Выполнение Scrum-релизов — от подготовки контента до развертывания

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

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

• Разработайте и завершите все истории за спринт. Некоторые из них могут быть закончены раньше, но в большинстве случаев истории заканчиваются прямо перед окончанием спринта. Может быть, даже после демо-презентации, чтобы быть открытым здесь.
• Выполните все запланированные тесты контента спринта, чтобы убедиться, что код, который будет выпущен, готов к работе.
• Выявляйте обнаруженные ошибки и своевременно исправьте их перед публикацией.
• Убедитесь, что конвейер развертывания обновлен последним содержимым и что сам конвейер надежен в работе.
• Запустите конвейер во всех соответствующих средах, чтобы обновить их с точки зрения кода и данных.
• Подготовьте примечания к выпуску и сообщите клиенту о влиянии выпуска и о том, что именно изменится впоследствии.
• При необходимости синхронизируйтесь с другими параллельными командами scrum, чтобы обеспечить одновременный выпуск зависимого контента. Ничего не должно быть упущено, чтобы содержимое вашего релиза работало должным образом.
• Помимо всего этого, пройдите все церемонии схватки. Не только связанные с текущим спринтом, но и те, которые предназначены для следующего спринта (например, сеансы уточнения истории).

Теперь представьте, что спринту уже две недели.

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

Ожидание релиза после каждого спринта все еще кажется таким автоматическим?

Обработка содержания выпуска

Если все процессы в спринте автоматизированы, есть возможность просто «нажать на курок» и установить последнюю версию кода в производство в конце каждого спринта. Проблема в том, что я никогда не испытывал такого идеального состояния скрам-команды.

Если это действительно так на каких-то мелких частных предприятиях, то я им очень завидую. Но реальность корпоративного мира такова, что скрам-команда не достигает такого уровня зрелости. Напротив, процессы выпуска обычно связаны с длительными действиями, которые охватывают большую часть следующего спринта, влияя на этот спринт с точки зрения контента и всех показателей. Релиз — это просто стрессовый акт, который никому в команде не нравится.

Поэтому я обнаружил следующий лучший сценарий для решения проблем.

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

Отдельная версия кода для следующего релиза

Речь идет об обработке отдельных веток в репозитории GIT. Есть много способов решить одну и ту же проблему, и все они могут быть успешными. Но для целей этой статьи я буду делать вещи простыми, чтобы продемонстрировать подход и его влияние.

Чтобы иметь как можно меньшее влияние на текущую деятельность по разработке, важно выделить контент для следующего выпуска в отдельную ветку. Назовем его Release Branch. Это решит следующее:

• Команда разработчиков может продолжать деятельность и сливаться с новыми историями основной ветки без перерыва.
• Нет риска того, что на содержание релиза повлияют неожиданные модификации кода командой Scrum.
• Действия по тестированию могут выполняться в изолированной зоне. Здесь будут внесены только изменения, необходимые для решения задачи тестирования.
• Поскольку конвейер выпуска будет только продвигать контент из ветки выпуска в рабочую среду, у нас есть четкий процесс и полный контроль над контентом, который будет выпущен. Не может случиться так, что какая-то неожиданная фиксация в ветке Git сломает уже проверенный код.

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

Время выпуска, чтобы они снова работали

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

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

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

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

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

Это кажется хорошим компромиссом между быстрой доставкой и выполнением скрам-мероприятий без существенных сбоев.

Развернуть выпуск

После успешного завершения действий по тестированию, отладке и подготовке конвейера запуск производственного конвейера и завершение выпуска в производственную среду становится довольно простым процессом.

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

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

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

Слить ветку релиза обратно в ветку разработки

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

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

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

Установить регулярные выпуски

И вот он у нас есть ? — солидный процесс приближения к релизу. Единственное, чего не хватает, это регулярного обслуживания. В этом случае после каждого второго спринта.

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

• Если релиз состоится не так давно, в продакшене не так много нового контента для установки. Увеличение небольшое и считается стабильным.
• Так много нового контента не означает большого количества тестов и создания тестовых случаев. Меньше общения, согласования и сотрудничества с заинтересованными сторонами в отношении того, что необходимо подтвердить. Они также согласятся, что прошло не так много времени с момента последнего выпуска. Поэтому этому действию придается меньшее значение.
• Команда привыкнет к этому циклу; со временем он станет естественной частью команды.
• В качестве побочного эффекта среды разработки и тестирования часто получают обновления данных. В любом случае это требуется для каждого нового цикла испытаний. Так что это не будет просто очередной запланированной деятельностью. Точнее, действие, которое уже является частью налаженного процесса. Это изменение точки зрения оказывает большое влияние на атмосферу в команде. Никто бы не поверил.

Заключение

Эта глава завершает мои предыдущие посты на тему жизненного цикла скрама. Кроме того, речь идет о том, что доказало свою эффективность в реальной жизни.

Часто команды начинают действовать гибко и делают много ошибок. Затем они в конечном итоге развиваются и начинают делать что-то по-другому. Эта серия может помочь некоторым из них сделать это изменение быстрее.

Этот подход к выпуску не является единственно возможным и не без проблем. Они по-прежнему будут существовать, и командам придется иметь с ними дело. Затем улучшите то, что возможно, и забудьте о том, что не имеет смысла.

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