Оновлення17 липня 2026, 11:01

Релізи ICanUp стали автоматизованими та контрольованими

ICanUp почав переходити від ручного оновлення сайту до контрольованого release workflow: GitLab CI/CD, автоматичний deploy на development, захищений production, health checks і підготовлений rollback.

На початку ICanUp оновлення проєкту ще значною мірою залежали від ручних дій. Для невеликого сайту це може працювати, але після появи окремих development і production середовищ такий підхід швидко перестає бути безпечним.

17 липня 2026 року почався перехід до повноцінного release workflow: зміни мали проходити перевірки, development оновлюватися автоматично, а production залишатися контрольованим і захищеним.

Що змінилося

GitLab CI/CD

Backend і frontend отримали автоматичні build, quality та test checks перед тим, як зміни можуть перейти далі.

Automatic Dev Deploy

Після успішного merge development середовище оновлюється автоматично і стає місцем фінальної перевірки змін.

Controlled Production

Production більше не оновлюється з робочої branch або Merge Request. Реліз виконується тільки через контрольований production flow.

Protected Git Workflow

Main отримав захист від прямого push і force push, а зміни проходять через окремі task branches та Merge Requests.

Release flow став передбачуваним

Новий процес розділив перевірку коду і фактичний deployment.

Зміни виконуються в окремій task branch.
Merge Request запускає build, static analysis, code style і automated tests.
Після merge у development запускається автоматичний deployment на dev.
На dev перевіряється вже зібрана версія в реальному середовищі.
Production deployment виконується окремо і тільки після успішних перевірок.
Після deployment система перевіряє працездатність застосунку та критичних процесів.

Це важливий перехід: ICanUp почав розвиватися не просто як кодова база, а як продукт із власним release lifecycle.

Безпека релізу стала частиною архітектури

Health Checks

Після deployment перевіряються HTTP response, Laravel, database, frontend assets, queue workers і Reverb.

Storage Verification

Deployment перевіряє storage symlink і права доступу замість небезпечних універсальних permission fixes.

Deployment Identity

У release process фіксуються environment, branch і deployed commit, щоб завжди було зрозуміло, яка версія працює.

Rollback

Для невдалого релізу з'явився окремий recovery path і можливість повернення до попередньої стабільної версії.

Для відвідувача ці зміни майже непомітні. Саме так і має бути.

Але для розвитку проєкту це одна з ключових ранніх віх: відтепер нова функція означала не тільки написати код, а й безпечно провести його через перевірки, development і production.

Саме з цього моменту release infrastructure стала окремою частиною ICanUp, а не набором ручних дій навколо нього.