GitLab flow design

Hi everyone. I am trying to solve a Design a GitLab flow that works for us problem.

GitLab best practice design

Screenshot from 2023-11-02 13-32-431404×746 110 KB

The design

GitLab workflow process1363×1144 133 KB

The problem (probably just me being too stupid to grasp this )

I am trying to follow the GitLab best practice and use GitLab flow vs the other kinds. And this made perfect sense in the perfect world, until I set up a test project and just used some text files to simulate a workflow.

The scenario:
As per the picture Developer 1 will work on Feature 1 and go through a process to get the code to a point where it needs to go Testing. The latter being a persistent environment where end-users will possibly log into services’ front-ends, or use API calls from their respective services to the one in Testing to see if everything is working. At the same time, Developer 2 is working on Feature 2. Both Feature 1 & 2 has passed the initial tests in the feature-branch pipelines. This brings them to the point where the dev would want to merge to main. This is still fine, it needs to go to main before it can go to the Testing environment. At this point all is still good. But here comes my problem. Feature 1 passes end user testing and everything is good, and can go to production, either via cherry-picking or during the next merge cycle (agile terminology inferred). But when the merge cycle arrives, Feature 2 is not ready yet to move onto the production branch. They need to do more tests. How do I hold back the merge of Feature 2 and keep it in Test but allow all other features (at this point just Feature 1) to be merged to production branch?

As mentioned, I am aware that one can quickly get a bug fix or urgent deployment through the flow process by cherry-picking it each time in each of the branches, but this seems like a silly approach for a “normal” process. Anyone out there have any ideas or practical examples they would care to share to help a dummy like me out? I would be forever grateful. TIA

The obvious solution is to simulate the manual testing of end-users as part of MR and going directly to Production A more cautious approach would be to deploy to Testing as part of MR pipeline (maybe after it’s approved?) and merge into main only after all testing is done and verified. But this also depends on what/how you do deployments and what’s the architecture of your application (in other words how small parts of it can be deployed separately).

If you want to keep Testing as a separate branch supporting multiple features in development at once, cherry-picking is the only solution. What I do miss in your flow is what happens when an issue is discovered during the manual end-user testing while a feature is already in Testing?

The idea is indeed to merge code from main branch to testing branch through an MR once the developer feels it is ready for user testing. I suppose if a bug is discovered in this part, the particular feature branch can be reverted (removing it from testing but keeping it in main?) Or a new feature branch would need to be created to fix/patch the bug, attach the new feature branch containing the patch code to the existing issue and starting the process from the start. But your question opens a whole new can of worms.

The majority of the code to be released are Java applications, and the idea is to start building out microservices to indeed get rid of huge inter-dependencies. What is your current approach? How do you do it? I am open to any suggestions from community members that currently have a functional flow and sticks to rules and best practices.

@hanserasmus I am also learning about Gitlab, I will share my scenario maybe it can help you to figure out a solution for you.

In my scenario: we have three branches for a project: “develop”, “test”, and “main”. When a fix or new feature is needed the developer create their working branches and push it to “develop” branch. If it pass all tests required, we merge the developer’s branch into “test” branch to continue evaluation from QA. If it passes, the developer’s branch is merged into “main”, this way only passed fix/features branches go to “main”. Developers have to keep in mind that their working branches must be branched off “main” allways, this way they are working with a clean code.

I hope this helps.