Pull to refresh

Эффективный CI/CD

Добрый день друзья.

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


Основные идеи:


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


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

3. Запускаем сборку на каждый коммит в фича-ветку — проще найти изменения которые сломали код.

4. Минимизируем время работы сборки, чтобы быстро понимать результат изменений — для этого сборку разбить на шаги/задачи и запускать их параллельно (так можно тяжеловесные тесты разбить на части и каждую часть запускать параллельно, то же для различных анализаторов кода (SonarQuibe, Checkmarx, Whitesource, blackduck и пр. Их можно запускать параллельно с тестами)).

5 Сборки должны быть воспроизводимыми — сборка с одного и того же коммита должна произвести точно такой же артефакт при каждом запуске — что бы была возможность пересоздать артефакты в случае необходимости, а также позволяет определить исходные данные для воспроизведения бага локально в случае его наличия.

6 Infrastructure as code — структура процесса сборки должна быть описана на каком нибудь DSL языке чтобы иметь возможность быстро разворачивать CI/CD окружение автоматически в точно таком же виде в случае если предыдущее окружение упало и не тратить время на ручное развертывание. Также это позволяет применить версионирования окружения если понадобится воссоздать какую то его историческую версию.

7 Автоматизировать мерж из исходной ветки в производную, например, если фича ветка была от develop то как только запушили код в девелоп запускать процесс сборки для фича-ветке и в начале процесса сборки локально вмержить девелоп в фича-ветку и если сборка/тестирование пройдет успешно запушить фича-ветку. Если этого не сделать есть вероятность что после мержа фича-ветки в девелоп — девелоп сломается не смотря на то что до мержа обе ветки были рабочие.

Более развернутые примеры ждите в следующих постах, всем спасибо за внимание и до новых встреч.

Tags:
Hubs:
You can’t comment this publication because its author is not yet a full member of the community. You will be able to contact the author only after he or she has been invited by someone in the community. Until then, author’s username will be hidden by an alias.