GitLab Flow et gestion des versions

The GitLab Flow is a streamlined Git workflow that combines feature-driven development with release management and CI/CD integration.

It's designed to be simple, effective, and to work seamlessly with GitLab's built-in features like Merge Requests and pipelines.

At its heart, GitLab Flow uses a single main branch (often named main or master) as the source of truth.

• Feature branches: All new work happens here.
• Environment branches: Dedicated branches (e.g., pre-production, production) track deployed code.
• CI/CD: Heavily integrated to automate testing and deployments.

When starting new work, you'll create a feature branch directly from the main branch. This keeps your main branch stable.

Naming conventions are key, like feature/add-user-profile or bugfix/fix-login-error.

Here's how you might start a new feature:

Once your feature is complete on its branch, you open a Merge Request (MR) to merge it back into main.

MRs are central to GitLab Flow:

• They trigger CI/CD pipelines for testing.
• They facilitate code review by your teammates.
• They track discussions and approvals.

After a feature branch is merged into main, the main branch itself is often deployed to a staging environment automatically by CI/CD.

This allows for final testing in an environment that closely mirrors production before the code goes live.

The main branch is always deployable.

For production deployments, GitLab Flow often uses a dedicated production branch. This branch only contains code that has been successfully deployed to the live environment.

When main is ready for production, you merge main into production, which triggers a production deployment.

When a deployment to production is successful, it's good practice to create a Git tag on the production branch.

Tags act as permanent markers for specific release versions (e.g., v1.0.0, v1.0.1). They help you easily refer back to a released state.

If a critical bug is found in production, a hotfix is needed. In GitLab Flow, hotfixes are typically handled by creating a branch directly from the production branch.

Once fixed, it's merged back into production (triggering redeploy) and then also merged into main to ensure main is up-to-date.

The true power of GitLab Flow comes from its tight integration with CI/CD pipelines.

• Automated Tests: Every push to a feature branch runs tests.
• Deployment Automation: Merges to main or production can automatically deploy.
• Quality Gates: Pipelines can prevent merges if tests fail or code quality is low.

Consider the typical structure of GitLab Flow.

You've explored the GitLab Flow, a robust workflow for continuous integration and delivery.

• It uses a stable main branch.
• Feature development happens on separate branches.
• Merge Requests drive code review and CI/CD.
• Dedicated environment branches (like production) ensure smooth releases.
• Hotfixes are handled by branching from production.

This flow is ideal for teams leveraging GitLab's full suite of features.