Введение в CI/CD с Nginx и Nginx Plus (часть 2)

Введение в CI/CD с Nginx и Nginx Plus

(продолжение, начало читать здесь)

Подробное рассмотрение шагов в CI/CD

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

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

Управление исходниками

Хотя ни одно из этих конкретных изменений не есть абсолютно необходимое, полный переход к CI/CD может полностью обновить то, что делает разработчик:

  • Архитектура приложения, скорее всего, перейдет к микросервисам – с небольшими кусками кода (потенциально написанными на разных языках), которые управляют собственными хранилищами данных (где это необходимо), и взаимодействуют с другими службами через API.
  • Управление исходным кодом может перейти на Git или аналогичные инструменты, которые предоставляют совместный доступ к коду и легкому управлению изменениями из нескольких источников.
  • Код может быть – и, более вероятно, будет! – разработан и внедрен в контейнерах, изолирующих его от деталей какой-либо конкретной среды разработки, тестирования или продакшен-окружения.
  • Код часто изменяется – от мажорных до минорных обновлений
  • Процесс разработки, вероятно, станет полностью гибким – двух-недельные спринты с ежедневными совещаниями по две “пицца-команды”
dia-kj-2017-06-1-source-test-monitor_2

В целом, переход к CI/CD может кардинально изменить рабочие обязанности и повседневную жизнь разработчика. Вместо того, чтобы десятки людей совместно владели и управляли мегабайтами кода – один или два человека будут управлять кодом в пределах килобайта. Разработчик, таким образом, становится DevOps-профессионалом, с обязанностями, которые простираются от первоначальной разработки кода – до контроля за тестирование и развертыванием (деплоем), чтобы отвечать на телефонный звонок в полночь для исправления проблем с деплоем.

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

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

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

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

dia-kj-2017-06-1-source-test-monitor_3

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

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

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

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

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

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

Тестирование

Тестирование сильно меняется в среде CI/CD. Тестирование того или иного рода происходит по всему механизму CI/CD. Этап тестирования относится к одному или двум конкретным видам испытаний:

  • Автоматизированные приемочные тесты . Многие программные среды, в которых не реализовано CI/CD, включают некоторую степень автоматизации приемочных испытаний. В CI/CD, операционная команда стремится постоянно укреплять этот и другие этапы тестирования для отбраковки любого кода , который не готов к продакшену. Разработчики должны активно взаимодействовать с командой, которая управляет автоматизированными приемочными испытаниями, чтобы сделать испытания по месту эффективными и способными уловить проблемы с критическими частями приложения.
  • Приемочные испытания пользователями (UAT). Это возможность определить изменения программного обеспечения для пользователей в реальном сценарии, прежде чем изменения будут развернуты. Тем не менее, этот шаг является спорным , поскольку он требует участия человека в цепочке CI/CD. Многие сайты минимизируют или устраняют этот шаг в пользу более сильного автоматизированного тестирования, в то время как другие используют тестирование на людях, чтобы проверить реакцию пользователей и оценить влияние на бизнес потенциальных проблем.
dia-kj-2017-06-1-source-test-monitor_4

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

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

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

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

Производительность или тестирование развертывания

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

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

dia-kj-2017-06-1-source-test-monitor_5

В итоге

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

NGINX и NGINX Plus в этом случае выступают важными компонентами эффективной системы CI/CD.

Уверенно освоить все инструменты стека методик CI/CD вы всегда можете на нашем авторском курсе “L3-DevOps”.

Залишити відповідь

Дякуємо, що поділились