Внедрение непрерывной интеграции в компании

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

Фаза 1 – отсутствие серверов сборки

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

Фаза 2 - Тестовая версия

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

Фаза 3 - Тестовая версия и основные автоматизированные тесты

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

Фаза 4 - Объявление метрик

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

Фаза 5 - Введение более серьезного тестирования

Преимущества непрерывной интеграции тесно связаны с надежностью тестирования. Теперь, такое тестирование, как Test-Driven Development, практикуется более широко, в результате растущего доверия к результатам автоматизированной сборки. Приложение уже не просто скомпилировано и протестировано, но если тесты проходят, то оно автоматически размещается на сервере приложений для более комплексных end-to-end тестов и тестов производительности.

Фаза 6 - Автоматизированное приемочные испытания и прочее автоматическое развертывание

Приемочное тестирование(Acceptance-Test Driven Development) широко применяется, сопровождая процесс разработки и предоставляя отчетность о состоянии проекта на высоком уровне. Эти автоматизированные тестовые инструменты Behavior-Driven Development и Acceptance-Test Driven Development используются в качестве связи, и средств генерирования документации так же часто, как и инструменты тестирования, публикуя отчеты по результатам тестов с использованием бизнес-терминов, которые разработчики не могут понять. Так как эти тесты автоматизированы на высоком уровне на ранней стадии процесса разработки, то они также обеспечивают четкое представление о том , какие функции были реализованы , а какие еще ​​предстоит сделать. Приложение автоматически размещается в тестовой среде для тестирования командой QA после внесения изменений, или ночью. Команда также способна использовать сервер сборки, чтобы выпустить релиз , сделать откат к предыдущей версии , если что-то пойдет не так .

Фаза 7 - Непрерывное развертывание

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

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