Три ингредиента идеальных релизов ПО

Соедините одну часть архитектуры с двумя частями командной работы. Добавьте автоматизацию и перемешайте.

Dan Radigan Dan Radigan
Просмотр тем

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

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

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

Идеальный релиз программного обеспечения начинается с модульной архитектуры

Какое бы ПО вы ни разрабатывали, лучше всего выпускать продукт как можно раньше и часто поставлять. Чтобы органично вписать релизы в культуру agile, команда может создать модульную архитектуру (или преобразовать имеющуюся в такую). Вместо того чтобы работать над одним массивным приложением (таким как упомянутый ранее монолит), разбейте его на ранних этапах программы на несколько фрагментов-модулей. Объедините схожие функции в небольшие приложения или компоненты и составьте четкие планы («контракты») API для каждого приложения или компонента. Эти API можно подвергать автоматическому тестированию с каждой новой сборкой, чтобы убедиться в совместимости и сократить риски на этапе выпуска программного обеспечения.

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

Идеальные релизы программного обеспечения строятся на взаимопонимании

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

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

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

Следующие рекомендации будут полезными для операционных команд, сотрудничающих с разработчиками.

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

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

Идеальные релизы ПО | Atlassian — тренер по agile

Идеальные релизы программного обеспечения легко переносить из одной среды в другую

Автоматизация, автоматизация и еще раз автоматизация!

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

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

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

Идеальные релизы программного обеспечения — отличная штука!

Отличительная черта agile-разработки заключается в том, что код должен поддерживаться в состоянии готовности к релизу.

Как это делается

Мы считаем, что в рамках предоставления программного обеспечения как услуги (SaaS) проще всего управлять небольшими частыми релизами. В случае с доступными для скачивания продуктами большое значение имеет тесное сотрудничество между разработчиками, операторами и инженерами по сборке. Эти команды совместно работают над автоматизацией релизов и заранее адаптируют автоматизацию к предстоящим изменениям в продуктах. Многие команды Atlassian автоматически развертывают каждую успешную сборку главной ветки в среде тестирования. Когда релиз готов к переводу в промежуточную среду или к поставке клиентам, эти команды могут инициировать автоматическое развертывание одной кнопкой. 

Поскольку мы являемся разработчиками ПО, на первом плане нашего цикла инновации должен находиться релиз. С кодом, который мы написали, будут взаимодействовать клиенты, и они будут делиться своими впечатлениями. Круто! Если выпуск версий станет вашим привычным занятием в рабочие дни, вам будет проще выводить код в рабочую среду и с гордостью произносить: «Это мой код!»

продолжение темы
Stress free release