2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- March 23, 2016
- Bits and Pieces
If there was a button on your computer that said “DO NOT PUSH,” would you push it?
If you push the button and a hand comes out of the monitor and slaps you on the face, would you push it again and again?
Of course not! But then why do you continue to use branching in version control? I understand that there are some legitimate uses for branching but it’s often overused, and feature branches are almost always a bad idea.
As soon as a branch is created, the system’s capabilities become divergent and the cost of bringing those pieces back together again can be very high. Branching development either by team or feature may seem like a good idea up front because nobody’s code affects the other people, but this can cause problems when integrating code later. Creating branches in this way is only postponing the inevitable, and postponing these little problems along the way causes them to become big problems later on. Integrating code becomes a bigger problem the longer you wait. So it’s better to integrate as soon as possible and best to integrate continuously.
Continuous integration may take some time to set up, but it pays back huge dividends rather quickly. The pain of integration and testing goes away and is replaced by a build system that gives valuable and immediate feedback to developers as soon as they check in their code.
Continuous integration provides the infrastructure for agility. In fact, I believe that continuous integration is at the very essence of Agile. If you integrate code as it’s built, you’re doing Agile. And if you wait to integrate code, even if it’s just a few weeks, then you are not doing Agile no matter how many stand up meetings you have. Iterations must end with integration, and ideally, developers integrate their code as they’re building it.
But how do we integrate features into a production system as it’s being built without using branching?
I’m glad you asked. It’s a good question and the answer to that question can be found in my next blog post: Use Flexible Feature Flags.
Until then, happy coding.
Previous Post: « Outside In or Inside Out
Next Post: Use Flexible Feature Flags »