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

• Определите, что нужно вывести в офлайн: серверы, компоненты.

• Что будут видеть конечные клиенты: нужно ли создавать специальную страницу с информацией о работах?

• Рассчитайте следующие сроки:

• время на выключение сервиса;

• время на резервное копирование;

• время на обновление программного и аппаратного обеспечения;

• время на проверку, что все работает;

• время на приведение системы в доступное для пользователей состояние.

• Для каждого из этих этапов распишите точный порядок действий.

• Для каждого этапа назначьте ресурсы и определите процесс перехода к следующему этапу.

• Определите совместно с бизнесом наиболее удобное время проведения релиза, желательно в период наименьшего использования системы.

• Составьте список тех, кому необходимо предоставлять отчеты о ходе работы, и тех, кого необходимо уведомить о завершении релиза.

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

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

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

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