Непрерывная интеграция из мира Agile
Гибкая методология разработки (Agile-разработка) была предшественником DevOps, а следовательно, и непрерывной интеграции, доставки и развертывания, которые вместе обозначаются сокращением CI/CD. Поэтому она тесно связана с этими понятиями. Если вы разберетесь с основными принципами Agile, это поможет эффективнее использовать CI/CD и создать CI/CD-пайплайн, реализующий методологию Agile.
К сожалению, появившиеся за последние годы многочисленные методологии, стратегии и консультанты искажают основные положения Agile и сводят все к бездумному следованию набору правил. Без понимания принципов гораздо сложнее их эффективно применять.
Принципы Agile-разработки
Agile — это в первую очередь мировоззрение, то есть общий взгляд на то, как следует разрабатывать программное обеспечение.
Agile видит главную цель в том, чтобы создавать работающее ПО, и утверждает, что стимулирование изменений и сотрудничества между отдельными людьми позволяет эффективнее достигать этой цели, чем жесткое следование плану в соответствии с заданным набором требований.
Принципы, изложенные в манифесте Agile, отражают эти ценности и предлагают способы их воплощения. Сюда входит создание профессиональных и готовых к сотрудничеству команд и доставка ПО на основе коротких циклов, позволяющих команде быстро реагировать на изменения.
Логика проста: если мы раз и навсегда устанавливаем жесткие требования и строго следуем плану, то теряем гибкость и не можем адаптировать продукт к новым обстоятельствам по мере того, как лучше узнаем ситуацию, а также при изменении требований пользователей. Agile-подход предполагает наличие конечной цели и гибкий выбор путей для ее поэтапного достижения.
Реализация принципов Agile-разработки с помощью CI/CD
Принципы Agile-разработки стали основой для формирования методологии DevOps, из которой в свою очередь выросла CI/CD.
В центре внимания методологии Agile-разработки, по крайней мере, на первом этапе ее существования, была деятельность групп разработчиков. DevOps идет дальше и охватывает также последующие рабочие процессы — от написания кода до релиза.
DevOps подчеркивает важность преодоления разобщенности и сотрудничества между разными командами для достижения единой цели: доставки пользователями удобного работающего ПО. Непрерывная интеграция, доставка и развертывание представляют собой практическую реализацию методологии DevOps для ускорения релиза ПО без ущерба для качества.
За счет автоматизации максимального числа шагов система непрерывной интеграции позволяет быстро получать обратную связь по новым сборкам, сокращая время доставки программного обеспечения пользователям.
С учетом истории Agile и DevOps неудивительно, что многие элементы пайплайна сборки помогут вам придерживаться принципов Agile-разработки. Начнем с того, что рекомендация «делать коммиты быстро и часто» стимулирует разделение работы на небольшие отрезки.
Разделение функций на небольшие части необходимо для цикличного процесса сборки и выпуска ПО. Цель заключается в том, чтобы после каждого коммита сборка могла пройти все этапы CI/CD-процесса и быть готова к релизу. Таким образом, каждый коммит должен приводить к созданию работающего продукта. Реализация такого подхода поможет сосредоточиться на создании работающего ПО.
И Agile, и DevOps подчеркивают важность совместной работы и коммуникации. Хотя первоначально в центре внимания DevOps была совместная работа разработчиков и операционных команд, преимущества этой методологии гораздо шире.
Включив предпроизводственные среды в пайплайн сборки и контролируя изменения в сборках с помощью панелей мониторинга, можно делиться информацией о ходе работе с другими командами и отделами (например, маркетологами, дизайнерами или специалистами по безопасности) и запрашивать у них обратную связь.
Центральное место в любом CI/CD-пайплайне занимают автоматические тесты, которые позволяют быстро получить обратную связь по изменениям кода и гарантировать качество сборки. Для доставки работающего продукта очень важно выполнять автоматические тесты для каждого коммита.
Среди принципов Agile одно из первых мест занимает частая доставка ПО пользователям. CI/CD- пайплайн играет ключевую роль в реализации этого принципа. Автоматизация этапов процесса выпуска ПО позволила разработчикам ускорить работу и доставлять изменения каждый день или даже каждый час: гораздо чаще, чем можно было предположить в то время, когда писался манифест.
Наконец, непрерывные циклы получения обратной связи, которые и составляют суть CI/CD-пайплайна, обеспечивают непрерывное улучшение не только разрабатываемого ПО, но и самого рабочего процесса. Тем самым реализуется принцип Agile, который гласит: команда должна регулярно анализировать свою работу и при необходимости корректировать ее. Циклическое создание сборок и получение обратной связи помогает поддерживать стабильный темп работы, о чем говорится в манифесте.
Построение Agile-организации
Хотя создание CI/CD-пайплайна может способствовать развитию образа мышления в духе Agile, это тоже не панацея, как и основанные на принципах Agile методологии и решения, возникшие за время существования Agile.
При этом в CI/CD-методологии регулярно встречаются такие схемы работы, которые очень далеки от настоящего Agile.
Частым препятствием на пути эффективной работы пайплайна сборки и внедрения принципов Agile становится использование различных ручных этапов в процессе подготовки релиза. Это может быть утверждение изменений экспертной группой или требование представить подробное описание изменений и оценки рисков перед развертыванием новой сборки в производственной (или даже тестовой) среде.
Обычно такие процедуры внедряются для дополнительного контроля релизов. Однако они значительно тормозят процесс и не учитывают задачи автоматического тестирования, которое должно гарантировать качество сборки.
Чтобы рассеять опасения сомневающихся, можно продемонстрировать надежность CI/CD-пайплайна с помощью метрик. В то же время панели мониторинга и автоматические уведомления могут избавить вас от большого объема ручной работы, информируя все заинтересованные стороны о том, какие изменения проходят пайплайн.
Еще один частый признак неблагополучия — появление запросов на замедление процесса и объединение изменений для уменьшения частоты релизов.
Объединение изменений и выпуск релизов раз в неделю или в две недели — разумный вариант для некоторых продуктов. Однако при более длительных интервалах вы рискуете потерять преимущества, которые дает развертывание изменений в производственной среде, поскольку полученную обратную связь можно использовать при дальнейшей разработке.
Объяснив принципы, на которых построены методологии Agile и DevOps, а также CI/CD, и получив согласие от всех заинтересованных сторон, можно упростить переход к их использованию.
Одно из главных препятствий для внедрения как CI/CD, так и Agile — недоверие, и как следствие — отсутствие у команд полномочий на выполнение необходимых действий. Если для принятия решений или внесения изменений нужно пройти многоступенчатую процедуру утверждения, это замедляет процесс и уменьшает пользу от быстрого фидбэка.
Если же команда получает необходимые полномочия, разработчики должны доставлять работающий продукт, а руководители — предоставить им необходимые инструменты и среды для выполнения работы.
Подводя итог
Многие ошибочно считают, что методология Agile — это некий заданный набор правил, которые нужно определенным образом выполнять. Если вы поймете ее базовые принципы и внедрите их в своей организации, не забывая при этом о неправильных схемах работы, то сможете принять Agile-подход к непрерывной интеграции.
Внедрение CI/CD-методологии поможет на практике реализовать принципы Agile и начать пользоваться преимуществами коротких циклов разработки и частых релизов.