CI/CD как система обратной связи

Этот урок начинается с нуля. Незнакомое слово здесь не считается вашим пробелом: мы сначала создадим образ, затем дадим точное значение и только потом применим его.

Где мы находимся

Полётное повторение. В прошлом уроке была опора commit → image → digest → registry → SBOM/scan → deploy. Не подглядывая, назовите её четыре звена и только затем сравните с записью.

Результат урока

Проектируем pipeline из независимых проверок и отделяем непрерывную интеграцию от доставки и развёртывания. Не переходите дальше, пока не можете объяснить, что проверяет каждая команда и какой отказ она обнаруживает.

Сначала знакомый образ

На заводе деталь проходит контроль после каждого важного этапа, а не только когда автомобиль уже собран. CI даёт быструю обратную связь после изменения. Delivery готовит проверенный выпуск, deployment действительно меняет работающую среду. Это три разных обещания.

Аналогия помогает начать рассуждение, но не заменяет устройство технологии. Ниже мы уточним каждое слово.

Опорный сигнал урока

commit → fast checks → build once → verify → deliver → deploy deliberately

Прочитайте цепочку слева направо. Она отвечает не на вопрос «какую команду запомнить», а на вопрос «почему следующий шаг следует из предыдущего».

Новые слова простыми словами

• CI — Автоматическая интеграция изменений с быстрыми тестами и проверками.
• Delivery — Состояние, когда проверенный выпуск готов к развёртыванию.
• Deployment — Фактическая установка версии в среду.
• Pipeline — Последовательность автоматических этапов и условий перехода.

Разбираем без спешки

CI быстро сообщает, можно ли объединять изменение. Continuous delivery держит проверенный артефакт готовым к выпуску; continuous deployment автоматически выпускает каждое прошедшее изменение. Скорость без надёжных ворот лишь быстрее доставляет дефект.

Сейчас не нужно запоминать формулировку дословно. Найдите в ней причинную связь и привяжите её к опорному сигналу выше.

Сначала предскажите результат

До запуска ответьте на бумаге: что должно измениться, что должно остаться прежним и какой вывод команды подтвердит ваш прогноз? Даже неверный прогноз полезен, если после опыта вы можете объяснить расхождение.

Опыт маленькими шагами

Выполните команды из корня course/cloud-devops-lab. Команды рассчитаны на учебную среду. Перед командой, меняющей сервер или данные, прочитайте её целиком и проверьте текущий каталог. Запускайте блок по одной смысловой группе. После каждой остановитесь и сопоставьте результат со своим прогнозом.

go test ./...
gofmt -l cmd internal
docker build -t cloudlab:ci .
docker run --rm -d --name cloudlab-ci -p 18080:8080 cloudlab:ci
trap 'docker rm -f cloudlab-ci >/dev/null 2>&1 || true' EXIT
sleep 1
curl -fsS http://127.0.0.1:18080/readyz

Эталонные файлы проекта.

Что именно делает этот опыт

Локальный скрипт повторяет будущий pipeline: форматирование, тесты, сборка, проверка образа. Запустите его после намеренной маленькой ошибки и снова после исправления — обратная связь должна быть понятной.

Что должно получиться

• Проверки идут от быстрых к более дорогим.
• Команда завершается предсказуемым кодом.
• Результат можно повторить на чистой среде.

Соберите целое по опорной схеме

Проведите пальцем или карандашом по четырём блокам и расскажите весь урок одним связным объяснением.

Воспроизведите без подсказки

1. Закройте схему и нарисуйте четыре блока по памяти.
2. Объясните каждый переход словами «потому что».
3. Дайте определение одному новому термину, не повторяя текст дословно.
4. Назовите один сигнал, который доказывает результат.

Найдите и исправьте ошибку

Ошибка: «CI/CD означает автоматический deploy каждого commit в production». Исправление: частота и согласование deployment — отдельное решение риска.

Задание

Теперь соберите тот же смысл самостоятельно. Можно смотреть на опорную схему; цель — не экзамен на память, а воспроизводимый результат.

Обязательное. Напишите POSIX sh pipeline из форматирования, теста, сборки образа и smoke test. Он должен останавливаться при первом сбое и всегда удалять тестовый контейнер. Отправьте только команды или скрипт POSIX sh без реальных ключей и токенов.

Критерии готовности

• Вы понимаете каждую запускаемую строку.
• Повторный запуск даёт ожидаемый результат или безопасно объяснённое отличие.
• В выводе нет настоящих ключей, токенов и паролей.
• Вы можете показать факт, который подтверждает успех.

Если проверка не прошла, зафиксируйте ожидаемое и фактическое, вернитесь к одному разорванному звену опоры и повторите. Ошибка не отнимает у вас право продолжать обучение.

По желанию. Запишите один возможный отказ и сигнал, по которому вы его заметите.

Открытая перспектива

Следующий урок добавит новую опору: GitHub Actions: проверка каждого изменения.

Оглавление курса