Перейти до вмісту

Побудувала пайплайни CI/CD на GitHub Actions з distroless‑образом продакшн‑фронтенду та просуванням між кількома середовищами.

один конвеєр, три середовища, distroless‑образ

Ситуація. Постачання не повинне залежати від того, чи хтось пам’ятає всі кроки, а те, що зрештою працює в продакшн, не повинне бути товстим контейнером загального призначення з оболонкою та пакетним менеджером, якими він ніколи не скористається, — це просто зайва поверхня для атак без жодної потреби.

Завдання. Зробити шлях від коміту до запуску в Azure автоматичним і тримати продакшн‑образи такими малими й закритими, наскільки дозволяє кожне навантаження.

Дія. Пайплайн побудовано на GitHub Actions. Окремі workflow відповідають за перевірку якості коду, тести й розгортання для кожного середовища, а поруч працюють CodeQL, dependency review та крок формування SBOM, тож нічого не потрапляє в середовище без попереднього проходження перевірок. Образи — це multi‑stage‑білди, і базовий образ для кожної частини обрано за його перевагами, а не за єдиним загальним правилом: фронтенд постачається на distroless‑образі (gcr.io/distroless/cc‑debian13 — без оболонки, без пакетного менеджера), Go API — на легкому Alpine, а образ бази даних — на postgres‑slim. Просування переміщує білд через середовища за визначеним маршрутом, а не вручну.

Результат. Релізи перестали бути обережним ручним ритуалом і стали рутинною, нудною подією, а це саме те, чого хочеться від релізів. Продакшн‑фронтенд працює на настільки малому, наскільки це взагалі можливо, перевірки ловлять проблеми до того, як вони потраплять у продакшн, а «розгортання» — це те, що робить пайплайн, а не те, через що будь‑кому доводиться перейматися.

Одна частина довшого переліку — і він увесь на цьому сайті.

Кожен запис написано однаково: ситуація, завдання, що ми зробили і що змінилося.

Переглянути весь перелік