Build and Artifact Management
A focused chapter on build and artifact management, with practical delivery concerns, trade-offs, and the operational questions behind CI/CD work.
От исходного кода до того, что действительно работает
Разбираем, почему исходный код нельзя напрямую отправлять в продакшн, что такое артефакты сборки и как настроить воспроизводимые билды для надёжного деплоя.
Почему каждой сборке нужен уникальный идентификатор
Узнайте, почему версия приложения — не гарантия уникальности. Как build ID, хеш коммита и метка времени создают надежную идентификацию артефактов в CI/CD.
Где живут ваши сборки: почему каждому артефакту нужен дом
Централизованное хранилище артефактов (registry) — ключевой элемент CI/CD. Узнайте, как registry разделяет CI и CD, обеспечивает воспроизводимость деплоев и упрощает откаты.
Почему никогда не стоит пересобирать для продакшена
Узнайте, почему пересборка артефакта для продакшена — это риск, и как продвижение (promote) одного и того же билда между средами даёт гарантию, что в production попадает именно то, что протестировано.
Почему пересборка для продакшена рискованнее, чем кажется
Зелёная сборка на стейджинге, тесты пройдены. Команда готова к релизу. Кто-то предлагает: «Давайте просто возьмём тот же тег, пересоберём и задеплоим в продакшен». Звучит эффективно, но на деле подрывает отслеживаемость и воспроизводимость. Разбираем, почему принцип «собрал один раз — продвигай везде» спасает от головной боли.
Почему никогда не следует пересобирать артефакт после успешного тестирования
Представьте: команда три часа гоняла тесты в стейджинге. Всё зелёное. Релиз-менеджер говорит: «Отлично, давайте пересоберём для продакшена». Кто-то запускает свежую компиляцию, пакует и деплоит. Через час продакшен сыпется ошибками, которых не было в стейджинге. Код тот же, но артефакт другой. Вы потеряли единственную гарантию: то, что тестировали, — не то, что работает.