Давайте погрузимся в мир конвейеров CI / CD!

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

Тем не менее, если вас интересует CI / CD, созданный для современной веб-разработки. Я бы посмотрел наши статьи о Google Cloud Build.

Что мы расскажем:

  • Что такое CI / CD?
  • Почему вам следует использовать CI / CD?

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

Что такое CI / CD?

Честно говоря, CI / CD на самом деле представляет собой комбинацию двух разных концепций.

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

Первый называется CI (Непрерывная интеграция) и представляет собой мощный способ непрерывного построения и тестирования вашего кода. Обычно процесс запускается при обновлении SCM (Диспетчер исходного кода). После срабатывания триггера ваш CI начнет создавать ваше приложение, а затем запускать тесты и другие операции для всего вашего приложения.

Примеры шагов:

  • Код клонирован из SCM (например, GitHub)
  • Сборка скриптов, создание новой версии вашего приложения
  • Новая версия отжата в виде серии автоматических тестов и других специфичных для приложения операций.

Преимущества:

  • Автоматическое выполнение набора тестов от триггера SCM
  • Меньше откатов производства из-за раннего выявления проблем

Непрерывная доставка

Второй называется CD (Непрерывная доставка), это мощный способ непрерывного развертывания вашего кода в реальном времени для конечных пользователей или в различных средах (например, dev, QA, prod). Подобно CI, процесс запускается обновлением SCM. Затем будет запущена серия операций, полностью настраиваемых вашей командой. Эти операции обычно упакованы в серию сценариев bash (например, bash, python), которые обрабатывают взаимодействие с вашими поставщиками услуг.

Если вы хотите глубже погрузиться в сценарии python bash, которые ОЧЕНЬ мощны. Ознакомьтесь с этой статьей Избавление от bash с заменой сценариев оболочки на python. Отличная статья!

Примеры шагов:

  • Код клонирован из SCM (например, BitBucket)
  • Сборка скриптов, создание новой версии вашего приложения
  • Новая версия отправляется / синхронизируется / загружается на ваш хостинг-провайдер и заменяет старую версию вашего приложения.

Преимущества:

  • Автоматизированный процесс развертывания (меньше человеческих ошибок)
  • Выпускайте новые версии вашего приложения быстро!

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

Почему вам следует использовать CI / CD?

Надеюсь, объяснение концепций выше. Достаточно убедительны, чтобы заставить вас задуматься о добавлении этого в список невыполненных задач вашей команды. Если нет, давайте подумаем, что происходит, когда у вас есть CI / CD, а когда нет.

С CI / CD:

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

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

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

Без CI / CD:

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

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

Как это произошло?

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

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

Вы можете подумать, а почему бы им не сгруппировать все свои тесты в серии, чтобы один разработчик не совершил эту ошибку? Ты прав. Однако такие маленькие ошибки случаются постоянно, и именно здесь в игру вступает сила CI / CD. CI / CD дает вам единое место для постоянного улучшения вашего процесса.

Если бы у этой команды вместо этого был CI / CD. Для CI / CD должен быть предусмотрен процесс усиления для тестирования, который будет применяться каждый раз, когда вводится новый код. Независимо от того, что разработчик сделал или не сделал, локально. Команда также могла бы снова пропустить повторное развертывание приложения вручную. Поскольку развертывание приложения также будет усиленным и автоматически будет инициировано push на их SCM.

Наконец, с добавлением CI / CD. После развертывания у вас может быть дополнительное тестирование (например, дымовые тесты), которые затем будут использовать ваши настоящие службы (а не локальную версию) для проверки успешности развертывания, отправив ваш / signUp конечная точка - полезная нагрузка для нового пользователя. Если это не удастся, с вашим новым блестящим CI / CD вы также можете включить возможность отката, который переместит стрелку от вашей последней версии к «последней заведомо удачной» версии. Это Святой Грааль.

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

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

Дополнительный контент:

Что делает Serverless Guru?

Serverless Guru помогает компаниям создавать масштабируемые и экономичные приложения в облаке. Мы помогаем обучать компании тому, как использовать IAC, бессерверные и облачные сервисы. Мы помогаем перенести существующие приложения в облако и оптимизировать существующие приложения в облаке, чтобы сделать их более рентабельными. Мы являемся партнером по бессерверной разработке и партнером-консультантом AWS.

Что мы упустили?

Когда вы оставляете свой ответ, обязательно оставьте комментарий ниже или напишите свой ответ @serverlessgurux в Twitter.

Райан Джонс

Основатель - Serverless Guru

LinkedIn - @ryanjonesirl

Twitter - @ryanjonesirl

Спасибо за чтение 😃

Если вы хотите узнать больше о Serverless Guru, подпишитесь на нас в Medium, Twitter, Instagram, Facebook или LinkedIn!