Какие этапы можно пройти при написании правильного пайплайна?11.12.2023 13:00

5 декабря мы провели вебинар «Этапы становления CI с использованием GitLab-CI», на котором подробно разобрали этапы создания качественного пайплайна. Делимся с вами кратким конспектом встречи.

MVP

1f08a1502ec509390f9cf5f58e2bdfa3.png

Самое начало: написание mvp вашего ci. Главное — чтобы работало. А проще такого короткого варианта даже сложно придумать. Дальше мы будем описывать шаги по усложнению, чтобы в итоге получить хороший результат.

Вводим проверки

93b50169ed90ca92df38184a79442882.png

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

flow для проекта

Здесь начинаем с версионирования.

0fe1523d78dde22f5d2b64527a44178b.png

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

Как реализовывать?

  •  Needs, rules

27cfe41f73c99ecc0e494647845b1670.png

  •  Protected branch (выстраиваем ветки, flow по неймингу веток, запускаем дополнительные проверки)

  • Conventional commits (для поддержания высокой инженерной культуры — всегда приятно читать историю в GitLab, когда все четко и понятно написано).

Пайплайн работает, что еще нужно?

Используем registry, чтобы хранить готовые образы или нужные библиотеки 

b9204dbca96388f5dd7311346859479c.png

Используем, чтобы распределить крупные джобы на небольшие, передавая результаты выполнения. Главное — не передавать секреты, особенно через кэш.

Безопасность

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

У нас есть работающий пайплайн, он деплоится, у него выстроен flow, мы используем базовые приемы работы с GitLab. Иммено на этом этапе начинаем думать про безопасность:

  •  Убираем секреты, токены из кода и ci. Интегрируемся с системой хранения секретов

  • Добавляем проверки ИБ sast, dast ищем секреты в коде. Проверяем docker images

399c810a4eed6b3ec4a804197fc2860e.png

Для примера можно пользоваться встроенными проверками, но внешние инструменты более функциональны.

Вероятный вектор атаки на вашу инфраструктуру. Для сборки используйте kaniko. Оставьте там, где крайне необходимо. Проброшенный docker.sock вообще не используйте. 

DRY

  • Используем default variables (использование собственных переменных снижает возможность поддерживать данный код и не позволяет переиспользовать его в других проектах)

  • extends, reference, include, components

886d2e9ac5d6e3cdf6e6b80db2a2a5b1.pngdf6ea6825570f08c96f29073bff9e26b.png

При сложной шаблонизации с большим количеством инклюдов важно фиксировать все в документации.

TTM

Для достижения высоких показателей нам нужно снижать time to market, и наоборот повышать deployment frequency. Так что на данной моменте мы сокращаем время выполнения пайплайна.

  • Определяем порядок и по возможности запускаем в параллель

  • Прячем в downstream

А что потом?

Для отработки новых знаний и получения практических навыков приглашаем вас присоединиться к новому практическому курсу Слёрма «Навыкум CI/CD», который стартует уже 11 декабря.

Что будет в Навыкуме?

1.   CI для python;

2.   проект из github переносим себе и локально устраняем уязвимости;

3.   готовый проект на js, в котором есть проблемы.

Формат Навыкума значительно отличается от привычных нам курсов — он состоит исключительно из практических заданий и разборов на живых встречах с экспертами. Всего за 3 недели вы сможете пополнить свое портфолио реальными интересными кейсами и получить +1 к грейду.

Ознакомиться с программой и присоединиться

© Habrahabr.ru