Урок 3 из 8 · 25 мин · обновлено
Git и CI/CD: автоматическая сборка и проверка
Что такое непрерывная интеграция и доставка, из каких этапов состоит конвейер, как он выглядит в GitLab CI и почему выкладывать вручную — плохая идея.
Что такое CI/CD
Разработчики «Чайной лавки» хранят код в Git — о нём подробно в курсе «Git и GitHub». Теперь нужно, чтобы каждое изменение автоматически проверялось и доходило до сервера. Это и есть CI/CD:
- CI (continuous integration, непрерывная интеграция) — после каждого коммита код автоматически собирается и проходит тесты. Ошибку видно через несколько минут после того, как её сделали, а не через месяц.
- CD (continuous delivery / deployment, непрерывная доставка) — проверенная версия автоматически выкладывается на серверы: по кнопке или сразу.
Конвейер
Последовательность шагов называют конвейером (pipeline). У «Чайной лавки» он такой:
| Этап | Что происходит | Если упал |
|---|---|---|
| test | Запускаются автотесты | Дальше не идём, разработчик получает уведомление |
| build | Собирается образ приложения | Дальше не идём |
| deploy | Новая версия выкладывается на сервер | Сайт остаётся на старой версии |
Главное свойство: если этап упал, следующие не запускаются. Сломанный код не доберётся до пользователей.
Пример: GitLab CI
Конвейер описывают в файле .gitlab-ci.yml в корне репозитория. Простой вариант для «Чайной лавки»:
stages:
- test
- build
- deploy
test:
stage: test
image: python:3.13
script:
- pip install -r requirements.txt
- pytest
build:
stage: build
script:
- docker build -t registry.example.ru/shop:$CI_COMMIT_SHORT_SHA .
- docker push registry.example.ru/shop:$CI_COMMIT_SHORT_SHA
deploy:
stage: deploy
script:
- ssh deploy@203.0.113.25 "./deploy.sh $CI_COMMIT_SHORT_SHA"
rules:
- if: $CI_COMMIT_BRANCH == "main"
Разберём:
stages— порядок этапов;test— в контейнере с Python ставим зависимости и запускаем тесты;build— собираем образ Docker (о контейнерах — в уроке 4) и помечаем его коротким номером коммита;deploy— подключаемся к серверу и запускаем скрипт выкладки, но только для основной веткиmain.
$CI_COMMIT_SHORT_SHA — встроенная переменная GitLab: короткий номер текущего коммита. По нему всегда видно, какая версия сейчас работает, и легко откатиться на предыдущую.
Похожим образом устроены и другие системы: GitHub Actions, Jenkins, TeamCity. Если понятен принцип, синтаксис осваивается быстро.
Секреты
Для выкладки конвейеру нужны ключи и пароли. Их никогда не пишут в код конвейера: репозиторий видят все разработчики, а история Git хранит всё навсегда. Секреты сохраняют в защищённых переменных CI/CD в настройках проекта и обращаются к ним по имени.
Попробуйте сами. Добавьте в конвейер «Чайной лавки» этап проверки стиля кода lint, который запускается до тестов командой flake8. Где он должен стоять в списке stages и как будет выглядеть задание?
Пример ответа
stages:
- lint
- test
- build
- deploy
lint:
stage: lint
image: python:3.13
script:
- pip install flake8
- flake8 .
Проверка стиля — самая быстрая, поэтому её ставят первой: если код оформлен с ошибками, нет смысла тратить время на тесты и сборку.
Мини-тест · 4 вопроса
Проверьте себя
Выберите вариант, который кажется вам правильным. В конце вы увидите свой результат и объяснение к каждому вопросу.
-
Что такое CI?
Continuous integration — непрерывная интеграция: каждое изменение сразу проверяется, и ошибки находятся, пока их легко исправить.
-
Тесты в конвейере упали. Что произойдёт с этапом выкладки?
Этапы идут по порядку. Если проверки не прошли, сломанная версия не попадёт к пользователям.
-
Где хранится описание конвейера GitLab CI?
Конвейер описан кодом и хранится вместе с проектом: его видно всем, изменения в нём проходят ту же проверку, что и код.
-
Как правильно передать конвейеру пароль от сервера?
Всё, что попало в репозиторий, видят все, у кого есть доступ к коду. Секреты хранят отдельно, в защищённом месте.