как минимизировать время простоя приложения при обновлении базы данных и приложения ORM

Question

В настоящее время мы используем решение для электронной коммерции для туристической компании. Каждый раз, когда мы выпускаем релиз, мы должны закрывать сайт электронной коммерции при обновлении схемы базы данных и кода доступа к данным. Мы используем специально построенный ORM, где каждый объект данных отвечает за свои собственные операции CRUD. Это достигается путем динамического генерирования SQL на основе атрибутов в объекте данных.

Например, объект данных для адреса будет ...

[tableName="address"]
public class address : dataEntity
{
  [column="address1"]
  public string address1;
  [column="city"]
  public string city;
}

Итак, если мы добавим новый столбец в базу данных, мы должны обновить схему базы данных, а также обновить сущность данных.

Как вы можете ожидать, деловые люди не слишком довольны этим перерывом в работе, так как это ограничивает их денежный поток. Операторы недовольны тем, что им приходится сталкиваться с большим напряжением при обновлении базы данных и приложений. Программисты расстроены, потому что они постоянно попадают в неприятности из-за унаследованной системы.

Есть ли у кого-нибудь из вас умных людей какие-то предложения?

Answer 1

Первый ответ, очевидно, не использовать ORM. Только прикладные программисты считают, что они хороши. Изучи SQL, как и все остальные:)

ОК, так что вернемся к реальности. Что может помешать вам ограничить все изменения схемы только дополнениями. Затем вы можете обновлять схему БД в любое время и устанавливать перекомпилированное приложение только до безопасного времени (лучше всего 6 утра) после обновления БД. Если вам нужно что-то удалить, выполните шаги в обратном порядке - установите новое приложение, оставив схему без изменений, а затем удалите биты из схемы.

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

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

Answer 2

Поддержка этого сценария значительно усложнит вашу среду и / или процесс и / или приложение.

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

В большинстве случаев лучше оставить приложение / среду / процесс простым и жить в центре города в течение медленного времени дня / недели / месяца. Практически все приложения время от времени должны быть «сняты» для «регулярного технического обслуживания».