Непрерывная сборка – это не непрерывная интеграция

Перевод статьи Дэна Норта - "Continuous Build is not Continuous Integration"

Автоматические сборки стали краеугольным камнем Agile-разработки. Каждый раз, когда разработчик чекинит изменения, инструмент вроде Cruise Control проверяет все исходники, все собирает, запускает все модульные тесты и немедленно отчитывается о результатах. Этот цикл стал известен как Непрерывная Интеграция благодаря основополагающей статье Martin Fowler и Matt Foemmel, но на самом деле это неподходящее название. Было бы лучше описать этот процесс как Непрерывная Сборка. Использование ими слова «интеграция» означало объединение всех кусочков ПО, когда различные программисты команды, работающие традиционно, то есть, изолированно друг от друга, собираются и проводят дни или недели вместе, чтобы заставить всё работать. В таких практиках, как парное программирование и автоматизированные сборки есть всё, кроме интеграционного ада. По крайней мере, в Agile-проектах.
Однако, поставка приложений – это больше, чем просто написание и тестирование ПО. Код живет в контейнере или на сервере приложений, которые работают в операционной системе, на оборудовании, в сети, за файерволлом, связанные с другими машинами, сервисами или компонентами, которые могут находиться внутри контейнеров или серверов приложений и так далее, через ваши приложения, через ваше предприятие и, возможно, наружу в большой мир, к другим предприятиям и серверам.
Интеграция на уровне приложений – сложная бестия. Она затрагивает, склеивая вместе, все компоненты приложения, такие как базы данных, инфраструктуры обмена сообщениями, внешние сервисы, входящие-исходящие каналы и зависимости от стороннего ПО.
Тестирование интеграции тоже может быть автоматизировано
Большая часть сюрпризов и рисков ожидает вас тогда, когда вы перейдете от разработки ПО к разворачиванию его в «продакшн». Если вы сможете тестировать эту интеграцию в самом начале проекта, и итеративно развивать это тестирование по мере того как ваши требования и система эволюционирует, со временем вы окажетесь в гораздо более выгодном положении. Во-первых, вы удостоверились, что все кусочки паззла сложились. В дополнение к тому, вы теперь попрактиковались в интегрировании и разворачивании несколько раз и автоматизировали скучные/повторяющиеся/склонные к ошибкам части, а потому вы уже не будете этого бояться.
Отовсюду приходят свидетельства успеха автоматизированных сборок, так что мы даже стали обдумывать автоматическую верификацию инфраструктурных частей. Конечно, есть независимая ценность в обладании постоянной автоматической сборкой, которая собирает твой код и изолированно тестирует его, о чем свидетельствую бесчисленные Agile-проекты. Но не позволяйте термину «Непрерывная Интеграция» ослепить вас в отношении того факта, что вы можете автоматизировать также и собственно интеграцию, и взяться за наиболее рискованные участки проекта ПО заведомо и развивать последовательно.
Разворачивайте в продакшн также, как при разработке
Приятным результатом автоматизации интеграции и применения вашего приложения в среде разработки является то, что его внезапно становится гораздо проще применить в любой среде. Так почему бы не поделиться любовью? Мой опыт развёртки приложения и проверки того, что оно развернуто корректно и работает, традиционно связан с высокими рисками, высоким уровнем стресса, случаями, когда надо скрестить пальцы, с героическими хлопцами, которые работают до поздней ночи, чтобы исправить файервол/сервер/разрешение/ версию JDK/DNS/аккаунт пользователя/число портов/роутеров/ваш-вариант.
Представьте себе качество жизни и последующий водопад маленьких подарков, которые будут сопровождать полностью автоматизированный, протестированный процесс развёртки продукта. Чтобы не солгать, это реально сделает день релиза антикульминационным, и вы почувствуете, что заслужили карри или пиццу на субботней вечеринки. (Давайте признаем это, вы сможете нажать на КНОПКУ сидя дома – вы знаете, что всё будет работать, потому что вы уже проверили окружение и вы разворачивали своё приложение буквально сотни раз до этого).
Chief technology officer "Один Сервис.ВЦ" - Денис Олейник