Проверочный список для выпуска промышленных приложений с иллюстрациями

Улучшает сон, приносит радость, повышает управляемость и наблюдаемость релизов.

Автор текста - Noah Mandelbaum, Выдающийся инженер. Автор иллюстраций - Mike Damrath, Старший менеджер. Оригинальная статья на английском.

Разработка приложений требует больших усилий.

Мы встаём и садимся. Мы работаем неделями, чтобы писать чистый код. Мы старательно обдумываем как лучше поддерживать наши приложения, используя идеи, которые Шанти Шридхаран (Santhi Sridharan) описала в своей статье про разработку поддерживаемого программного обеспечения. Иногда мы рефакторим до тех пор, пока наш глаз не замыливается.

И немного разочаровываемся, когда обнаруживаем на релизе, что наше приложение, которое мы любовного разрабатывали, имеет изъяны или ломается в каких-то ситуациях.

Некорректная работа программ может дать клиентам негативный опыт использования, создать риски для бизнеса, привести к большим временным затратам на исправление ошибок. Так как же мы можем быть более уверенными в успешности релиза?

Этот проверочный список пытается установить баланс между отсутствием формального процесса выпуска ПО и сложностью Release It! (книга Майкла Нейгарда "Release it! Проектирование и дизайн ПО для тех, кому не всё равно"). Проходя по этому списку, отвечайте на вопросы - это поможет вам понять, как вашей команде прийти к успешным релизам. Плюсом вы, возможно, улыбнётесь читая или разглядывая скетчи.

Примечание:

Мы - два разработчика ПО, работающие над системами, которые остро необходимы нашим клиентам и сотрудникам Capital One. Мы создали этот проверочный список, чтобы помочь нашим командам с релизными процессами. Мы понимаем, что он не идеален, и вам, возможно, потребуется изменить его для вашей команды. Но надеемся, что он будет для вас полезен.

Проверочный список для выпуска промышленных приложений с иллюстрациями

В 1735 году Бенджамин Франклин придумал фразу “унция профилактики стоит фунта лечения”, объясняя жителям Филадельфии наилучший способ предотвращения пожаров.

Чтобы помочь предотвратить пожар в вашем релизе, мы разделили этот проверочный список на 3 секции:

• Pre-release - предрелизная.
• Releasing - в процессе релиза.
• Мониторинг - наблюдение после релиза.

Предрелизный список

Мы стараемся следовать двум главным правилам как мы подготавливаем бизнес требования для релиза:

1. Ограничивайте количество новшеств в релизе, чтобы ограничить риск: старайтесь релизить чаще.
2. Имейте полный список требований (definition of done) для всех задач:
   • Написаны юнит-тесты с хорошим покрытием кода.
   • Выполнены автоматизированные функциональные тесты для проверки новых возможностей и регрессионного тестирования старых.
   • Проведены тесты удобства использования, доступности.
   • Позаботились о проверке производительности.
   • Просканировали на предмет уязвимостей.
   • Задокументировали технический долг, который мы оставили.

Более того, когда мы готовы к релизу, есть несколько технических моментов, на которые надо обратить внимание:

• Сохранён ли код, который мы хотим деплоить, в системе контроля версий, помечен (tag) ли соответствующей меткой?

• Правильно ли мы обновили наши настройки на проде?

• Если у нашего продукта есть зависимости (например, микросервисы, базы данных и т.д.), развёрнуты ли они на проде и готовы ли к приёму запросов?

• Убедились ли мы, что нужная нам инфраструктура доставлена на прод с правильными настройками: сеть, DNS, балансировщики нагрузки и, например, сервисы Амазона?

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

• Проверили ли мы, что происходит с пользовательским опытом, когда мы выкатываемся в середине дня (в пик активности) - получат ли пользователи ошибки?

• Установили ли мы переключатели для канареечного или A/B тестирования?

• Учли ли мы контроль доступа для приложений, которые этого требуют?

• Проверили ли мы средства наблюдения за работой приложения (observability), чтобы иметь возможности для отладки в проде. Получаем ли мы и анализируем метрики, ход выполнения запросов и журналируем (логируем) ли мы события? Заметьте, существует множество коммерческих и открытых программных продуктов, которые помогают вам это делать.

• Есть ли план по откату к прошлой версии? Может ли новая возможность быть отключена, если требуется? Можем ли мы вернуться к прошлой версии кода? Могут ли появиться проблемы у пользователей с рабочим окружением, если релиз пойдёт не по плану?

Мы стараемся всегда иметь план Б и В!

Когда подготавливаешь релиз, люди также важны:

• Есть ли у нас список контактов ключевых технических специалистов, к которым мы можем обратиться в случае, если релиз проходит не так как планировалось?
• Понимаем ли мы, как повлияют наши изменения на пользователей, и каких пользователей? → Проверяли ли мы, что фичи во включённом состоянии работают у правильной группы людей, и как они работают у других групп? Проверили ли, что контроль доступа правильно работает для разных групп людей? Есть ли назначенные люди, которые помогут нам проверить наш релиз? Люди такие как: продуктовый менеджер (PM), владелец продукта (PO), инженеры поддержки (Support). Люди, которые должны заметить изменения, и кто должен не заметить их.
• Сделали ли мы другие подготовительные работы, которые помогут нам релизить более успешно? Например:
  • Обновили документацию и материалы для обучения?
  • Объявили ли о выходе релиза?
  • Отправили информацию заинтересованным лицам?

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

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

Список для проведения релиза (доставки)

Пережив бессчётное количество установок софта вручную, становится ясно, что нет ничего лучше хорошей системы для непрерывной интеграции и доставки (CI/CD). Если у вас её ещё нет, мы рекомендуем обзавестись ей. В противном случае вы можете застрять с ручным руководством и огромной головной болью, которая с ним приходит.

Мы достаточно удачливы, чтобы иметь CI/CD конвейер. Поэтому, когда идёт релиз, мы:

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

Так как нам важен пользовательский опыт, мы задаём себе также следующие вопросы:

• Люди, назначенные для проверки, дали подтверждение, что они увидели то, что должны были увидеть? И не могут увидеть то, что не должны?
• Люди, кто проверяет нашу систему, заметили ли какие-нибудь аномалии: окно ошибки, задержки отклика, необычный процесс навигации? Иногда по таким незаметным сигналам мы понимаем, что что-то пошло не так.

В случае, если релиз оказался неуспешным, мы запускаем план по откату изменений.

Мониторинг - не список

Случается, что релиз сразу встаёт и нормально работает, но позже появляются проблемы. Это особенно часто происходит, когда он касается баз данных или изменений API.

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

Стоит сказать, мы также наблюдаем первые 24 часа после релиза. Особенно, если релиз был выкачен во время с низким потоком трафика.

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

Заключение

Этот проверочный список необязательно должен быть сложным у всех команд и во всех случаях. Надеемся, он развлёк вас. Также надеемся, он поможет вам доставить вашу работу до пользователей.