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

Побудувала пайплайни CI/CD на GitHub Actions

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

  • Port, crane, container
    Фото: WorldInMyEyes / Pixabay
  • Motorcycle, package, parcel delivery
    Фото: Tho-Ge / Pixabay

один пайплайн, три середовища, distroless‑образ

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

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

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

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

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

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

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