При Continuous Integration происходит автоматическая сборка и проверка новых кусочков кода. Непрерывная интеграция подразумевает полное исключение человека из  процессов сборки и деплоя.

Можно на ранней стадии обнаружить проблему и исправить ее до слияния нового кода с основной веткой.

Самые популярные — TeamCity и Jenkins. Вы также можете использовать внутренние системы платформ GitHub и GitLab.

Continuous integration она же непрерывная интеграция — это автоматическая сборка и проверка новых кусочков кода.

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

По сути Continuous integration — это ядро всех процессов. Непрерывная интеграция подразумевает полное исключение человека из процессов сборки и деплоя (развертывания, то есть помещения нового кода на сервер, где он будет работать).

Continuous integration представляет собой приложение или систему для автоматизации.

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

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

• модули приложения
• интерфейс
• производительность.

Так что, если что–то вызовет ошибку и тесты это покажут, то команда узнает об этом до того, как выкатит релиз или все запустит в работу. Зато успеет вовремя поправить. Непрерывная интеграция работает как страховка

Система непрерывной интеграции сама забирает новый код из хранилища (репозитория). И тут есть два варианта, как этот процесс настроить.

• Continuous integration в определенное время будет отправлять запрос в хранилище: «Нет ли для меня чего новенького?».
• Хранилище само вызывает приложение: «У меня обновление, получите — распишитесь».

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

Затем пройдут автотесты. И если на каком–то этапе что–то пойдет не так (не получится собрать проект, или тесты выдадут ошибку), то все заинтересованные лица (например, разработчик, чьи изменения привели к ошибке, менеджер проекта) получат информацию об этом, ну и по шапке, конечно.

Тестирование билда (тот самый двоичный файл с исполняемым кодом) должно происходить максимально быстро. Это нужно, чтобы непрерывная интеграция в принципе имела смысл.

В идеале длительность тестирования не должна превышать 10 минут.

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

Осталось разобраться, как и где Continuous integration проводит такой сумасшедший объем работы, да еще и так быстро.

Сама система (а их есть много разных, подробнее остановимся на них дальше) код не собирает и не тестирует. Это делают другие машины — компьютеры или виртуальные серверы, так называемые «агенты».

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

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

Это удобно, потому что одна машина может подвести из–за сбоя или каких–то настроек. А другая отлично справится.

Либо часть «агентов» работает на Виндовс, другая — на Линукс. Какие нам нужны, таких и выбираем.

Для удобства системный администраторы дают машинам свои имена.

На практике это может выглядеть так: сисадмин покупает компьютеры и устанавливает на них клиентское приложение системы для непрерывной интеграции. Эти компьютеры будут делать сборку и прогонять тесты. На другом компьютере будет сервер, с которого будут раздавать задания и с него же оценивать результаты.

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

• Если задачи в списке запущены автоматически, то можно их и подвинуть. Это плановая проверка.
• А если задача прилетела от человека, то придется подождать.

• Можно на ранней стадии обнаружить проблему и исправить ее до слияния нового кода с основной веткой.
• Улучшается коммуникация между командой за счет улучшенной визуализации.
• Баги получается искать быстрее.
• Не надо сидеть и ждать, пока закончиться тест кода. Можно работать над новым куском.
• Много обратной связи по изменениям. Это поможет улучшить продукт.

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

• TeamCity — этот сервис поддерживает большое количество мощного функционала. Есть бесплатная версия для небольших проектов. Надежен. Не зависит от запуска сборок. У сервиса понятная интеграция с системами контроля, отличается высокой надежностью, не зависящей от запуска сборок. Можно запускать команды удаленно.
• Jenkins — инструмент на Java с открытым исходным кодом. Можно тестировать код в реальном времени, создает отчеты об отдельных изменениях в кодовой базе. Подходит для быстрых пометок и исправлений ошибок и багов в коде. Настраивается достаточно просто. Доступен на Linux, Mac и Windows.
• Codeship — инструмент для непрерывной интеграции, позволяет автоматизировать разработку и развертывание. Позволяет настроить уровни доступа участников команды для каждого проекта. Есть функция отладки прямо из среды непрерывной интеграции. Удобная панель инструментов.
• Travis — это веб–ресурс. Его можно использовать бесплатно проектам с открытым исходным кодом. Поддерживает довольно много языков программирования, в том числе Node и PHP. Легко настраивается и интегрируется со Slack, HipChat, электронной почтой. Для сборки использует виртуальные машины. Можно запускать параллельное тестирование.

Continuous integration — это только первый шаг большого автоматизированного конвейера. Разработка тут ведется в своих отдельных (локальных) ветках, затем все изменения вливаются в основную ветку. Все сборки и тестирования запускаются автоматически и занимают не больше 10 минут. Остальное развертывание запускается вручную.

Кроме этого шага есть еще:

Continuous delivery — непрерывная доставка. Здесь процесс непрерывной интеграции полностью автоматизирован. Как и процесс сборки релиза. А вот развертывание в продакшн происходят вручную.

Continuous deployment — непрерывное развертывание. В этом случае предыдущие два этапа (Continuous integration и Continuous delivery) полностью автоматизированы. А также автоматизирован процесс развертывания версии продукта на компьютере клиента или виртуализированной операционной системе. Чтобы ее мог оценить клиент.

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

Концепция Ci/Cd используется в большей или в меньшей степени абсолютно во всех проектах.

Процессы Continuous integration, Continuous delivery и Continuous deployment не исключают друг друга. По своей структуре они больше напоминают матрешку.

• Continuous integration — это самая маленькая, нижний уровень.
• Continuous delivery — средняя.
• Continuous deployment — самая большая матрешка, внешний уровень.

Главная цель всех этих процессов — повысить надежность разработки, сделать релизы более стабильными и уменьшить время разработки.

• Первый шаг — сам код. Его пишут, покрывают тестами.
• Второй шаг — build. Система непрерывной интеграции автоматически собирает изменения и обновления и отправляет их на тестирование.
• Третий шаг — ручной тест. Он наступает после автоматического тестирования.
• Четвертый шаг — релиз. Команда тестировщиков проверила все изменения, и получила стабильную версию продукта (с исправленными критическими ошибками). Ей присваивается номер. И теперь эта версия именуются релиз кандидатом.
• Пятый шаг — деплой. Развертывание версии продукта на компьютере клиента или виртуализированной операционной системе. Чтобы ее мог оценить клиент.
• Шестой шаг — мониторинг. Следим за развернутой версией продукта и в случае чего стабилизируем ее или чиним неполадки. Ведь всегда остается риск, что что–то может сломаться.
• Седьмой шаг — планирование новых функциональностей продукта или сбор данных для корректировки следующих релизов.

Так работает процесс поставки продукта от стадии написания кода новой функции до использования этого обновления клиентами.

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

Организуется этот процесс по–разному. Например, с помощью больших мониторов в центре открытого офиса. На них выводится информация о состоянии билдов.

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

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