Posted by: Jeff Timmins | September 24, 2013

Thoughts on Release timing

When is it a good time for a Release?

Because of world-wide usage of the Internet, there is no good time for most solutions. Due to that, the Release timing usually comes down to what time is good enough.

I should add that if you are asking the “timing” question you need to consider that your deployment tools and/or infrastructure and/or the solution design has probably failed you. This is 2013, in theory deployments to Production should be performed without impact to customers. A deployment without impact could happen whenever your internal resources were available. Okay enough theory, now onto reality for a number of you out there.

For good enough Release timing, the first item to consider is how long of a change window is needed. This “window” should include time for deployment of the code, any configuration changes outside of the deployment process and validation (including Business owner testing, QA & verification that Monitoring results are as expected). Also to be considered is enough time for a rollback if the validation fails. Note that if this is a new process it could take a number of deployments to come up with an exact amount of time for all these tasks. While waiting for that exact timing make sure to add lots of buffer time to your estimates.

Next you will need to look for a possible Customer Service Level Agreement (SLA) from people in the know. If created between your company and the customer, the SLA will provide the first timeline restriction to consider. Solutions like Salesforce.com or Workday are likely to maintain an SLA with their corporate customers where solutions that deal directly with the consumer will not typically provide an SLA.

After that, it is important to consider customer usage patterns during the SLA timeline. For example, if the customer’s SLA states that changes can only be made between 12:00am and 5:00am Pacific Time then only focus on usage patterns during that time. If there is no SLA then your options are wide open. Hopefully the Monitoring team will provide the user activity data for your solution in a format easy to access and understand. Once you have the data, look for the day of the week & time of day that shows the lowest amount of usage (i.e. the least amount of impact to users). I’d suggest reviewing the last 4 instances of your choice to confirm you found a good window.

When picking the “good enough” time you should understand the impact of the deployment for customers that may be using it during the change window. For example, during the deployment is the whole solution unavailable or is it possible that users will see a small interruption? As expected, the less the impact to customers the more flexibility you have with the change window.

Lastly, and only if you want to be nice, try to consider when it is convenient for your customer to preform their validation processes as well as when is it a good time for your team-members to be online. These things are typically items that few companies have the luxury to think about but should be on your radar.

Disclaimers

  • I’m not a big fan of “site down for maintenance” pages so I didn’t address it. I just think using it doesn’t put the customer first.
  • For my LinkedIn Release Management friends, I’m defining “Release” as deploying (i.e. installing) new code (i.e. changes to the current software installation) to Production systems (i.e. used by internal or external customers for their work, productivity or entertainment). Hardware changes to support a code update are another topic.
  • If you are the kind of organization that doesn’t like to rollback and you take the “fix and go forward” approach – good luck with that. I’m a rollback kind of guy but anyway … you will need to remember to base your window on how much time you are willing to deal with errors in Production. You could be of the mindset of “fixing forever” or you might give your team a limit until a rollback is invoked.
  • This post doesn’t deal with how often code should be deployed to Production because in my opinion that really depends how often the Development team can provide stable changes. I’ll leave that discussion up to them and because of that I did not address the Daily, Weekly, Monthly or Quarterly question.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: