Rituals-driven development
I tried to convince my colleagues about mainline development. They agree to it during the conversation but still follows Git flow style. There is a dev-branch, and PRs submitted to dev-branch is later merged to master.
The reasoning is that the master branch has to be “stable” all the time. I usually ask why not make the code always releasable. They say, yes that is a good idea. But the team falls back to the git-flow model. Merging PR a dev-branch and then to master, it is a complete waste of time. But the ritual continues..
My friend told me this during our recent conversation. The team consists for 4–5 programmers and looks like git-flow is a burdensome process for them. But most teams follow it because it is the standard.
Yes, its difficult to change rituals. Maybe it is because the importance here is for the code, instead of seeing the code as a means to deliver value. I feel if the team’s focus shifts to continuous value delivery to customers, the waste will be visible. And the team feels, the “rituals” don’t add value.
I am not saying trunk based development is right, and git-flow is always wrong. It is about being agile, adapting to the situation. Do it because it adds value, not because that is how we’ve been doing.
I’d Like You To Know the Definition of Agile…
…so you understand what it means to be agile.
medium.com
There are ways to keep the master branch stable without merge hells. Automated tests, pair programming, continuous integration, automated deployments, feature toggles etc. help to keep the code stable and releasable.
The same follows with retrospectives, stand-ups, planning meetings etc. too. Are teams doing it because it is a ritual or does it help in delivering a better product?
I hope my friend will be successful one day in using his time effectively than wasting on mundane tasks.
