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

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 декабря.

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

1. CI для python;

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

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

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

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