Channels ▼
RSS

Embedded Systems

Not All Release Management Is Created Equal


Application delivery specialist Serena Software is usually vocal on the subject of software rollout out inside what the firm terms an "orchestrated" IT environment. The firm's chief evangelist Kevin Parker states that not all software releases are created equal so it is a false premise to have standardized processes, controls, and deliverables for all releases.

Parker contends that release teams want to be able to vary the controls imposed during the release process to meet individual project needs at different stages in the project lifecycle.

"What this means is allowing developers to drive the release cadence in some situations and to allow operations to drive at other times. [We advocate] a collaborative approach amongst DEV, DEVOPS, and OPS to determine where the 'trust line' is along the release continuum," said Parker.

In Serena's view, fast-paced projects need continuous delivery during test and integration and should be "as repeatable as possible" and have minimal controls to maximize velocity. This will mean that automation of every step of the process is essential to maximize speed and minimize error.

According to Parker, automated instantiation of test environments (physical, virtual, and cloud) and automated deployment to these environments is essential to maintain that delivery cadence.

"But that does not mean throwing out the pre-production verification, controls, and reporting. Once the trust line has been set this becomes the point at which appropriately defined, service-transition processes are invoked. Once again though, we believe that, on a project-by-project basis, controls should be set accordingly. Critical to this is a central IT-calendar so there is clear understanding of which projects cross the trust-line and when, what their current trajectory is," said Parker.

"Our goal here is to liberate the DEV teams so that continuous delivery is no more complex or involved than using the version management system. We want to facilitate the agility of the team to meet the project's profile while ensuring the organization governance is complied with but not in the way," he added.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video