Слышали о CI/CD, но не знаете, что это такое?
В идеале инженеров-программистов нанимают для написания кода, который необходимо отправить в производственную среду, чтобы компания, которой нужен продукт, могла его использовать. Чтобы удовлетворить бизнес (часто называемый пользователями/клиентами), важно, чтобы продукты не содержали ошибок.
Типичный подход, которого придерживаются инженеры-программисты, заключается в работе в ветках и создании запроса на включение, который обновляет главную ветку новым сделанным обновлением. Мы переняли практику написания тестов как средство гарантировать, что новые изменения не приведут к появлению ошибок. Когда разработчики в большинстве случаев работают над функцией, они часто не создают запрос на включение до тех пор, пока полностью не завершат работу с этой функцией. Вот что происходит, когда они готовы;
- Они тратят много времени, пытаясь привести свою кодовую базу в соответствие с изменениями, которые произошли в производственной ветке во время их работы.
- При этом им придется исправить серию конфликтов слияния.
- Существует также вероятность того, что они сломают производственную ветку, что повлияет на тех, кто выйдет из ветки до того, как проблема будет обнаружена и устранена.
Если вы когда-либо оказывались в такой ситуации, вы согласитесь, что это может быть неприятно — никто не хочет проводить свой рабочий день вот так.
Какое решение?
Непрерывная интеграция
Чтобы предотвратить сценарии, о которых я говорил выше; команды разработчиков могут применять практику, называемую непрерывной интеграцией . Как следует из названия, она предполагает непрерывную интеграцию изменений кода, внесенных разработчиками, в общую ветку/репозиторий. Код, который будет интегрирован, должен пройти проверенное тестирование, чтобы убедиться, что он не нарушает работу приложения. Только когда тест пройден, он интегрируется
Чтобы понять это, давайте представим себе реальный сценарий, в котором есть команда из 10 разработчиков. Эти разработчики создают локально ветку, в которой пишут код для реализации тех или иных функций. Вместо того, чтобы отправлять запросы на включение, когда они полностью закончили работу с этой функцией, они предпочитают отправлять запросы на включение, когда они вносят небольшие изменения. Примером такого изменения будет создание нового модального окна, при условии, что разработчик работает над функцией, позволяющей пользователям управлять отдельными задачами в приложении. Вместо того, чтобы ждать завершения функции задачи, чтобы придерживаться шаблона непрерывной интеграции, разработчик вносит это небольшое изменение (по сравнению с тем, над чем он работает) и создает запрос на включение для слияния с кодом.
Прежде чем это новое изменение будет интегрировано, необходимо провести серию тестов.
Команды разработчиков программного обеспечения используют такие инструменты, как Travis CI, для создания этих интеграционных процессов и тестов. С помощью подобных инструментов тесты автоматизируются, поэтому они запускаются, как только запрос на включение отправляется в целевую ветку, выбранную во время установки.
Результаты тестов генерируются, и разработчик, создавший запросы на включение, может увидеть результаты и внести необходимые изменения. Преимущества придерживания этого шаблона минимальной интеграции кода и наличия проверенного теста для запуска:
- Участвовавшая команда может узнать, что привело к сбою процесса сборки или теста. Это снижает вероятность отправки ошибки в производство.
- Если команда автоматизирует процесс, у них будет роскошь времени, чтобы сосредоточиться на продуктивности.
В этой практике важно отметить, что она побуждает команду часто отправлять код в основную ветку. Это будет неэффективно, если другие члены команды не будут использовать основную ветку для обновления своего локального репозитория.
Виды тестов
При написании тестов, которые станут частью процесса интеграции, вот некоторые из них, которые можно реализовать в этом процессе:
- Интеграция – объединяет отдельные блоки программного обеспечения и тестирует их как группу.
- Модуль – он тестирует отдельные модули или компоненты программного обеспечения, такие как методы или функции.
- Пользовательский интерфейс – утверждает, что программное обеспечение работает хорошо с точки зрения пользователя.
- Приемка – проверка соответствия программного обеспечения бизнес-требованиям.
Важно отметить, что вам не нужно тестировать все из них, поскольку некоторые из них уже могут быть описаны в коде, написанном разработчиком.
Инструменты непрерывной интеграции
Не вдаваясь в подробности, вот инструменты, которые вы можете начать использовать в своих текущих или новых проектах;
- Travis CI – известен в мире открытого исходного кода и обещает, что ваш код будет легко протестирован за считанные минуты.
- Circle CI — предоставляет вам мощность, гибкость и контроль для автоматизации вашего конвейера от контроля до развертывания.
- Jenkins — предоставляет сотни плагинов для поддержки создания, развертывания и автоматизации любого проекта.
Если вы новичок в Jenkins, я бы посоветовал пройти этот курс Udemy, чтобы изучить CI с Java и .NET.
Непрерывное развертывание
Какая польза от того, что создаваемая вами функция будет находиться в репозитории неделями или месяцами, прежде чем будет развернута в производственной среде. Поскольку инженерные группы могут работать над интеграцией небольших изменений в основную ветку по мере их возникновения, они также могут как можно скорее перенести эти изменения в производственную среду.
Целью практики непрерывного развертывания является доведение внесенных изменений до пользователей, как только разработчики интегрируют эти изменения в основную ветку.
Как и в случае с непрерывной интеграцией, при использовании непрерывного развертывания настраиваются автоматические тесты и проверки, обеспечивающие проверку вновь интегрированных изменений. Развертывание происходит только после прохождения этих тестов.
Чтобы команда могла извлечь выгоду из практики непрерывного развертывания, ей необходимо иметь следующее:
- Автоматизированное тестирование является основой всех методов непрерывного проектирования. В случае непрерывного развертывания развертываемый код должен соответствовать стандарту, установленному командой для того, что они собираются предлагать конечным пользователям. В идеале, если новое изменение ниже порогового значения, тест должен провалиться и не интегрироваться. В противном случае он становится интегрированным.
- Несмотря на то, что автоматические тесты проводятся подряд, некоторые ошибки могут проникнуть в производственную среду. Для этого необходимо, чтобы команда имела возможность отменить внесенное изменение – отменить развертывание. Это должно вернуть производственный код к тому состоянию, в котором он был до внесения нового изменения.
- Системы мониторинга необходимы для отслеживания изменений, внесенных в производственную среду. Таким образом команда сможет отслеживать ошибки, с которыми сталкиваются пользователи при использовании развернутых изменений.
Инструменты, упомянутые для непрерывной интеграции, также предоставляют вам функциональные возможности для настройки системы непрерывного развертывания. Их много, о которых вы также можете прочитать.
Заключение
Продуктивность команды разработчиков жизненно важна для успеха бизнеса. Чтобы обеспечить их продуктивность, необходимо применять практики, способствующие этому. Непрерывная интеграция и развертывание являются примерами такой практики.
Благодаря непрерывной интеграции команды могут ежедневно добавлять как можно больше кода. Благодаря этому становится легко как можно скорее развернуть добавленные изменения для пользователя. Развертывание этих изменений позволяет получить обратную связь от пользователей. В конце концов, бизнес сможет внедрять инновации на основе полученных отзывов, что является беспроигрышным вариантом для всех.
Вы также можете узнать, как масштабировать и оптимизировать CI/CD.
Если вы разработчик и заинтересованы в изучении CI/CD, обратите внимание на этот замечательный курс.