5 декабря мы провели вебинар «Этапы становления CI с использованием GitLab-CI», на котором подробно разобрали этапы создания качественного пайплайна. Делимся с вами кратким конспектом встречи.
1. MVP
Самое начало: написание mvp вашего ci. Главное – чтобы работало. А проще такого короткого варианта даже сложно придумать. Дальше мы будем описывать шаги по усложнению, чтобы в итоге получить хороший результат.
2. Вводим проверки
Сначала добавляем линты для проверки корректности синтаксиса, не запуская компилляцию. Второй важный этап – тесты, проверяющие определенные условия. На выходе мы имеем простой проект, который только деплоится и запускает проверки.
3. flow для проекта
Здесь начинаем с версионирования.
На этом этапе особенно важен контакт с разработчиками и обсуждение того, как именно должен работать будущий пайплайн, чтобы иметь возможность мысленно выстроить дальнейшие процессы.
Как реализовывать?
Needs, rules
Protected branch (выстраиваем ветки, flow по неймингу веток, запускаем дополнительные проверки)
Conventional commits (для поддержания высокой инженерной культуры – всегда приятно читать историю в GitLab, когда все четко и понятно написано).
4. Пайплайн работает, что еще нужно?
Используем registry, чтобы хранить готовые образы или нужные библиотеки:
Image registry, artifacts repository
artifacts, cache
Используем, чтобы распределить крупные джобы на небольшие, передавая результаты выполнения. Главное – не передавать секреты, особенно через кэш.
5. Безопасность
Сложно переоценить важность безопасности в ci (а вот дополнительное время которое она тратит оценить точно можно).
У нас есть работающий пайплайн, он деплоится, у него выстроен flow, мы используем базовые приемы работы с GitLab. Иммено на этом этапе начинаем думать про безопасность:
Убираем секреты, токены из кода и ci. Интегрируемся с системой хранения секретов
Добавляем проверки ИБ sast, dast ищем секреты в коде. Проверяем docker images
Для примера можно пользоваться встроенными проверками, но внешние инструменты более функциональны.
Отказываемся от dind
Вероятный вектор атаки на вашу инфраструктуру. Для сборки используйте kaniko. Оставьте там, где крайне необходимо. Проброшенный docker.sock вообще не используйте.
6. DRY
Используем default variables (использование собственных переменных снижает возможность поддерживать данный код и не позволяет переиспользовать его в других проектах)
extends, reference, include, components
При сложной шаблонизации с большим количеством инклюдов важно фиксировать все в документации.
7. TTM
Для достижения высоких показателей нам нужно снижать time to market, и наоборот повышать deployment frequency. Так что на данной моменте мы сокращаем время выполнения пайплайна.
Определяем порядок и по возможности запускаем в параллель
Прячем в downstream
8. А что потом?
Используем pages
Интегрируем k8s
GitOps
Для отработки новых знаний и получения практических навыков приглашаем вас присоединиться к новому практическому курсу Слёрма «Навыкум CI/CD», который стартует уже 11 декабря.
Что будет в Навыкуме?
CI для python;
проект из github переносим себе и локально устраняем уязвимости;
готовый проект на js, в котором есть проблемы.
Формат Навыкума значительно отличается от привычных нам курсов – он состоит исключительно из практических заданий и разборов на живых встречах с экспертами. Всего за 3 недели вы сможете пополнить свое портфолио реальными интересными кейсами и получить +1 к грейду.
