Непрерывная интеграция и доставка: лучшие практики

Cloud Server, VPS | Amber | Комментировать запись

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

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

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

Поддерживайте высокую скорость конвейеров

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

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

Изолируйте и защитите среду CI/CD

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

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

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

Настройте конвейер CI/CD как единственный способ развертывания в производство

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

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

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

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

Старайтесь дублировать особенности среды производства в тестовой среде

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

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

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

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

Выполняйте одну сборку кода и передавайте результат по конвейеру

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

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

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

Запускайте быстрые тесты раньше

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

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

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

Минимизируйте ветвление в системе контроля версий

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

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

По сути, ветки, которые не отслеживаются вашей системой CI/CD, содержат непроверенный код, который следует рассматривать как риск для вашего проекта. Уменьшение количества веток позволяет использовать сильные стороны системы.

Проводите локальное тестирование, прежде чем запускать код в конвейер CI/CD

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

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

По возможности проводите тесты в эфемерных средах

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

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

Заключение

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