В конце марта Мстислав Казаков, руководитель практики Python ГК Юзтех, провёл внешний Usetech Meetup на тему «Как писать Gitlab CI файлы которые легко понимать, расширять и поддерживать».
С ростом проекта и увеличением количества автоматизированных операций содержимое Gitlab CI файла превращается в спагетти-код.
На примере демо проекта Мстислав поделился подходами, которые помогли ему решить эти проблемы. Спойлер: проблема решалась при помощи include, reference, rules и манипуляций с Docker.
Демо проект (или эталонный проект) – это монорепозиторий (представлен на изображении ниже). Он содержит 10 сервисов, монолит с беком и фронтом и несколько внутренних библиотек. Если говорить о тестовых средах, обновлениях, релизных циклах, и т.д., то их 3. В первой среде находится актуальная develop версия проекта, во второй среде тестируется release candidate, а третья среда предназначена для end-to-end тестов.
На этом примере Мстислав показал:
— Include в Gitlab CI: разбил большое на малое.
— Reference в Gitlab CI: в чём разница между алиасами? Можно ли использовать reference в правилах?
— Rules в Gitlab CI: замена устаревшим only/except. Рассмотрел, как простые правила, так и «сборные».
— Билдим и деплоим всё единообразно: вынес нюансы билда и деплоя сервисов из CICD процессов.
— Env vars из настроек Gitlab CI: как облегчить управления большим количеством переменных.
— Всем джобам единый образ! Как экономить время и строчки кода.
— Gitlab раннеры: как это сделано и почему это полезно знать?
Смотрите видео и оставляйте обратную связь в виде вопросов и комментариев.