Каковы хорошие стратегии, позволяющие исправлять развернутые приложения?

Question

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

Но, к сожалению, мы живем в реальном мире, и иногда ошибки проносятся мимо нас и не поднимают свои уродливые головы, пока мы не заняты написанием кода для следующего выпуска. И ошибка должна быть исправлена ​​ Теперь . Не как часть следующего запланированного выпуска. Не сегодня вечером, когда умирает движение. Теперь .

Как вы справляетесь с этой необходимостью? Это действительно может идти вразрез с хорошими методами проектирования, такими как рефакторинг вашего кода в красивые, дискретные библиотеки классов.

Ручное редактирование разметки и хранимых процедур на производственном сервере может стать сигналом к ​​катастрофе, но может также предотвратить катастрофу.

Каковы некоторые хорошие стратегии для разработки приложений и методов развертывания, чтобы найти баланс между потребностями обслуживания и хорошими методами кодирования?

Answer 1

[Несмотря на то, что мы много тестируем перед выпуском,] То, что мы делаем, это:

Наш SVN выглядит так:

/repo/trunk/
/repo/tags/1.1
/repo/tags/1.2
/repo/tags/1.3

Теперь, когда мы выпускаем, мы создаем тег, который мы в конечном итоге проверяем на производстве. Прежде чем приступить к производству, мы делаем постановку, которая [меньше серверов, но] почти такая же, как и производство.

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

Теперь, когда нам нужно исправить проблему, мы сначала исправляем ее в тегах / x, а затем svn update из тега, и это хорошо. Иногда мы проходим стадирование, с некоторыми проблемами (например, мелкими / тривиальными исправлениями, такими как орфография), мы минуем постановку.

Единственное, что нужно помнить, это применить все патчи от tags/x до trunk.

Если у вас более одного сервера, Capistrano чрезвычайно полезен для выполнения всех этих операций.

Answer 2

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

Answer 3

Одной из стратегий является интенсивное использование внешних файлов конфигурации декларативного стиля для различных компонентов.

Примеры этого:

• Доступ к базе данных / объектно-реляционное отображение с помощью инструмента, подобного IBatis / IBatis.NET
• Регистрация через такой инструмент, как JLog / NLog
• Внедрение зависимостей с помощью инструмента, подобного Spring / Spring.NET

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