Branching and Continuous Delivery video discussion

Comments

2 responses to “Branching and Continuous Delivery video discussion”

1. 

   Christoffer Holmstedt

   July 7, 2015

   Interesting discussion and it would definitely be interesting to listen to more of it. I have some thoughts/questions concerning the issue being discussed.

   First thing to hear more about would be from Olve and Dave concerning what their experience is with the version control logs and how they are used. In those project I have practiced the “commit to trunk” as often as possible the history (most often git log) isn’t worth a lot. Most commits end up being useless when you figure out the best solution on your third attempt. In comparison when submitting patches for the Linux kernel, patches must be squashed or split into logical steps that makes sense for others to review. This step that each developer must prepare the changes into logical steps that are easily understood by other developers (and myself in the future) is possible with the CoDe:U workflow but not when everyone is always committing to trunk/master all the time.

   Another issue when I commit and merge back often (without mandatory pre-commit checks) I can suddenly get a build error that I try to debug which in the end turns out to be that someone else missed a semicolon or similar which is a big time sink when it happens.

   The second concern I have is that the discussion is maybe going around in circles due to scope in the questions/answers. Mike’s and Lars’ point of view is more from the Continuous Delivery/Deployment angle while Olve and Dave is talking more about Continuous Integration, at least that is how I hear it now. I miss the Delivery/deployment part from Olve’s and Dave’s reasoning. In the CoDe:U workflow every commit in integration branch could be a new release with added functionality or bug fixes but from Olve’s and Dave’s reasoning if unlucky some dead/WIP code not used could be included in a release.

   As maybe obvious from my comments above I’m currently leaning towards that a branching model like CoDe:U is better than letting everyone commit to trunk in a free-for-all. Though as a last not I must say that Olve’s idea about making it really attractive for everyone to integrate often is something worth striving for.

   Reply
2. 

   Dave Farley

   September 11, 2018

   I guess the first question depends on how important you think the change-log is and what it is for.

   Is it equally, or more important than working software? That statement is, I know, a bit extreme but is *kind-of* accurate. The change log tells a story, but what is the story? If I connect my “story/requirements management system” (JIRA etc) to my commits via a tag in the commit message, I can trace every commit to a story.

   Analysis from the “2017 State of DevOps Report (https://puppet.com/resources/whitepaper/state-of-devops-report)” found the following:

   “High performers have the shortest integration times and branchlifetimes, with branch life and integration typically lasting hours.

   Low performers have the longest integration times and branchlifetimes, with branch life and integration typically lasting days.

   These diferences are statistically significant.”

   Do I really care that this commit made the button blue and the next commit made it green? I know that the commit was related to the story, so from the perspective of an audit trail of work on the story I have a definitive statement.

   From the perspective of a developer wanting to know what change did what, I have a more detailed picture of what any given change did what, because it is more granular. I can build up the story, in fine detail of the evolution of the ideas. I have more information not less.

   I confess that I don’t really understand the desire for a “clean change log”. What does that mean. It seems to me to imply an assumption that once I have finished a “Story” I am done. I don’t believe that software development is like that. However I work, I am going to be returning to the code over and over again and refining and updating it as requirements are added and as my understanding evolves. So even if I have a log entry-per commit, I still need to read them all to know the state of the system, the only difference is one of granularity.

   Not sure that “pre” or “post” commit checks make any difference if the team adopts CI discipline. If I, or another team member, break something, including compilation, my (automated) coding-standards, or a test the commit fails!

   CI is foundational to CD. “Continuous Delivery” does NOT equal “Continuous Deployment”. “Continuous Delivery” is working so your software is always in a releasable state “Continuous Deployment” is automating the deploy to prod if all the tests pass.

   CI is – like all things – a compromise. If we choose to go down that track we incur the need to be disciplined in our changes. Every change needs to leave the software passing the tests, and in the context of Continuous Delivery, releasable. So we use techniques like “Dark Launching”, “Branch by Abstraction” and “Feature Flags” to help us grow complex features over a series of commits – it works, and the data says that it works better than the alternatives.

   You can read more about my thoughts on Feature Branching here: http://www.davefarley.net/?p=247
   more on “Feature Flags” here: http://www.davefarley.net/?p=255

   Reply