Создание интуитивно понятного приложения, увеличение пропускной способности и повышение стабильности и эффективное непрерывное развертывание фактически снижает риск любой разработки ПО. В процессе непрерывного обучения и коммуникации с людьми, которые осуществляют его, мы делаем выводы, которые можно свести к четырем принципам:
- Релизы программного обеспечения с низкими рисками — поэтапные
- Развертывание и релиз должны быть разграничены
- Сосредоточьтесь на снижении размера
- Оптимизируйте для получения устойчивости
Принцип 1: Релизы низкого риска являются поэтапными
Любая развитая организация выпускает на рынок системы, состоящие из нескольких взаимосвязанных компонентов или услуг, со связанными компонентами. Например, мое приложение может зависеть от некого статического контента в базе данных и некоторых услуг, предоставляемых другими системами. Обновление всех тех компонентов в одном большоом релизе подразумевает наличие больших рисков, чтобы выпустить новую рабочую функциональность.
Вместо этого, развертывание компонентов отдельно, в паралельной конфигурации, если таковое возможно, например, если вам нужно, обновить статический контент, поможет вам не переписывать старое содержание. Вместо этого, лучше перенести его содержимое в новый каталог, так чтобы он был доступнен по разным URL перед развертыванием новой версии приложения, которое требует его.
Изменения в базе данных также могут быть реализованы постепенно. Даже такие организации, как Flickr, которые развертывают версии несколько раз в день, не развертывают изменения в базе данных так часто. Вместо этого они используют функцию «развернуть шаблон». Правило гласит, никогда не меняйте все сразу существующие объекты. Вместо этого, разделите изменения на обратимые этапы:
До релиза, добавьте новые объекты в базу данных, которая потребуется в новой версии.
Выпустите новую версию приложения, которая обращается к новым объектам, но считывает со старых объектов в случае необходимости – это поможет перенести данные «без усилий». Если вам нужно вернуться к какому-то этапу, вы сможете сделать это без отката изменений базы данных.
Наконец, когда новая версия приложения стабильна, и вы уверены, что вам не нужно будет делать откаты, применять условный сценарий чтобы закончить миграцию всех старых данных и удалить все старые объекты.
Аналогично, если новая версия вашего приложения требует новую версию некоторого стороннего сервиса, вы должны иметь новую версию этого сервиса, рабочую и протестированную перед развертыванием новой версии вашего приложения. Один из способов сделать это — записать старую версию своего сервиса, чтобы клиенты ожидающие новой версии могли работать с ней. На сколько легко будет реализовать это во многом зависит от платформы и дизайна, с которыми вы работаете.
Если это не возможно, вам нужно иметь возможность запускать несколько версий паралельно. В любом случае, ваш сервис должен быть в состоянии поддерживать старых клиентов.
Разрабытывая программное обеспечение на заказ, сервисы для поддержки клиентов, работающих на старых версиях, будьте готовы к затратам – наиболее серьезных затрат требуэт в обслуживание и тестирование совместимости. Это означает, что потребители Ваших услуг могут обновить версию приложения, когда им удобно, в то время как вы можете сосредоточиться на разработке новой функциональности. И, конечно, если потребителям нужно вернуться к старой версии своего приложения, которое требует более старой версии вашего сервиса, они могут сделать это.
Конечно, необходимо учитывать множество крайних случаев при использовании таких методов создания программного обеспечения, кроме того они требуют тщательного планирования и дополнительной разработки ПО, но в конечном счете это всего лиши поэтапные приложения.
Подводя итог, рассмотрим, как нам выпустить новую версию приложения похэтапно? Это цель метода автоматического развертывания. При использовании этого шаблона, мы развертываем новую версию приложения паралельно со старой версией. Чтобы перенести данные со старой на новую версию и вернуться к старой версии, мы изменим настройку балансировки нагрузки или маршрутизатора. Изменения при автоматическом развертывании применимы при работе в кластерных серверах. С помощью этой модели, вместо обновления сразу целого кластера до последней версии, вы делаете это постепенно.
Подготовлено компанией ПНН. www.pnn.com.ua