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

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

Убедившись, что все в порядке, вы можете начать направлять трафик на новую версию, и, когда он будет переведен полностью, старую версию можно будет удалить, так что продолжит работать только новая версия. Если же что-то пойдет не так, вы можете удалить новую версию и начать сначала – пользователи при этом даже ничего не заметят.

Такой способ развертывания называется сине-зеленым (blue-green), и если вы его освоите, то сможете проводить релизы спокойно и безболезненно. Дополнительным преимуществом этого способа является постоянная проверка скриптов для развертывания инфраструктуры. Чем сложнее ваша архитектура, тем сложнее в реализации будет этот способ деплоя, однако ничего невозможного тут нет. И он идеально подходит для веб-приложений.

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

Когда вы добьетесь того, что релизы будут хорошо отработаны и будут проходить безболезненно, вы избавитесь от стресса и рисков, связанных с обновлениями, и они перестанут быть значительным событием. Независимо от того, какую стратегию вы выберете, всегда создавайте описание релиза (release notes), в котором описывайте все изменения, – это очень полезная привычка. Это может быть просто текстовый файл, документ в вики или же страница в Atlassian Confluence. Некоторые системы управления задачами позволяют привязывать тикеты или спринты к версиям ПО и автоматически создавать описание релизов.

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