Are you Release Ready?

Assume for a moment I could give you “DevOps in a Box” and you could start delivering via an orchestration release system in an automated, repeatable way today.  Would you be ready for it?  What would you have to change in your teams to use it effectively?

I bet your teams would be only slightly faster than they are today, if at all.  Many times with CD our thinking and process is more important than the tools or frameworks we have in place.  After we automated our deployments we immediately struggled with our ability to get the code ready to deploy.  For example, assume you have three user stories completed and in a UAT environment awaiting approval for production.  Now imagine the product owner only approves two user stories and files a bug against the other.  What would you do?

If you said fix the bug really quick and get the fix into UAT so the product owner can approve them all, you are not release ready.

“Release Ready” means any code commit may be released to customers at any point.

If you wait to deploy the approved stories you delay providing value to your customers.  What prevents you from pushing only the approved user stories to production?  We use the term “Release Readiness” on our Kanban board to represent our plan for this situation and other impediments that prevent us from deploying code.

There are two main categories of issues with release readiness:

• Breaking Existing Consumers – Will you break your existing consumers, customers, other dependent code, etc.?
• Work in Progress – Can you hide changes that are not done or approved and still deploy other changes?

Breaking Existing Consumers

You can’t afford to wait on other development groups to implement changes before deploying your changes.  Likewise you can’t wait on other developers in your team to complete their work before you complete yours.  Think about how you can finish and deploy your work without waiting on others.  You can always come back later and fix bugs found in a new version down the road.  Code becomes stagnant waiting to go to production, push it as soon as reasonable.

Examples

• Web services – don’t update services, version them and then work with other teams to get them up to the latest version.
• Databases – don’t make breaking or destructive changes like renaming columns (instead create a new column and copy the data) or update proc parameter names (create a new proc instead), then cleanup deprecated objects after all users are updated to use the new objects.
• Website redesign – don’t change the default design of the website, instead make it configurable by the user to opt-in.

 

Work in Progress

Nothing feels better than to thrash on an ongoing issue and hold up your co-workers [sarcasm].  Don’t be that guy.  Have a plan for hiding or disabling your changes so others can deploy to production and not have to wait on you.

Examples

• New web page – don’t start with adding navigation to the new page, start by creating new page and navigate to it manually until its ready.  Users will never see if there is no navigational link to it.
• Refactor middleware method – don’t update an existing method, create a copy of the method to refactor and unit test then swap to use the new method when complete.
• Complex broad reaching change – in some cases changes cross several systems and you need a more advanced solution.  Use a feature flag framework or maybe a configuration setting to link all the related changes with a single toggle.

 

This all boils down to your work is either done/approved to be delivered OR your work is still in progress.  You will likely be in both situations during development so have a plan for both.  We ensure developers work Release Readiness analysis into their development process by adding it to the definition of done for the analysis phase on our Kanban board. 

Feature Flags/Toggles

Over time we found it was easiest to just wrap each new change with a feature flag.  This makes it so easy to toggle features on and off in any environment without requiring a rebuild of the code.  Its also nice to use the same toggles to make feature or integration tests aware of the toggle state and test appropriately.  The one caveat is you have to remember to go back and cleanup your old toggles when they are no longer needed.

Start Today

No matter where you are on your CD journey, your team can begin to adopt Release Readiness and get value from the practice.  So try it today and let me know how it goes.