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, начать автоматизировать процесс интеграции и поставки и ускорить цикл разработки с минимальными рисками вы можете на видеокурсе Слёрма «Gitlab CI/CD».
На нём вы:
освоите конвейерный метод разработки, научитесь работать с пайплайнами, билдами и артефактами;
узнаете, из чего состоит Gitlab и какие у него возможности и настройки, создадите свой проект;
разберёте лучшие практики построения пайплайна, особенности шаблонизации и работы с переменными;
научитесь добавлять в пайплайн возможность отката назад, узнаете, что такое динамическое окружение и что оно дает.
Обучение начнётся сразу после оплаты, график и темп обучения вы выбираете сами 👌
