At the dawn of time all we worked together on source code in shared folders and a couple of problems arose. First we needed to call out to colleagues which files we were working on, locking out other team members to work on the same files. Second we had no history on the files, when we screwed up, we had to fix it and sometimes that was painstaiking. And third we lacked backups of source files. To solve this we started to use an SCM.
With an SCM we could work on multiple files, without interfering with other team members. There was a track record of our changes through commit messages and we could talk about specific revisions or versions.
An SCM comes with the possiblities of branching and tagging. Soon we used tagging to point to a specific revision in history to mark our releases. And we started using branches to create a personal development space. A personal space was good because most of our team members worked on different changes.
So what was the problem that branches solved for us? When we all worked on different features on the trunk we encountered problems with merging, multiple team members touched the same code, working with our own branch made it possible to develop in parallel. The con is that we introduced merging hell further down the line. Testing was done manually most of the time and we needed to create a solution to waterfall to a release, hence can git flow. A model to overcome the problems with branches. With git flow there are feature branches on which developers can work on their features, run unit tests and deploy to a development area. Then when all integrates well the feature is promoted to the development branch, again tests are run, it get's promoted to a release branch and again some more tests. Then all is merged to trunk and brought to production. Sounds waterfallish to me to be honoust. And git flow is a fix on a fix. It fixes problems on branch development. But shouldn't we just fix branching in the first place?
With a lean thought in mind where waste is evil, branching is a perfect way of introducing waste. It gives developers the opportunity to work on items that are not delivered. When working in teams, expecially in agile teams, the most important thing is focus. Working on features together is more important than working on multiple features at the same time. From XP we learned that pairing results in short feedback loops, improved quality and better architecture. Put this in practise and stop branching. Just work on the trunk. Working with a DVCS over a CVCS makes this even easier.
But when should we branch? Keep in mind that we only work on code that will actually go to production, but sometimes we need to experiment. If the experiments are small, they can be done on the trunk. If they are bigger or oppose the proper functioning of the trunk, they should be branched. Although with feature toggleing an experiment can be done on the trunk as well.
Another reason for branching is that tests are not fully automated or take too long to complete. Improve the testsets and think about what you need to test, instead of running all the tests all the time, be wise.
Altough I was a big fan of the branching model, I now understand that it introduces waste. It overcomes a problem that shouldn't have been there in the first place. Sometimes branching is good, but by exception.
Sources:
- https://www.git-tower.com/learn/git/ebook/en/desktop-gui/basics/why-use-version-control
- https://trunkbaseddevelopment.com/
- https://www.quora.com/Why-do-we-need-branches-in-GIT
- https://datasift.github.io/gitflow/IntroducingGitFlow.html
No comments:
Post a Comment