Over a million developers have joined DZone.

Internal & External Releases

· Agile Zone

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

A recent post on InfoQ discusses a two part article by Israel Gat that argues in favor of internal vs external releases by decoupling the engineering aspects of a release from the marketing and sales aspects. By doing so, the engineering team can release the product internally on a frequent basis and the business is free to temporally choose the release they would like to promote. I agree. That sounds grand. But in part two, the author diminishes the effort of all that goes into a software release by stating:

From an engineering standpoint, a release is merely a branch in the
code tree, representing a packaging and distribution decision.

A software release involves much more, especially if the business is allowed to freely choose which release they promote to the public. In general, a software release requires that certain lifecycle activities be performed, including build, testing, and more. The frequency with which a team can release is going to be directly tied to the ability of the team to perform these other lifecycle activities.  And there is a cost to these lifecycle activities.

In a session at Agile 2008, David Anderson discussed Future Directions for Agile, where he elaborated on these costs. The beginning and end of any value-added activity involves transaction costs. He goes on to state:

The prevailing paradigm in Western management were that overheads
(transaction and coordination costs) were inevitable and efficiency was
achieved through economies of scale (large batch sizes)

Because of the transaction costs surrounding SDLC activities, including build, test, and other release management tasks, the economies of scale motivate teams to release software less frequently. Is it really possible to adequately perform all engineering activities necessary to ready a software system for release on a weekly basis? And isn’t there a lot of waste involved in doing this if the business only chooses to promote a small percentage of internal releases? Absolutely…NOT! Dr. Gat is spot-on in that it can be done, and it should be done, but he doesn’t really tell us how to do it.

There is significant advantage to ensuring a software system is in a continuously releasable state because it allows the organization to bring the right product to market at the right time for the right customer. So the million dollar question must be this. How are transaction costs surrounding a software release effectively eliminated to provide the increased efficiencies without requiring economy of scale? Beyond saying that agile practices play a role, I don’t believe Dr. Gat answered that question in his articles. But if I were a betting man, I’d say that Dr. Gat’s teams leverage a pretty effective continuous integration strategy. Because if they don’t, I don’t know how they can pull it off.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.

Topics:

Published at DZone with permission of Kirk Knoernschild. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}