CMCrossroads
Published on CMCrossroads (https://www.cmcrossroads.com)


[article]

Things about Release Management Every Programmer Should Know

By Steve Berczuk - April 11, 2010
Summary:
I was privileged to contribute to the book 97 Things Every Programmer Should Know: Collective Wisdom from the Experts. Here are link to a some of the posts I found particularly interesting.

As I mentioned earlier I was privileged to contribute to the book 97 Things Every Programmer Should Know: Collective Wisdom from the Experts. In addition to the contributions about coding and design, I was pleasantly surprised to see the number of items that relate to release management. While I've long been interested in how to build architectures and processes that make deploying and releasing software easy, I sometimes get the impression that these items were often though of necessary evils that could be done at the end, often by the someone who isn't doing "more valuable work." Much like awareness of agile software development made it obvious that testing and quality assurance activities work best when they are integrated throughout the development lifecycle, agile has also made it more obvious why build and release engineering is something to work on as you go. This makes a lot of sense, as ease of release is closely tied to the physical architecture of the system, and your build process defines the physical architecture.

Some of the posts of interest are the following, though I could have added others than related to testing as well.

  1. Deploy Early and Often by Steve Berczuk
  2. Install Me by Marcus Baker 
  3. Keep the Build Clean by Johannes Brodwall
  4. One Binary by Steve Freeman
  5. Own (and Refactor) the Build by Steve Berczuk
  6. Put Everything Under Version Control by Diomidis Spinellis
  7. Step Back and Automate, Automate, Automate by Cay Horstmann

Aside from being excited that programming experts understand the importance of build, release, and installation mechanisms, I was also excited to see that one topic that people associate with SCM wasn't mentioned: Branching.

Branching is a useful tool when used in the right context, but more often than not, branching is used as a way to avoid issue rather than to address them. Rather than branching because there is a true divergence in the code, we branch to avoid breaking existing code. The problem is that doing so simply defers a cost. Sometimes deferring the cost makes sense. Often it's better to invest in the techniques you need to enable incremental change while keeping the codeline working.

97 Things Every Programmer Should Knowis about much more than just coding, or just release management. And that's the point: programming is a multi-faceted skill and to write good code, you need to know about more than just writing code.

 


About the author

Steve Berczuk's picture

Steve Berczuk

Steve Berczuk is a Principal Software Engineer with experience as a manager, Scrum Master and technical lead in Boston, MA. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a Certified ScrumMaster. Contact Steve at [email protected] or visit berczuk.com and follow his blog at blog.berczuk.com.

Connect with Me

  • http://linkedin.com/in/steveberczuk
  • http://twitter.com/sberczuk
  • http://blog.berczuk.com
©2011-2013 TechWell Corp.