Сообщить об ошибкеКороткий ответ
Стадия `build` превращает исходный код в исполняемый артефакт (образ, бинарник, пакет), а стадия `deploy` доставляет уже готовый артефакт в целевое окружение и запускает его там; без собранного артефакта стадии деплоя либо нечего разворачивать, либо она ошибочно соберёт код «на лету», теряя воспроизводимость.
Как это работает подробнее
`build` отвечает за компиляцию, установку зависимостей и упаковку; `deploy` отвечает за обновление инфраструктуры — например, применение Kubernetes-манифеста, обновление образа в Deployment или копирование файлов на сервер. Это разделение ответственности позволяет повторно использовать один артефакт для разных окружений.
Пример кода
example.txt
$ ./deploy.sh myapp:abc123
Error: image "myapp:abc123" not found in registryЧто использовать на практике
- На практике. если смешать сборку и деплой в одной команде/скрипте, сложнее тестировать стадии по отдельности и труднее гарантировать, что в staging и в production попал один и тот же код. Разделение также ускоряет повторные деплои — не нужно пересобирать, если нужно просто откатиться на предыдущую версию.
- Пример. Ожидаемое поведение при правильно настроенном пайплайне: стадия `deploy` находит образ `myapp:abc123`, потому что он был собран и запушен в registry на предыдущей стадии; ошибка выше означает, что стадия `build` не выполнилась или запушила образ под другим тегом.
Подводные камни
- Частые ошибки. пытаются запустить деплой-скрипт, который ссылается на несуществующий файл или тег образа, потому что стадия `build` не сохранила артефакт или использовала другое имя; не настраивают зависимость стадии `deploy` от `build` (`needs`/`stage` порядок), из-за чего деплой может начаться раньше, чем сборка завершится.