Dialing Up Your Application's Release Cadence

DZone 's Guide to

Dialing Up Your Application's Release Cadence

When cranking up your release cadence's speed, it's wise to take it slow, rather than getting in over your need with the new speed.

· Agile Zone ·
Free Resource

When trying to get to Continuous Integration (most enterprises are not really there yet - nightly build isn’t CI), or trying to get to Continuous Delivery or Deployment from mere CI, it is wise to not attempt to fast-forward to your intended release cadence. You should really only turn the up dial a little versus where you are now. Then you should measure how successful that was and plan the next dialing up.

You should also worry about how many defects you get per release. You should not plan to stay where you are with that. You’re going to need to work out how to ‘dial back’ defects per release, as well as how to solve them quicker.

Oh, and remember to get ‘safe to fail’ locked in with the business.

Of course, how to score your defects per release is a factor too. Visibility to the business as well as cost by some definition are factors, so it may not be as simple as “defects per release.”

Lastly, new teams making applications or services should be attempting to carve a path to production (dark deployments, etc.) for the first non-viable “Hello World” version of their application. Hopefully, that’s one of the two CDs, and they should fight hard to not lose that ability, including making new ‘controls’ for it if sign-offs and passing audits is a requirement.

agile ,ci/cd ,continuous deployment ,continuous integration ,continuous software delivery

Published at DZone with permission of Paul Hammant , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}