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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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