Gitlab CI/CD Pipeline

Hello,

I have a question about Gitlab CI/CD workflows. I am in the process of trying to get a CI/CD pipeline set up for a project I work on. Here is what I am thinking, and please let me know if I am on the right track.

Generally speaking, let’s say I have “develop” branch and a “master” branch. Me, as a developer, creates “feature” branch off of the “develop” branch. I create merge request (MR) to merge my feature branch into develop branch. Upon a successful merge, I trigger a test-build-deploy pipeline, and the code gets deployed to say a “dev” environment. If everything looks good there, I create a MR to merge develop into master. Again, this will trigger a test-build-deploy pipeline, and the code gets deployed to say “staging” environment. If everything looks good here in the staging environment, I tag the commit from the master branch, and then push up the tag to Gitlab. Again, this will trigger a test-build-deploy pipeline, and the code gets deployed to a production environment.

Now I guess there are multiple ways to go about this, but I just wanted to know from a high level view if this is the basic idea.

Thank you for your help,
Chris

Hi,

the workflow sounds good to me, this is what is generally referred as Gitflow Workflow. In our environments, we use a simpler workflow without the develop branch. Instead, the master branch is always considered stable, but also is the development branch for the next feature release.

In terms of features, these are branched off master, and the merge request is created. When it is a draft and lives longer, our developers and reviewers are encouraged to rebase against master. Then again CI runs and ensures that prior to merging the MR, everything is working as expected.

Once the MR is merged to master, CI triggers and builds snapshot packages/nightly builds which are deployed into a staging environment. The same happens every night triggered by a cron to ensure that previous possibly delayed runs are still run. Meaning to say, we rely on the fact that test packages are also available at packages.icinga.com for our community to test.

The release process goes as follows: For a new major release, a new release branch is created with updating the changelog, etc. The version is raised and a Git tag is added and pushed. The CI configuration is then enabled to trigger a specific release type, stable in this regard. These release package are built and then available for production deployment. A middle stage publishes them as release packages to packages.icinga.com for users and customers (rpm/deb().

For minor bugfix releases, also for older major versions, we keep using support/x.y branches where hotfixes and bugfixes are cherry-picked into, and upon successful build after push, bugfix release are tagged.

That’s a workflow we’ve developed in the past 10 years with trying many different one’s before. In our environment with new developers coming to the team, the develop branch creates an overhead which we are aiming to solve with a strong focus on MR reviews and CI builds, or even deployments into staged feature environments.

You can find more workflow details in a GitLab training I’ve created for NETWAYS:

Cheers,
Michael

Hello Michael,

Thank you for your reply. It is nice to know how other teams work together to build software. I really like your approach, and I hope to get my team following a similar workflow as yours.

Thank you again for taking time to respond to my post.

-Chris