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

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


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

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

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

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

Какое решение?

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

https://www.youtube.com/watch?v=HnWuIjUw_Q8

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

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

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

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

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

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

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

Типы тестов

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

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

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

Инструменты непрерывной интеграции

Не вдаваясь в подробности, вот инструменты, которые вы можете начать использовать в своих текущих или новых проектах;

  • Трэвис CI – известен в мире открытого кода и обещает, что ваш код будет протестирован без проблем за считанные минуты.
  • Круг CI – предоставляет вам мощность, гибкость и контроль для автоматизации вашего конвейера от контроля до развертывания.
  • Дженкинс – предоставляет сотни плагинов для поддержки создания, развертывания и автоматизации любого проекта.

Если вы новичок в Дженкинс, то я бы предложил взять это Курс удэми изучить CI с помощью Java и .NET.

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

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

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

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

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

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

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

Вывод

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

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

Если вы разработчик и заинтересованы в изучении CI / CD, проверьте это блестящий курс.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map