2009-08-18 4 views
4

Я просто получил сообщение о том, что мне нужно изменить значение конфигурации в 2009-09-01 (новые налоги). Наш нормальный подход для этого состоял бы в том, чтобы пробудиться в 2009-08-31 в 23:59, а затем просто измените значение вручную. Что не является большой проблемой, поскольку это часто случается. Но это заставляет меня задаться вопросом, как другие люди справляются с такими проблемами.Изменение значений конфигурации в определенное время

Итак! Как вы обрабатываете изменения конфигурации с конкретными датами?

(мы работаем в asp.net, но я не думаю, что это должно быть специфичные для языка)

Br
Карл Bergquist

ответ

18

я обычно хранить этот вид данных в таблице базы данных, как этот

Key, Value, EffectiveFrom, EffectiveTo 
----------------------------------------- 
VAT, 15.0,  20081201,  20091231 
VAT, 17.5,  20100101,   NULL 

Я бы затем использовать даты EffectiveFrom и EffectiveTo выбрать значение, которое является эффективным в данный момент времени. Если скорость открыта, то эффективность может быть равна NULL или 99991231.

Это также позволяет вернуться, не изменяя конфигурацию. Например. если кто-то попросит вас пересчитать налог за предыдущий месяц до изменения ставки.

+1

Я рассмотрел это решение. Будем ли мы не использовать базы данных для всех наших сервисов и, следовательно, вместо того, чтобы использовать базы данных в качестве общего решения. –

+1

Вы можете реализовать что-то подобное с помощью файла. – pjp

+0

Проблема с этим заключается в том, что вы должны потреблять каждое значение по одному. Но вы можете использовать одно и то же, но поскольку значение записывает ini-filename/destination, а затем у вас есть ini-файл с вашим решением. Кроме того, вы можете использовать независимую программу для этого. – StampedeXV

2

В Linux есть команда «at» для партии выполнение.
Подробнее см. "man at".

+0

Имя для команды планирования одинаково для Windows. Хотя, наличие службы планирования в вашем распоряжении не является решением проблемы. –

1

Это полностью зависит от ситуации и технологии.

Идея pjp хорошая, если вы получаете конфигурацию из базы данных или как метаданные для определения допустимого времени для целых наборов/файлов конфигурации.

Другой может быть: просто подготовьте новый конфигурационный файл с новыми записями и замените их в полночь (возможно, с перезапуском службы/программы). Подмена их возможна с помощью (как указано bei Neeraj) ...

Если синхронизация является проблемой, вы должны обработать изменение или, по крайней мере, время изменения на работающем сервере (чтобы избежать тайм-аута проблемы синхронизации).

2

Чтобы быть честным, просыпаться рядом со временем и менять его, кажется, самый простой и дешевый подход. Все технические решения в порядке, но это зависит от того, где вы работаете.

В нашей среде было бы дешевле и проще заставить кого-то проснуться и внести изменения, а не перепрофилировать функциональность части программного обеспечения, которое уже работает. Это, безусловно, связано с меньшим количеством тестирования, накладными расходами на разработку и затратами, что означает, что мы будем решать проблему так же, как и вы, вручную.

+0

Да, я согласен, в большинстве случаев это лучшее решение. –

+2

Этот подход очень слаб, когда вашему процессу разрешено принимать любое количество таких запросов ... Я бы сказал, что лучше всего также пробудить человека, который запросил изменение, и заставить их проверить его, как только он появится на месте. Этот дополнительный шаг помогает сократить количество этих запросов, которые вы получите в будущем. – ifatree

+0

Я думаю, это зависит от того, где вы работаете, как он масштабируется. Как правило, для нас технические решения дорогостоящие, требуют огромного количества ресурсов (управление проектами по управлению процессами выпуска, тестирование управления рисками и т. Д.). Приведение в действие большого количества очень дешевых (оффшорных) ресурсов для выполнения конкретных задач проще и дешевле для такого рода работ. – Tollo

0

Я видел гибридный подход. Вместо фактического изменения модели данных, чтобы включить EffectiveDate/EndDate или вручную изменить значения самостоятельно, планируйте сценарий для автоматического изменения значений. Кроме того, убедитесь, что у вас есть надежный план тестирования, который будет проверять все изменения.

Однако этот тип ручного изменения может оказать существенное влияние на отчетность. Если предыдущие транзакции соединяются напрямую с изменяемыми таблицами, цифры в исторических отчетах могут измениться очень плохо. На самом деле нет «правильного» ответа.

1

Мы получили такую ​​же проблему некоторое время назад и обрабатывали, используя следующий подход. это подходит, если вы хорошо знакомы с источником, который обрушивает изменения конфигурации.

В нашем случае источник разоблачил веб-сервис (действительный сторонний), который вернет измененные детали конфигурации. И на нашем сервере работает служба Windows, которая продолжает опрос веб-службы и обновляет файл конфигурации, если есть какие-либо изменения.

это прекрасно работает в нашем случае ..

Вы можете использовать этот подход путем изменения избирательного WebService части к источнику изменения конфигурации (например чтению изменений из некоторого диска пути). Но я не уверен, как это возможно при чтении изменений конфигурации из электронной почты.

0

Если я не могу сделать что-то вроде решения pjp, я бы использовал запланированную задачу или задание на сервер, чтобы автоматически обновлять ее в нужное время. Но ... Я бы, наверное, все еще бодрствовал, проверяя, что это сработало.

1

Почему бы просто не сделать сценарий оболочки для замены файлов. запустите его в cron и выпустите файлы за минуту до этого, и отправьте текст предупреждения, если НЕ успешны, и электронное письмо будет успешным.

Это пример на ящике Linux, но я думаю, вы поняли, что можете это сделать и в окне Windows.

Сценарий:

cp /path/to/old/config /path/to/backup/dir/config.timestamp 
cp /path/to/new/config 

if(/path/to/new/config exsits) { 
sendSuccessEmail(); 
} else { 
sendPanicTextAlert(); 
} 

хрон:

59 23 31 8 * /path/to/script.sh 

вы можете проверить это, как хорошо, прежде чем руки только указать на некоторые фиктивные каталогов и файлов

+0

Вы можете сделать то же самое в Windows с базовой планируемой задачей, если не хотите, чтобы на самом деле ничего не кодировали. – Gineer

+0

Вам все равно нужно будет скопировать изменение скрипта, а также процесс оповещения. Я согласен с тем, что запланированные задачи и задания Cron примерно одинаковы –

0

Посмотрите лучшим решением было бы параметризовать ваш файл конфигурации и добавлять такие вещи, как при использовании определенной записи. Это отрицает необходимость в копировании или замене файлов, и ваше приложение просто справится с этим. (Это идет для файла конфигурации захода на посадку или базы данных)

Если вы не можете изменить существующие системы, и вы должны идти с обменивать конфигурационные файлы, то у вас также есть два варианта:

  1. Использование по расписанию задание запускать пакетное задание или даже скрипт VBScript или PowerShell (который вам когда-либо нравится) Убедитесь, что вы настроили правильные учетные данные, чтобы иметь возможность сделать это в середине ночи, и вы также можете добавить некоторые проверки и смягчение этого подхода.
  2. Напишите Windows Service, который сделает это за вас. Здесь у вас есть вся необходимая гибкость. Кодируйте его, чтобы делать все, что он должен делать, делать все проверки, в которых вы нуждаетесь (чтобы вы могли спать, а не убеждаться, что это действительно сработало) и т. Д. И т. Д. Вы также будете заботиться о плане планирования, и все будет будь хорошим. Здесь вы можете использовать объект xml DOM и xPath и не заменять файл, а просто обновлять определенные записи по мере необходимости.

Помните, что любые изменения в файле конфигурации приведут к перезапуску вашего сайта, поэтому убедитесь, что вы позаботились обо всех других причинах, связанных с ведением домашнего хозяйства.(Хотя это было бы точно так же, если бы вы сидели там в середине ночи, копируя файл)

Смежные вопросы