📜 Понимание непрерывной интеграции CI и непрерывного развертывания CD

by itisgood

Слышал о CI / CD, но не уверен, что это такое?

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

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

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

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

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

Что происходит, когда они готовы:

  • Они тратят много времени, пытаясь привести в соответствие свой код с изменениями, которые произошли в производственной ветке
  • При этом они должны исправить ряд конфликтов мёржа
  • Существует также возможность того, что они повредят производственную ветку.

Если вы когда-либо были в такой ситуации, вы согласитесь, что это боль -и  никто не любит так проводить свой рабочий день.

Непрерывная интеграция CI

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

Код для интеграции должен пройти тесты, дабы убедиться, что он не нарушает работу приложения.

Только когда тест пройдены, он интегрируется

Чтобы понять это, давайте представим реальный сценарий, в котором есть команда из 10 разработчиков.

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

Далее они делают пулл реквесты после какого либо изменения в коде.

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

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

Прежде чем это новое изменение будет введено, необходимо выполнить серию тестов.

Группы разработчиков программного обеспечения используют такие инструменты, как Travis CI, для создания этих интеграционных процессов и тестов.

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

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

Преимущества придерживаться этого шаблона интеграции кода являются следующие параметры:

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

Типы тестов

Вот некоторые из этих тестов, которые могут быть реализованы в процессе:

  • Интеграционные тесты – объединяет отдельные модули программного обеспечения и тестирует их в виде группы.
  • Unit – это тестирование для отдельных модулей или компонентов программного обеспечения, таких как методы или функции.
  • UI – утверждает, что программное обеспечение работает хорошо с точки зрения пользователя.
  • Приемка – тестирование на соответствие программного обеспечения требованиям бизнеса.

 

Непрерывное развертывание CD

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

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

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

Развертывание происходит только после прохождения этих тестов.

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

  • Автоматизированное тестирование является основой всех непрерывных инженерных практик. В случае непрерывного развертывания код, который необходимо развернуть, должен соответствовать стандарту, установленному командой. В идеале, если новое изменение ниже порогового значения, тест должен завершиться неудачей и не будет интегрирован.
  • Несмотря на автоматические тесты, возможно, некоторые ошибки попадут в производственную среду. Для этого необходимо, чтобы группа могла отменить внесенные изменения – отменить развертывание.
  • Системы мониторинга необходимы для отслеживания изменений, внесенных в производственную среду. Таким образом, команда может отслеживать ошибки, с которыми сталкиваются пользователи при использовании развернутых изменений.

Заключение

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

Чтобы обеспечить их продуктивность, необходимо принять соответствующие меры.

Непрерывная интеграция и развертывание являются примерами такой практики.

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

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

Развертывание этих изменений позволяет получить обратную связь от пользователей.

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

 

You may also like

Leave a Comment