CI/CD давно став звичною частиною розробки, але різні інструменти реалізують його по-різному. У цій категорії я ділюся власними спостереженнями про pipelines, автоматичні перевірки, збірку, деплой і все, що допомагає швидше отримувати зворотний зв'язок під час розробки.
Для великого релізу я не вливаю пов’язані задачі в development по одній. Спочатку вони збираються в окремій release branch, проходять спільну стабілізацію, а вже потім реліз рухається далі як одна перевірена одиниця.
Під час production-розгортання ICanUp я не хочу показувати користувачам напівоновлений Laravel-застосунок і випадкові помилки 500. На критичний період сайт переходить у режим технічних робіт із контрольованою відповіддю 503, попередньо підготовленою сторінкою, Retry-After та чітким правилом: якщо розгортання завершується помилкою, сайт не відкривається автоматично.
Після успішного розгортання Laravel-застосунку я не вважаю production автоматично справним. У ICanUp після оновлення окремо перевіряю HTTP, завантаження Laravel, з’єднання з базою даних, frontend assets, Supervisor, queue worker, Reverb і commit SHA. Якщо ключова перевірка не проходить, процес має зупинитися, а відкат до попередньої стабільної версії не повинен вимагати ручного редагування файлів.
У ICanUp я хотіла автоматично рухати Jira-задачу після створення та merge GitLab Merge Request, але не віддавати автоматизації весь життєвий цикл задачі. Розбираю, чому залишила лише два автоматичні переходи, як перевіряю target branch і поточний статус та чому повторний webhook не повинен рухати задачу вдруге.
На сервері всі VITE_REVERB_* значення були в .env, але production bundle усе одно збирався без них. Розбираю, як я знайшла причину в GitLab CI build stage, перенесла build-time variables у правильний environment scope і додала fail-fast перевірки перед deployment.
CI/CD для мене - це не просто автоматичний deploy. У своєму Laravel-проєкті я використовую pipeline, який послідовно перевіряє код, запускає тести, збирає frontend і тільки після цього дозволяє рухатися до deployment.
Іноді знайомий процес можна показати зовсім по-іншому. Саме це я помітила, коли вперше попрацювала з іншим CI/CD-інструментом.