Update17 July 2026, 11:01

ICanUp Releases Became Automated and Controlled

ICanUp started moving from manual site updates to a controlled release workflow with GitLab CI/CD, automatic development deployment, protected production, health checks, and rollback preparation.

In the early stage of ICanUp, project updates still depended heavily on manual actions. That can work for a small site, but once separate development and production environments exist, it quickly stops being a safe release strategy.

On July 17, 2026, the project began moving toward a complete release workflow: changes needed automated verification, development needed automatic deployment, and production needed to remain controlled and protected.

What changed

GitLab CI/CD

Backend and frontend gained automated build, quality, and test checks before changes could move further through the release process.

Automatic Dev Deploy

After a successful merge, the development environment is updated automatically and becomes the final verification stage.

Controlled Production

Production is no longer updated from a task branch or Merge Request. Releases go through a dedicated controlled production flow.

Protected Git Workflow

Main is protected from direct and force pushes, while changes move through separate task branches and Merge Requests.

The release flow became predictable

The new process separated code verification from actual deployment.

Changes are developed in a dedicated task branch.
A Merge Request runs builds, static analysis, code style checks, and automated tests.
After a merge into development, an automatic deployment updates the development environment.
The built version is verified in a real environment.
Production deployment runs separately and only after successful verification.
After deployment, the system checks the application and its critical processes.

This was an important transition: ICanUp started evolving not only as a codebase, but as a product with its own release lifecycle.

Release safety became part of the architecture

Health Checks

After deployment, the process verifies the HTTP response, Laravel, database, frontend assets, queue workers, and Reverb.

Storage Verification

Deployment verifies the storage symlink and writable paths instead of relying on unsafe universal permission fixes.

Deployment Identity

The release process records the environment, branch, and deployed commit so the running version remains traceable.

Rollback

A failed release gained a documented recovery path and a way to return to the previous stable version.

These changes are almost invisible to a visitor. That is exactly how release infrastructure should work.

For the project itself, however, this was one of the important early milestones. A new feature no longer meant only writing code; it also meant moving that code safely through verification, development, and production.

From this point on, release infrastructure became a real part of ICanUp rather than a collection of manual actions around it.