Внедрение CI/CD: 5 распространенных ошибок и способы их избежать

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

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

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

Многие наши команды используют DevOps-практики, и именно CI/CD-подход, в разработке продуктов. Как и 99% компаний, если верить отчету DevOps Trends Survey 2020, мы заметили ряд улучшений как в работе команде, так и в бизнес-результатах. При этом, если верить тому же отчету, 85% команд испытывают трудности с внедрением DevOps-практик на первых этапах.

Зачем переходить на CI/CD

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

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

5 ошибок работы с CI/CD и способы их избежать

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

1. Построение CD на нестабильном CI
Построение CD процессов предполагает что в проекте уже заложена основа в виде надежного CI flow. Такой CI дает нам уверенность в том, что:

а) каждый юнит релиза не нарушает работоспособность системы;

б) процесс сборки приложения достаточно автоматизирован и повторяем (то есть повторная сборка одного и того же кода приведет к точно такому же результату).

Если уверенности в этих пунктах нет, вероятность что CD-флоу будет постоянно останавливаться и требовать ручного вмешательства инженеров для поиска и устранения проблем (появление ошибок которых не было ранее, падающие билды) очень высока.

Как исправить: Убедиться что все этапы CI-флоу реализованы, а у команды есть доверие к результатам работы CІ. Например, код который однажды собрался и прошел тесты, сможет гарантированно собраться и пройти тесты и в будущем.

2. Не соотносить риски и выгоды автоматизации
При автоматизации процессов всегда нужно учитывать соотношения затрат на автоматизацию к пользе, которая будет получена. Например, если предполагается, что релиз будет происходить достаточно редко (например, раз в две недели), но для его автоматизации нужно потратить два месяца работы QA-команды по написанию автотестов (при ручной регрессии, которая занимает не больше 4х часов), то автоматизация такого процесса может никогда не окупиться. Если же цель команды ─ постоянная работа над уменьшением времени на деливери кода (например, имея цель в обеспечении релизов каждый день), тогда, наоборот, CD может существенно сэкономить время работы QA-команды, гарантируя в это же время большую надежность.

Как исправить: Перед началом автоматизации нужно четко сравнить пользу и цену этой автоматизации.

Для этого, прежде чем автоматизировать какой-то процесс, задайте себе несколько вопросов:

1. Как часто этот процесс повторяется?
2. Сколько времени занимает?
3. Сколько людей и ресурсов задействованы в нем?
4. Отсутствие автоматизации приведет к ошибкам в процессе?
5. Почему этот процесс нужно автоматизировать прямо сейчас?

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

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

3. Путать continuous deployment и continuous delivery
Continuous Deployment ─ достаточно специфичная практика, которая предполагает, что любое изменение в кодовой базе должно автоматически и как можно быстрее попасть в продакшн. С одной стороны, этого боятся большинство команд, потому что быстрые изменения могут отпугнуть пользователей, с другой, они считают, что не делают CD-часть методологии, если не запускают любое изменение в продакшн моментально. На самом деле, они просто путают continuous deployment и continuous delivery.

Continuous Deployment ─ это отдельный механизм, который выступает надстройкой над continuous delivery и не заменяет его. Соответственно, при реализации CI/CD-процесса рассматривайте continuous deployment как отдельную возможность, которая может быть нужна, а может быть и не нужна в каждом конкретном проекте.

Как избежать: Если вы все-таки решили работать с continuous deployment, подготовьте к этому свой проект заранее, чтобы внезапные изменения не пугали пользователей и не нарушали пользовательский опыт. Например, можно внедрить подход Feature Flags. Он позволяет выкатывать новый функционал изначально спрятанным от пользователей и дает возможность продуктовой команде или аккаунт-менеджеру включать и выключать его определенным группам пользователей в нужное время.

4. Ненадежные системы тестирования
Одна из основ CI/CD-процесса ─ надежные тесты. Они дают уверенность в том, что код работает правильно и позволяют идти дальше по релиз флоу. Если к автоматическим тестам нет доверия, команде приходится либо дублировать работу, проводя мануальные тесты (что обесценивает работу по написанию автоматических тестов), либо сталкиваться с большим количеством ошибок на этапе продакшена (что будет приносить вред напрямую продукту).

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

1) Тесты гарантируют достаточное покрытие всего функционала: то есть все модули приложения и все основные флоу покрыты тестами.
2) Можно доверять результату работы каждого отдельного теста: тесты не падают сами по себе, а если тест прошел, значит, эта часть функционала была действительно проверена

5. Недостаток значимых дашбордов и метрик

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

В идеале, несмотря на то, что Agile и CI/CD имеют разные цели, они должны помогать друг другу. В основе обоих подходов лежит практика continuous improvements ─ постоянный анализ выполненного, пересмотр и улучшения. Проще всего реализовать ее, хорошо покрыв все процессы метриками и дашбордами. Команда должна иметь возможность видеть текущее состояние, чтобы понимать куда двигаться дальше. Также любые проблемы должны выявляться и решаться на ранних стадиях. Это касается и Agile и CI/CD в равной мере. Например, команда, которая работает по SCRUM, должна понимать свою производительность и burn rate, а также понимать свой Time To Delivery, чтобы видеть возможные боттлнеки в процессе релиз флоу. Если этого понимания нет, то команда не узнает, какая часть системы работает неэффективно, и не сможет сфокусироваться на улучшениях.

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

Что в итоге

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

Если вы только начинаете изучать эту тему, могу посоветовать книгу Сэма Ньюмана «Design, Build, Ship: Faster, Safer Software Delivery». Она поможет сложить представление о CI/CD как о цельном процессе и о его отдельных элементах.