Is there a better model for my CI/CD cycle?

Question

I am having some troubles finding a better model for my CI/CD cycle.

This is mainly gitflow issue.

My current model : We have 2 bitbucket branches : master and develop.

Both are linked via webhooks to jenkins to be deployed to prod. and dev. servers.

QA team for testing features and releases on dev. server.

Team of developers for both frontend and for backend. With lots of troubles.

The problem : Team manager wants to be able to have better control over accepted/rejected features. Say : developer1 committed a feature to develop branch, developer2 added a hotfix to develop, we want QA team to easily test them both separately, and then testing both together with the least hassle possible. And afterwards easily select what commit stays and moved to master branch.

As I said, this is mainly gitflow issue.

Any suggestions?

Answer 1

Key issue with this approach is that applying commits selectively is extremely problematic. Basically, how do you know whether commits are dependent or independent?

As you correctly mentioned, this is one of the issues with Gitflow itself, so the solution is shifting methodologies. Preferred way today is Trunk-Based Development (TBD) - https://trunkbaseddevelopment.com/ - refer to "Accelerate" book for evidence.

Under TBD you can choose a style of work where you have short-lived feature branches. Once a feature is complete, pull request is created and QA can test this feature selectively under such short-lived branch and then approve the merge to main.

This way you know that your branches are independent (unlike commits in Gitflow) and approve features selectively. Note, that you can achieve something similar in Gitflow with multiple different branches, but this gets extremely messy there.