The “develop” branch
Why?
I work with a lot of different development teams. For many teams I’ve seen them create an integration branch called “develop” for their work. It typically is used to merge each developer’s feature branch together so the team can test things more completely before they are ready to call it done and merge to the release line. I’ve also seen cases where “develop” becomes the main release line.
I struggle with this concept and have had many debates with a lot of different team members. In most cases, the root reason is because the team doesn’t trust the feature branches will not break production so they want an extra level of manual testing before proceeding. This also has a root cause of a lack of good automated unit tests. Another reason I’ve been given, is teams are just fearful of breaking the release line.
Many of these discussions occurred while I was helping our organization move to automation for many of our heritage products. In this context, it is understandable since there was no automated tests, no continuous build and it was largely a foreign concept to change the release line until integration testing was complete.
However today I still see many teams doing this “develop” branch and I have to wonder why, when agile practices and automation are so much more prevalent and standard.
Get Stephen Paulin’s stories in your inbox
Join Medium for free to get updates from this writer.
If you are one of those teams that uses a “develop” branch, please comment on your reasoning. I enjoy understanding the varying perspectives. However, I truly have to say using a “develop” branch is a bad practice (code smell?).
Current development practices with source control systems drive a powerful model to commit changes frequently and merge and deploy often. For this reason a “develop” branch really isn’t needed since the release line should be updated with small incremental changes. With good unit testing backed by an automation system, the probability of releasing a breaking change is reduced.
Another thing, if you have good testing practices and an automated build system, then don’t be afraid of braking the release line. The failure will be caught quickly and source control allows you to easily roll back or make another change. Trust in the power of your source control system and testing practices.
It’s also good to break things every once in a while. First, it proves your system is working correctly to catch defects. Even better, you will learn much more from breaking things.
Disband using the “develop” branch or any other that prevents you from progressing quickly. Work on your feature branches and check they are working with your unit test (and automation). Its best to use merge request builds to verify the merge will be good too. All this should give you confidence that your release line stays stable and can be updated without the extra effort of an addition “develop” branch.
If you truly don’t agree, I’d enjoy hearing why in the comments. If you do agree then clap. Happy coding.
I enjoy receiving comments and suggestions so I can improve. If you like this please remember to clap and don’t forget to follow me for more content.
