Protect development at all cost
This post has been imported from my previous blog. I did my best to parse XML properly, but it might have some errors.
If you find one, send a Pull Request.
Some time ago I wrote a few entries about my attitude to the GitFlow and a small adjustment that can greatly reduce the possibility of breaking development/release branches. The main reasoning was following: review, build your merge commits in your feature branches, then using fastforward-only merge apply it on develop. Having this applied should keep your development, healthy, right?
Not at all. The final step is pushing changes. And it’s a manual step, as ending the feature is. If that’s a manual step, there’s a bunch of things that can wrong. Yes, you can push quick-fixes, fixups, minor-improvements to development and say to your whole tea m “it’ll be there in a sec”, but isn’t it easier to just don’t break things? Having that said, is possible to be guarded against push that isn’t proper? Yes, and my automation for this is simple:
- use git prehooks
- add check against TeamCity API if the build is ok
- add check against a code review tool
- allow push only if the checks are successful
In the following posts I’d present how to
- create git hooks, preferably using PowerShell (“You won’t be able to run on Linux oooooh nooooo!”)
- successfully get statuses and consume TeamCity API
- combine this to revoke commits that might hurt development branch
Stay tuned!
Comments
Definitely use PowerShell ;)
by Michael Burns at 2015-12-04 21:23:28 +0000
Great thoughts. Personally I believe that "the root of all evil" when it comes to pushing to the development branch is all minor fixes, features and refactors. It is just like you mentioned - since in the final flow step, there is a huge human factor, reducing it is the only way to lower the risk of breaking a build. Just a quick thought - I think we, the people who call themselves software engineers - turn a blind eye to often when it comes to all continuous build remarks, alerts and warnings. As long as we have team members, who are like "yeah, I've just broken a build, let me fix this with following 5 rubbish commits", we can fight and try to protect development, but it is still tilting at windmills.
by Kamil Mrzygłód (@Kamil_Mrzyglod) at 2015-12-06 19:40:36 +0000
[…] the recent post I’ve shown the need of securing the development branch in GitFlow. The same should be applied […]
by Git plumbing with PowerShell | Extreme .NET programming at 2015-12-09 09:00:47 +0000
