Был ли опыт настройки файлов для релизов в CI/CD системах

Что проверяют

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

Как отвечать

Нужен рассказ о своём конвейере, а не перечень инструментов. Удобный каркас:

• где и что: GitLab CI (.gitlab-ci.yml) или GitHub Actions (.github/workflows/*.yml), какие стадии и что их запускает: мердж в основную ветку, тег, ручной запуск;
• проверки: golangci-lint, go test -race ./..., контроль, что go mod tidy ничего не меняет, govulncheck для зависимостей;
• сборка: статический бинарник с CGO_ENABLED=0, флаги -trimpath и -ldflags "-X main.version=$TAG", чтобы версия была видна в логах и метриках. Многоэтапный Dockerfile с итоговым образом на distroless или scratch, кеш GOMODCACHE и GOCACHE между прогонами;
• релиз: теги вида v1.4.2 (префикс v для Go-модулей обязателен), GoReleaser с .goreleaser.yaml для бинарников под несколько платформ, чексумм и changelog;
• выкладка: Helm-чарт или манифесты, отдельные окружения, ручное подтверждение для прода, откат на предыдущий тег образа.

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

Если такого опыта нет, скажите прямо и покажите ближайшее: Makefile с целями сборки, свой Dockerfile, конвейер пет-проекта на GitHub Actions. Честное «конвейер писал DevOps, но я правил стадию тестов и разбирался, почему падает сборка» звучит лучше выдуманной истории.

Где спотыкаются

Рассказывают по STAR-шаблону «сократили время релиза на 30%» и не могут объяснить ни одной строки собственного конфига.

Хранят секреты прямо в YAML или дают любой ветке доступ к прод-переменным вместо защищённых веток и переменных.

Не знают, как версия попадает в бинарник, и выкатывают образ latest без тега. Тогда по логам не понять, какой код сейчас работает.