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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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