Перевод "An Illustrated Enterprise Release Checklist For Applications" - статьи о процессах, необходимых для спокойного и контролируемого выпуска новых версий ваших приложений.
Улучшает сон, приносит радость, повышает управляемость и наблюдаемость релизов.
Автор текста - Noah Mandelbaum, Выдающийся инженер. Автор иллюстраций - Mike Damrath, Старший менеджер. Оригинальная статья на английском.
Разработка приложений требует больших усилий.
Мы встаём и садимся. Мы работаем неделями, чтобы писать чистый код. Мы старательно обдумываем как лучше поддерживать наши приложения, используя идеи, которые Шанти Шридхаран (Santhi Sridharan) описала в своей статье про разработку поддерживаемого программного обеспечения. Иногда мы рефакторим до тех пор, пока наш глаз не замыливается.
И немного разочаровываемся, когда обнаруживаем на релизе, что наше приложение, которое мы любовного разрабатывали, имеет изъяны или ломается в каких-то ситуациях.
Некорректная работа программ может дать клиентам негативный опыт использования, создать риски для бизнеса, привести к большим временным затратам на исправление ошибок. Так как же мы можем быть более уверенными в успешности релиза?
Этот проверочный список пытается установить баланс между отсутствием формального процесса выпуска ПО и сложностью Release It! (книга Майкла Нейгарда "Release it! Проектирование и дизайн ПО для тех, кому не всё равно"). Проходя по этому списку, отвечайте на вопросы - это поможет вам понять, как вашей команде прийти к успешным релизам. Плюсом вы, возможно, улыбнётесь читая или разглядывая скетчи.
Примечание:
Мы - два разработчика ПО, работающие над системами, которые остро необходимы нашим клиентам и сотрудникам Capital One. Мы создали этот проверочный список, чтобы помочь нашим командам с релизными процессами. Мы понимаем, что он не идеален, и вам, возможно, потребуется изменить его для вашей команды. Но надеемся, что он будет для вас полезен.
В 1735 году Бенджамин Франклин придумал фразу “унция профилактики стоит фунта лечения”, объясняя жителям Филадельфии наилучший способ предотвращения пожаров.
Чтобы помочь предотвратить пожар в вашем релизе, мы разделили этот проверочный список на 3 секции:
Мы стараемся следовать двум главным правилам как мы подготавливаем бизнес требования для релиза:
Более того, когда мы готовы к релизу, есть несколько технических моментов, на которые надо обратить внимание:
Сохранён ли код, который мы хотим деплоить, в системе контроля версий, помечен (tag) ли соответствующей меткой?
Правильно ли мы обновили наши настройки на проде?
Если у нашего продукта есть зависимости (например, микросервисы, базы данных и т.д.), развёрнуты ли они на проде и готовы ли к приёму запросов?
Убедились ли мы, что нужная нам инфраструктура доставлена на прод с правильными настройками: сеть, DNS, балансировщики нагрузки и, например, сервисы Амазона?
Проверили ли мы, что происходит с нашим приложением под высокой нагрузкой: масштабируется ли оно, или же падает?
Проверили ли мы, что происходит с пользовательским опытом, когда мы выкатываемся в середине дня (в пик активности) - получат ли пользователи ошибки?
Установили ли мы переключатели для канареечного или A/B тестирования?
Учли ли мы контроль доступа для приложений, которые этого требуют?
Проверили ли мы средства наблюдения за работой приложения (observability), чтобы иметь возможности для отладки в проде. Получаем ли мы и анализируем метрики, ход выполнения запросов и журналируем (логируем) ли мы события? Заметьте, существует множество коммерческих и открытых программных продуктов, которые помогают вам это делать.
Есть ли план по откату к прошлой версии? Может ли новая возможность быть отключена, если требуется? Можем ли мы вернуться к прошлой версии кода? Могут ли появиться проблемы у пользователей с рабочим окружением, если релиз пойдёт не по плану?
Мы стараемся всегда иметь план Б и В!
Когда подготавливаешь релиз, люди также важны:
Многие большие компании требуют более формальный процесс контроля изменений. Мы работаем в одном из таких мест, так что иногда мы должны создавать запрос на изменения, включающий:
Пережив бессчётное количество установок софта вручную, становится ясно, что нет ничего лучше хорошей системы для непрерывной интеграции и доставки (CI/CD). Если у вас её ещё нет, мы рекомендуем обзавестись ей. В противном случае вы можете застрять с ручным руководством и огромной головной болью, которая с ним приходит.
Мы достаточно удачливы, чтобы иметь CI/CD конвейер. Поэтому, когда идёт релиз, мы:
Так как нам важен пользовательский опыт, мы задаём себе также следующие вопросы:
В случае, если релиз оказался неуспешным, мы запускаем план по откату изменений.
Случается, что релиз сразу встаёт и нормально работает, но позже появляются проблемы. Это особенно часто происходит, когда он касается баз данных или изменений API.
Мы поняли, что если мы настраиваем наблюдаемость хорошо, мы можем установить тревоги (alarm), которые будут нас проактивно информировать в случае возникновения ошибок и прочих аномалий. Эти тревоги предупреждают нас, если заметно необычное поведение нашей инфраструктуры, кода, критичных транзакций в нашей системе. Для релизов, которые требуют более точной проверки, мы также исследуем логи на предмет нестандартного поведения.
Стоит сказать, мы также наблюдаем первые 24 часа после релиза. Особенно, если релиз был выкачен во время с низким потоком трафика.
Временами мы спрашиваем надёжных пользователей для перепроверки функциональности релиза и вербально или письменно получаем подтверждение об успехе.
Этот проверочный список необязательно должен быть сложным у всех команд и во всех случаях. Надеемся, он развлёк вас. Также надеемся, он поможет вам доставить вашу работу до пользователей.