Перевод статьи Гешана Манандара «5 Things to consider when deploying a new major feature to production».
Хорошо поставленный процесс деплоймента новой функциональности на продакшен — залог эффективной работы любой команды. Сегодня автоматическое развертывание возможно с помощью таких инструментов как capistrano или fabric – это делает деплоймент легкой задачей, а не пугающей операцией, где стоит пропустить один шаг – и навернется весь продакшен.
Сегодня Docker и Kubernetes сильно облегчают процесс развертывания. В этом посте я подчеркну вещи, на которые следует обращать внимание, когда разворачиваешь новую major-фичу, затрагивающую какой-то большой участок кода и связанную с изменениями в базе данных.
Что такое Major-фича
Как различить деплоймент обычной и major-фичи? Например, если вы разворачиваете подсистему пользовательского кошелька на e-commerce сайте или функцию многопользовательской аренды в приложении для съема жилья, следует считать, что вы выкатываете major-фичу.
Обычные фичи не требуют плана выкатывания или особого продумывания всего наперед. Их можно деплоить с помощью запуска вашей обычной процедуры деплоймента и это нормально. Major-фича это целый под-проект на фоне обычных фич и багов. Развертывание такого существенного функционала это общая ответственность команды разработчиков, системных администраторов / devops и продуктовой команды.
TLDR;
Прежде чем выкатывать в продакшен новую major-фичу, всегда тщательно проверяйте ее в стейджинге. Сделайте бэкап базы данных и разворачивайте маленькими частями с обратной совместимостью. Всегда имейте план отката и используйте feature flag.
На следует обратить внимание
Итак, что следует учитывать, собираясь развернуть новую major-фичу, которую команда закончила разрабатывать и хочет выкатить в продакшен?
Ниже указаны вещи, которые стоит отметить галочками, прежде чем делать major-деплоймент, связанный с изменениями большого куска кода и кое-какими изменениями схемы базы данных путем миграций:
1. Тщательное тестирование в стейджинге
Вы должны скрупулезно проверить новую фичу в стейджинге и убедиться, что покрыли различные use-cases. Я бы даже посоветовал завести google-таблицу со списком возможных use-cases и протестировать все пункты списка.
Если у вас есть QA-отдел, вам определенно следует заручиться их поддержкой.
Тестирование н уровне разработчика также является жизненно важным. Найти баг в стейджинге и исправить его намного дешевле, чем запустить в продакшен код с багом, а потом откатываться.
Возможно, вам все-таки придется откатиться, если какой-то баг обнаружится уже в продакшене. Но это нежелательная ситуация. Такое может случиться, если у вас уже готов релиз, а тестирование занимает слишком много времени и может его задержать.
2. Всегда делайте бэкап базы данных
Бэкап это одна из самых важных вещей, которые нужно сделать до внесения любых изменений в базу данных на продакшене. Это одна из тех мелочей, забыв о которых можно прийти к катастрофе.
Проблемы могут накатиться лавиной, если вы изначально не делали все правильно.
Так что будьте бдительны и всегда делайте бэкап базы данных, прежде чем запускать запросы типа migrations/alter. Также следите за тем, чтобы скрипт деплоймента не запускал migration автоматически. Это может сделать процесс деплоймента major-фичи болезненным, так что всегда будьте готовы к сложной ситуации.
3. Множественные маленькие деплои с сохранением обратной совместимости
Следует позаботиться о том, чтобы необходимые изменения в базе данных обладали обратной совместимостью.
У вас могут быть alter-таблицы и новые столбцы, сделанные в production database. Это поможет вам разделить major-фичу на более мелкие части и деплоить их по одной.
Это позволяет команде выкатывать новую фичу в продакшен более гибко и уверенно. А если вы разыграете свои карты правильно, это может стать способом развертывания с нулевым временем простоя.
4. Не забудьте план отката
Если вы планируете сделать один major-деплоймент для релиза major-фичи, подготовьте план, как вы будете ее выкатывать. В нем должны содержаться детали выполнения деплоймента, включая продуманную стратегию отката.
Даже если вы думаете, что деплоймент пройдет успешно, всегда имейте под рукой план отката.
Перечислите вещи, которые вам нужно будет откатить до текущей рабочей версии вашего приложения в случае, если все пойдет не так, как предполагалось, и вам придется возвращаться к прежнему состоянию. Если у вас будут небольшие проблемы, которые можно быстро исправить, от откатываться вам не придется, но в случае серьезных проблем это неизбежно.
5. Фичи с ограничением доступа
И последнее. Если вы деплоите major-фичу, будет хорошей идеей как можно раньше дать к ней доступ сотрудникам вашей компании (или какой-нибудь группе людей внутри компании).
Например, фича может быть протестирована в продакшене продуктовой командой.
Вы спрашиваете, как это сделать? Просто поставьте ограничения. Например, ваш код должен выполняться только если пользователь логинится с помощью email-адреса, оканчивающегося на @yourcompnay.com.
Я помню, мы так однажды сделали, когда выкатывали метод оплаты. Он был видимым только если использовался специфический email.
Таким можно выкатить major-фичу в продакшен, но отфильтровывать доступ к ней. После того как выбранная команда даст зеленый свет, можно просто убрать условие доступа к фиче и сделать ее доступной для всех пользователей.
Заключение
Для сохранения доступности вашего приложения стремитесь к нулевому времени простоя и запускайте скрипт миграции базы данных в продакшене в то время, когда трафик низкий. И даже если простой неизбежен, старайтесь продумывать все так, чтобы он был минимальным. Удачного деплоймента!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]