Мы используем CI/CD во всех проектах компании последние четыре года, а избирательно начали применять восемь лет назад. Мы научились применять эту практику для ускорения темпа интеграции функций в программное обеспечение с сохранением высокого качества кода. Если вы хотите внедрить практику CI/CD в свое производство, ознакомьтесь с перечисленными далее факторами, которые принципиально влияют на ее полезность. Без учета этих факторов внедрение CI/CD вряд ли будет эффективным и не принесет пользу проекту. Мы смогли выделить эти факторы успеха после нескольких лет хождения по граблям, вам они могут помочь сократить затраты и не совершить типичных ошибок.
Заинтересованность участников проекта
Если участники команды не заинтересованы в CI/CD, то она не будет работать. Перед началом внедрения найдите подходящую литературу, статьи, доклады о CI/CD и заразите участников команды. Если сможете пригласить в команду энтузиаста с опытом использования CI/CD на практике, шансы на успех значительно возрастут.
Команда должна понимать какие плюсы может получить от применения CI/CD еще до начала внедрения. Игнорирование этого фактора может привести к тому, что CI/CD будет восприниматься как навязанный процесс, который не имеет ценности.
Выбор правильной платформы CI/CD
Правильная платформа – ключевой фактор успешности внедрения CI/CD. Платформа должны быть интегрированной. Это означает, что она встраивает CI/CD в необходимые при разработке системы:
- контроля версий кода – Git, SVN, Mercurial;
- управления задачами – RedMine, Gitlab Issues, Github Issues, Atlassian Jira;
- управления артефактами – Sonatype Nexus, Docker Registry, FTP, Web-каталог;
- тестирования кода;
- отслеживания уровня покрытия кода;
- документирования – Wikimedia, Atlassian Confluence, GitHub Wiki, Gitlab Wiki.
Производители инструментов для разработчиков поставляют такие платформы. Широко известные интегрированные платформы, которыми пользуется более 100000 команд по всему миру:
- Gitlab CE/EE;
- Atlassian Confluence, Jira, BitBucket, Bamboo.
Компания Atlassian поставляет самый интегрированный набор продуктов, но он сложен в эксплуатации, настройке, а стоимость использования зависит от количества рабочих мест. Другие поставщики не предоставляют настолько интегрированных продуктов как Atlassian, однако, следующим лидером является продукт Gitlab. Даже версия для сообщества Gitlab CE предоставляет контроль версий кода, управление задачами, управление артефактами, тестирование кода, отслеживание покрытия кода, документирование. Все инструменты интегрированы с CI/CD. Gitlab CE является предпочтительным выбором для небольших и средних компаний. Продукт доступен для установки на сервере и как облачная услуга.
Исторически, разработчики широко используют продукт с открытым кодом Jenkins для решения задач CI/CD. К недостаткам данного продукта мы относим слабую интегрированность. Несмотря на наличие модулей для интеграции с распространенными инструментами разработки, Jenkins не предлагает готовых решений. Для команды, которая начинает использовать CI/CD в своей практике – это минус.
За последние два года мы перенесли все задачи CI/CD с Jenkins в Gitlab, что сократило наши затраты на администрирование и сделало нашу инфраструктуру CI/CD более простой.
Внедрение необходимых процессов и правил
Процессы разработки определяют востребованность CI/CD в команде. Если команда не имеет четких правил, то внедрение CI/CD не будет эффективным. Мы выделяем ряд важных правил, которые необходимы для успешного использования CI/CD.
Автоматизируйте
Если развертывание приложения, настройка, обновление требует уникальных навыков, которые есть только у специально обученного человека, то CI/CD не будет успешным. Вы должны автоматизировать развертывание всех необходимых сред приложения и встроить это развертывание в ваши сборочные сценарии CI/CD. Любой участник команды должен уметь развернуть любую версию приложения без специальных навыков, по конфигурационному файлу специальным скриптом. Практика CI/CD сильно связана с DevOps и способом взаимодействия разработчиков и администраторов в проекте.
Внедрите TDD, интеграционное тестирование и E2E тестирование
CI/CD не имеет смысла без написания unit-тестов и интеграционных тестов. Постарайтесь разрабатывать и e2e тесты, внедрите их в ваши сборочные сценарии CI/CD. Unit-тесты и интеграционные тесты разрабатываются в момент написания кода. E2E тесты создаются инженерами тестирования и интегрируются в сборочные сценарии для веток, которые требуется тестировать на регрессии.
Gitlab поддерживает отслеживание покрытия кода тестами. Это позволяет менеджерам следить за общим состоянием тестового плана. Code Coverage – отличный инструмент для визуального анализа качества тестирования, его применение позволяет наглядно отслеживать код с плохим дизайном или слабым покрытием тестами.
Обратите внимание на сервис Coveralls, который бесплатен для продуктов с открытым кодом.
Внедрите процесс работы над ветками кода
Используйте процесс работы над задачами, который упорядочивает деятельность команды и поддерживает интеграцию изменений в код. Мы часто используем Git-flow. Другие команды могут использовать иные процессы: Github Flow, Trunk-based Development или что-то свое. Важно, чтобы этот подход был описан, воспринимался всеми участниками команды однозначно и покрывал проектные требования. Без использования установленного процесса работы над кодом, практика CI/CD не будет эффективной.
Начните делать ревью кода
Ревью – важный инструмент экспертной оценки выполненной задачи. Без этого процесса ничто не мешает интегрировать код с ошибками в основное дерево разработки. Если ревью не используется, CI/CD не имеет смысла. Каждая задача должна проходить ревью. В малых командах ревью делает технический руководитель, в больших – ревью делается двумя сотрудниками – техническим руководителем и опытным инженером.
При выполнении ревью постарайтесь учить сотрудников как делать правильно. Ревью должно быть информативным и содержать конструктивные советы по улучшению кода.
Используйте общий стиль кода
Для каждого языка программирования существует средство оценки стиля кода. Настройте стиль кода и внедрите проверку стиля в сборочный сценарий. Это не позволит попадать в дерево проекта коду, который реализован с нарушением стиля.
Проверка стиля кода – инструмент автоматической оценки качества кода и защита от лишней нагрузки на сотрудников, выполняющих ревью. До тех пор, пока код не проходит проверку стиля, он не должен рассматриваться в качестве кандидата для ревью.
Расследуйте провальные сборки
Если сборка провалилась, это повод провести расследование. Если сборка проваливается периодически, необходимо найти причину и устранить ее. Как только Вы начнете пренебрегать этим правилом, процесс CI/CD потеряет ценность. Это будет знак для команды, что в проект можно интегрировать изменения, даже если они вызывают падение сборки.
Для получения пользы от CI/CD необходимо поддержание высокой дисциплины. Нет дисциплины, практику CI/CD можно прекращать.
Декомпозируйте проект
Разделите код проекта на слабо связные компоненты, для которых Вы сможете выполнять CI/CD по отдельности. Реализуйте возможность развертывания каждого исполняемого компонента изолированно. Используйте микросервисную архитектуру, если требования и квалификация команды это позволяют.
Высокопроизводительное оборудование для выполнения CI/CD
Выделите достаточно серверных ресурсов для сборки. Чем качественнее проект покрыт тестами, тем больше времени будет занимать сборка. Если сборка занимает много времени, то ее отладка станет неэффективной. Это снизит мотивацию команды в использовании CI/CD.
Рабочие станции команды должны быть современными и быстрыми, чтобы разработчики могли запускать CI/CD локально до отправки кода для интеграции.
Чем быстрее будут проходить сборки, тем больше шансов, что команде будет нравиться использовать CI/CD.
Хорошая сеть
Выполнение операций CI/CD может генерировать существенную нагрузку на сетевые каналы. Современные продукты зависят от десятков и сотен внешних библиотек. Медленная сеть приведет к тому, что сборки могут длиться долго. Используйте инструменты локального кэширования, чтобы уменьшить время загрузки компонент из сети.
Если сеть имеет плохой доступ к тем или иным ресурсам, это будет приводить к тому, что сборки будут “падать” из-за того, что зависимости не будут скачиваться. В результате практики CI/CD вызовут у команды лишь разочарование.
При блокировке Роскомнадзором серверов Amazon, Google и Microsoft в 2018 году наши процессы CI/CD значительно пострадали и стали работать нестабильно. Нам пришлось потратить примерно неделю на преодоление этого препятствия.
Организация работы с артефактами
Целью CI/CD являются артефакты сборки. Артефакты – это скомпилированный код, преобразованные файлы, отчет по исполнению тестов, отчет по покрытию, журнал сборки и другие продукты сборки. Артефакты должны помещаться в хранилища артефактов, где они будут удобно доступны для заинтересованных лиц. Если не обеспечить условия удобного доступа, то процессы CI/CD будут под угрозой. К примеру, отчет по покрытию тестов должен быть доступен в форме веб-страниц по ссылке, которую легко найти тому, кто делает ревью. Если это условие не обеспечить, то, при выполнении ревью, анализ покрытия кода будет пропускаться.
Если вы разрабатываете код на Java, обеспечьте доступность Nexus, если используете Docker, сделайте Docker Registry. Подумайте обо всех репозиториях, которые вам нужны, создайте и поддерживайте их в актуальном состоянии с самого начала проекта.
Организация развертывания в тестовое и продуктовое окружение
Добейтесь того, чтобы все необходимые ветки автоматически развертывались в требуемых окружениях из CI/CD без участия людей. Ваши инженеры QA, продуктовая команда и заинтересованные лица со стороны бизнеса должны получать доступ к требуемым версиям продукта как можно раньше. Это ускорит процессы разработки, принятия решений, демонстрации функций заинтересованным лицам.
Разработайте модель CI/CD
Пример модели CI/CD для одного из проектов.
Объясните схему всем участникам проекта. Проведите тренинг по использованию модели для всех заинтересованных лиц.
Изучайте свои инструменты CI/CD и создавайте новые
Проблемы, которые возникнут у вас, наверняка возникали у других людей. Разработчики инструментов стараются учесть типовые проблемы и включают их поддержку в новых версиях. Если в инструменте нет поддержки чего-то, что вам необходимо, приложите усилия для
- презентации необходимой функции разработчикам,
- помощи в создании,
- публикации в форме открытого кода.
Тем самым вы можете не только принести пользу другим разработчикам, но и продвинуться в понимании того, как другие команды решают аналогичные проблемы. Постарайтесь непрерывно анализировать процесс CI/CD в вашем проекте, чтобы понять как его можно улучшить, чтобы повысить свою продуктивность.
Читайте еще по этой теме:
- Принцип ‘You build It, You Run It’ при разработке современного ПО
- Автоматизированное тестирование для молодых и дерзких
Если вам понравился этот пост, поделитесь им с друзьями.