Почему agile не может существовать без непрерывной поставки

Поставка по итогам каждого спринта — вполне достижимый результат. Мы расскажем, что для этого нужно.

Иэн Бьюкэнэн Иэн Бьюкэнэн

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

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

Близость вашего процесса к #agile определяется тем, как часто вы можете поставлять продукт, не теряя спокойствия.

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

Жизнь в непрерывной нервотрепке

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

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

Ошибка | CI/CD Atlassian

Если эта ситуация вам знакома до боли, знайте, что надежда есть.

Подумайте о том, как подход «проверка и адаптация» улучшил ваш процесс планирования, а затем распространите его на процессы разработки и поставки. Представьте, что можно выявлять проблемы в каждом выполненном коммите. А теперь представьте, что вы можете обнаруживать проблемы на своей локальной рабочей станции даже до того, как сделаете коммит. То, что вы сейчас представили, — это главные причины, по которым для подхода agile нужна непрерывная поставка: разработчикам требуется быстрая обратная связь.

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

Начните со скрипта и сервера

Раньше использовали только Make, но многие разработчики натыкались на баги из-за лишних пробелов. Позже в Ant вместо пробелов появились угловые скобки. Но использовать эти устаревшие инструменты не обязательно. Конечно, все равно существует множество проектов с открытым исходным кодом, где применяется Maven или даже Ant. Спишем это на старые привычки. А в качестве запасного варианта всегда можно прибегнуть к языкам сборки на основе XML.

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

Таблица языков программирования и рекомендуемых инструментов | Atlassian CI/CD

«Непрерывность» непрерывной поставки означает получение обратной связи при каждом коммите. Именно поэтому серверы сборки автоматически отслеживают состояние вашего репозитория и запускают сборку, когда происходят какие-либо изменения. «Непрерывность» — это также выпуск фиксов для сборки, если происходят сбои. Как разработчик, вы получаете преимущество от изоляции изменений. Лучший способ не дать баг-фиксам стать слишком сложными и громоздкими — не давать им накапливаться. Серверы сборки, такие как Bamboo, легко устанавливать. Изначальная цель заключается в простом выполнении скрипта сборки в чистой среде. По сути, сервер сборки прежде всего помогает вам выявлять проблемы в скрипте сборки.

Используйте автоматическое обнаружение проблем

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

Давайте закончим спор: автоматическое тестирование НЕ представляет угрозы для специалистов, выполняющих ручное тестирование.

На самом деле, специалисты-тестировщики дают отличные подсказки, когда речь заходит о том, что нужно автоматизировать (а что нет). Разумная стратегия автоматизации должна исходить из вопроса: «Какие проблемы обнаружить наиболее важно?» Чтобы ответить на него, потребуются опытные люди, которые специализируются на обеспечении качества ПО.

Начало непрерывной поставки

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

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

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

продолжение темы
Конвейер