Непрерывная интеграция в SAFe®

Вольный перевод статьи Continuous Integration — Scaled Agile Framework.

Суть интеграции в том, что она регулируют процесс разработки продукта. Это точка опоры для улучшения системы. Проект оказывается в беде, когда сроки интеграции затягиваются. —Dantar Oosterwal, The Lean Machine

Непрерывная интеграция (Continuous Integration, CI) — это процесс разработки, тестирования, интеграции и проверки в предпродуктивной среде Фич из Бэклога Программы, после чего они готовы к развертыванию и Релизу по Требованию.

CI — это второй элемент из четырех в Конвейере Непрерывной Поставки (Continuous Delivery Pipeline, CDP), состоящем в том числе из Непрерывного изучения (Continuous Exploration, CE), Непрерывной интеграции (Continuous Integration, CI), Непрерывного развертывания (Continuous Deployment, CD) и Релиза по требованию (Release on Demand, RoD) (рисунок 1).

Непрерывная интеграция является критически важной технической практикой для каждого Agile Release Train (ART). Это повышает качество, снижает риски и определяет быстрые, надежные и устойчивые темпы разработки.

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

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

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

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

Четыре вида деятельности в непрерывной интеграции

Как показано на рисунке 2, SAFe описывает четыре вида деятельности, связанные с непрерывной интеграцией:

• Разработка описывает методы, необходимые для реализации историй и коммита кода и компонентов в систему управления версиями.
• Сборка описывает методы, необходимые для создания развертываемых исполняемых файлов и объединения веток разработки в основную ветку (mainline).
• Сквозное тестирование описывает методы, необходимые для проверки решения.
• Предпродуктив описывает методы, необходимые для размещения и проверки решения в «буфере» перед рабочей средой.

Разработка решения

Разработка решения относится к реализации историй путем уточнения Фич из Бэклога Программы, кодирования, тестирования и коммита рабочего продукта в систему управления версиями. Тестирование в этом случае, как правило, сосредоточено на модульном и сценарном тестировании и в большинстве случаев требует тестовых дублеров (test doubles) для эмуляции других компонентов или подсистем.

С разработкой решения связаны семь практик:

• Нарезка фич на истории — разделение фич на истории обеспечивает непрерывную поставку небольшими партиями и плавную интеграцию. Может включать в себя создание карт пользовательских историй (User Story Mapping, USM), чтобы гарантировать, что рабочие процессы разработаны в соответствии с потребностями клиентов.
• Разработка на основе поведения (Behaviour Driven Development, BDD) — это процесс, который владельцы продуктов и команды используют для более глубокого понимания требований и улучшения качества путем создания критериев приемлемости и приемочных тестов. Последние часто автоматизированы еще до того, как код будет написан. BDD часто используется совместно с TDD (Test Driven Development).
• Разработка через тестирование (TDD) — включает в себя написание модульного теста, а затем построение минимального кода, необходимого для прохождения теста. Это приводит к лучшей архитектуре, более высокому качеству и повышению производительности разработки. TDD часто используется совместно с BDD.
• Контроль версий — эффективный контроль версий позволяет командам быстро восстанавливаться после проблем и улучшать качество, убедившись, что нужные компоненты интегрированы вместе. Агрегирование объектов разработки в системе контроля версий является опережающим индикатором зрелости процесса непрерывной интеграции.
• Встроенное качество — встроенное качество предписывает практики в отношении потока, архитектуры и качества архитектуры, качества кода, качества системы и качества выпуска.
• Телеметрия приложений — телеметрия приложений является основным механизмом, который помогает проверить результаты соответствующих гипотез с помощью объективных данных.
• Моделирование угроз — в дополнение к моделированию угроз, выполняемому при моделировании архитектуры в непрерывном изучении (CE), при создании системы следует также уделять внимание возможным уязвимостям, которые могут быть привнесены в систему.

Сборка решения

Команды непрерывно интегрируют новый код на этапе сборки.

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

«Проверенный коммит» (gated commit) гарантирует, что программное обеспечение прошло проверку в контрольной точке (например, модульное тестирование, тестирование производительности и отсутствие известных дефектов и т. д.) прежде чем оно будет проверено в основной кодовой базе или основной ветке. Код, который проходит через контрольную точку, автоматически интегрируется в основную ветку — это устраняет сложности, связанные с управлением несколькими ветвями разработки. Такой подход, как разработка в основной ветке (Trunk Based Development), помогает гарантировать, что код может быть надежно выпущен по требованию без необходимости дорогостоящих замораживаний кода или итераций стабилизации.

Существует пять методов, которые могут помочь в создании решения:

• Непрерывная интеграция кода — коммит кода должен автоматически инициировать сборку и тестирование изменений. В идеале это должно происходить на каждом коммите, но на практике должно происходить не реже нескольких раз в день (по расписанию).
• Автоматизация сборки и тестирования — процесс сборки должен быть автоматизирован и включать в себя модульные и сценарные тесты для проверки изменений. Эти тесты часто используют тестовые дублеры (test doubles) для эмуляции других частей систем и обеспечения быстрых сборок.
• Разработка в основной ветке — рекомендуется избегать долгоживущих веток разработки. Команды должны интегрировать результаты работы как можно быстрее (не реже одного раза в день) и желательно работать в одной ветке.
• Проверенный коммит — коммит в основную ветку несет риск, так как сломанные изменения могут повлиять на многие команды. Вот почему только изменения, которые были проверены в процессе сборки и тестирования, интегрируются в основную ветку.
• Безопасность приложений — инструменты анализа кода проверяют код и сторонние пакеты на наличие известных уязвимостей.

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

Сквозное тестирование решения

Автоматизированного локального тестирования историй и компонентов недостаточно. Для тщательного тестирования фич требуется интеграция и тестирование на уровне системы в целом. При поддержке Системной команды результаты работ всех команд Agile Release Train (ART) должны часто интегрироваться, чтобы гарантировать, что решение разрабатывается так, как ожидалось (см. рисунок 3).

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

Отметим шесть методов, которые могут помочь в сквозном тестировании системы:

• Конгруэнтность тестовой и производственной среды — конгруэнтность среды гарантирует, что тестирование использует решение так, как оно будет вести себя перед реальными пользователями, и снижает вероятность того, что дефекты попадут в продуктив.
• Автоматизация тестирования — необходимо выполнить множество типов тестов: функциональное тестирование, интеграционное тестирование, регрессионное тестирование и т.д.
• Управление тестовыми данными — для обеспечения стабильности тесты должны быть консистентными и реалистичными, максимально эмулируя продуктив. Тестовые данные, как и код, должны быть в системе контроля версий.
• Виртуализация сервисов — различные виды тестирования требуют разных сред. Виртуализация сервисов позволяет командам моделировать продуктивную среду без затрат и усилий, связанных с созданием реальных сред и управлением ими.
• Тестирование нефункциональных требований (Non-Functional Requirements, NFR) — системные атрибуты, такие как безопасность, надежность, производительность, ремонтопригодность, масштабируемость и удобство использования, также должны быть тщательно протестированы.
• Непрерывная интеграция с поставщиками — поставщики вносят уникальный вклад, который может оказать значительное влияние на сроки выполнения и поставку стоимости. Результаты их работы также должны быть постоянно интегрированы. Это помогает принять общий интеграционный цикл и установить объективные этапы оценки прогресса работ.

Проверка в предпродуктиве

Наконец, все решение должно быть проверено в предпродуктивной среде на основе следующих методов:

• Актуализация предпродуктивной среды — приведение предпродуктивной среды к состоянию, максимально повторяющему состояние продуктивной среды.
• Сине-зеленое развертывание (Blue-Green Deployment) — паттерн включает в себя две среды — активную (продуктив) и «неактивную/выключенную» (предпродуктив). Изменения непрерывно поступают в неактивную среду, где они накапливаются до тех пор, пока не будут готовы к развертыванию в продуктивной среде. В момент переключения (например, обновляется балансировщик нагрузки) неактивная среда становится активной, в то время как активная среда наоборот становится неактивной. Это обеспечивает непрерывную поставку, развертывание без простоев и быстрое восстановление после сбоев.
• Демонстрация системы — это мероприятие, на котором заинтересованные стороны оценивают готовность решения к развертыванию в продуктивной среде.

Создание культуры непрерывной интеграции

Непрерывная интеграция больших и сложных систем трудозатратна.

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

• Интегрируйте часто — чем чаще команды интегрируются, тем быстрее они находят проблемы. И чем сложнее это сделать, тем чаще им нужно это делать — устраняя препятствия и добавляя автоматизацию на этом пути. Это приводит к более быстрым циклам обучения и меньшему количеству переделок.
• Сделайте результаты интеграции видимыми — когда процесс интеграции прерывается, все должны знать, что он сломался и почему. Когда ошибки исправлены, следует добавить новые тесты, чтобы обнаружить проблему раньше и предотвратить ее повторение.
• Исправление неудачных интеграций является главным приоритетом — команды, которые просто продолжают работать после сбоя интеграции, не соответствуют ценностям и культуре, связанным с созданием системы, которая может быть выпущена в продуктив в любое время. Чтобы создать правильное чувство срочности и важности, необходимое для устранения проблем интеграции, команды часто используют «светофоры» или другие уведомления, чтобы привлечь внимание к сломанной сборке и показать процент времени, в течение которого система остается неисправной.
• Установить общую каденцию — точки интеграции более применимы, когда все команды движутся в одном и том же последовательном ритме. Если полная интеграция не может быть достигнута в ходе итерации, команды могут пойти на краткосрочные компромиссы в отношении того, что может быть интегрировано, постоянно улучшая свои методы и инфраструктуру для достижения этой цели.
• Разработка и поддержка надлежащей инфраструктуры — эффективная непрерывная интеграция зависит от наличия тестовой и предпродуктивной сред. Инфраструктура — это, конечно, инвестиция. Но Лидеры Lean-Agile представляют долгосрочную перспективу и делают инвестиции, необходимые сегодня, чтобы увеличить скорость завтра.
• Применяйте вспомогательные методы разработки программного обеспечения — лучше чтобы система разрабатывалась с ориентиром на непрерывную интеграцию. Разработка и проектирование с подходом «Сначала тесты, потом код» (Test-First) требуют модульных решений, а также использования первичных интерфейсов и физических тестовых точек.

Непрерывная интеграция становится возможной с DevOps

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

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

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

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

См. всю серию роликов о применении SAFe DevOps на практике.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.