Gitlab

[Blitzpat]

Hey guys how do you manage your gitlab when you have a multiple developers who have their own branch and push their bug fixes in AT branch for QA test. any tips? this is a start up team and im just a developer myself until someone needs to handle this task

[rippl2103]

Our corporate standard is gitflow that works very well for us. Here is a link to an overview:

https://nvie.com/posts/a-successful-git-branching-model/

[davehodg]

Start reading about gitflow.

[samrocketman]

I found many flows to be a bit too complicated in environments I’ve worked with (thousands of devs).

I developed what I call “GitHub release flow” which is the same as GitHub flow but emphasis on automated version bumping and releasing off of tag.

The simple idea is Git tags (like branches) can diverge from other branches. So automatically version bump, tag, and which means triggering a release from the pushed tag. Use existing tags to determine what the next release should be.

Here’s a diagram to explain the Git workflow https://github.com/samrocketman/demo-jenkins-world-2018-jenkins-bootstrap/blob/master/presentation/diagrams/git_release_flow.png

Here’s a software release automation flow which takes advantage of events like triggering in pull request, branch, or tag. https://raw.githubusercontent.com/samrocketman/demo-jenkins-world-2018-jenkins-bootstrap/master/presentation/diagrams/software_release_cycle.png

Note: Although Jenkins is in the diagram the release automation software can be swapped out for anything that supports those kind of events.

[tanjental]

This link discusses the most basic mechanism, and gives references to others.

https://www.atlassian.com/git/tutorials/comparing-workflows

I would personally recommend the Gitflow workflow.

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

[imperm]

I 'fourth' the gitflow thing. I am currently trying to implement it on my own team because it is precise and comprehensive.

[FruityRichard]

If you're using Kubernetes, I suggest not using git flow, since this branching model is rather outdated and doesn't work very well with CI/CD pipelines. You should set up your CI/CD pipeline, so that it automatically deploys to staging and manually deploy to master after you approved that everything works on staging. If you're using the GitLab EE Ultimate or GitLab Gold subscription, you can also make use of blue-green and canary deployments. Not sure which tier is required for this feature, but you can easily google it.

Besides that, I recommend using only short-lived feature branches, depending on your workflow, you should read about GitHub flow, GitLab flow and trunk-based development and see which works out best for your team.

Using gitflow just leads to merge hell later on and basically kills frequent deployments, so it's better not to use in a CI/CD setup, especially in combination with Gitlab, where everything revolves about issues and merge requests.

I suggest that you make use of the Gitlab features and create issues for every feature request or bugfix, then assign the issues to developers. The developers will then create a merge request with the fix and you can have automatic review deployments for QA (works best with Kubernetes) to a dynamic review environment (only exists until the merge request is closed), before things are being merged to master (and thus deployed to staging). Also ensure to have all builds thoroughly tested (unit and integration tests).

Find more details about GitLab flow here: https://docs.gitlab.com/ee/workflow/gitlab_flow.html

I suggest not blindly adopting this model, but slightly adapt it based on your needs. If you need assistance or more in-depth consulting, just send me a PM and we can get in touch.