Share this content

Ecommerce deployment: How to avoid delays and disappointments

by
5th Jun 2014
Share this content

When everything is approved, tested and ready to go, one thing stands between the updates and your customers: deployment.

Of course, replatforming, introducing innovative new features or responding to user testing are important in order to stay ahead of the competition, but the deployment of a major ecommerce update is when the most can go wrong. It is therefore important to plan ahead in order to avoid a deployment disaster and ensure that when the hypothetical switch is flicked the process runs seamlessly and effectively.

Be prepared

The old adage “fail to prepare, prepare to fail” resonates in these situations, where it is vital to anticipate problems and potential downtime. A roll back strategy prepares for the unexpected and allows for changes to be undone should something go wrong. However, it is important to note that sometimes simply fixing the problem and accepting a few hours of downtime can be less time-consuming than rolling the entire deployment back and repeating the whole process.

Accepting a certain amount of downtime to fix a relatively small issue can sometimes be a better option than instigating a time-consuming rollback. Things such as payment integrations can also be difficult to test properly; hence problems can arise during deployment, so it is important to undertake manual tests prior to the go-live date. Software is available to test such integrations in a simulated production environment so if new payment processes are part of the deployment plan, this type of technology is vital.

Keeping the developer’s computers, development servers, staging servers and production servers separate allows for freedom to develop whilst also maintaining control of the final code. This also allows for testing at each stage of the build without causing disruption to the development cycle. It is important to ensure that all environments are running the same versions of software and hardware to maintain consistency during the testing process to avoid squabbles about whether it works on colleagues’ machines which may run on different operating systems.

Preventing delays

In the interest of preventing delay, be aware of database processes that could take a long time to undertake. It is important to test deployments with production levels of data in advance so the team has a realistic idea of how long it will take. This will then allow for accurate planning of potential downtime.

Delays may also arise due to downtime, or the risk of unplanned downtime. When possible, this should take place out of hours, or at a time when trading is at its lowest point. It can also be tempting to get an update out before the weekend but deploying on a Friday, for example, can set up a team for difficulty should there be issues when people are hard to reach. Problems can often take days to emerge, meaning that your site could potentially go down for hours. Deploying earlier in the week means that issues are less likely to happen at inconvenient times. Also, be aware of database processes that could take a long time to undertake – for example, adding database columns. Once again, testing deployments with production levels of data gives you a realistic idea of how long they will take and allows for planning downtime.

Communicate

It may seem glaringly obvious, but teams must communicate! There should be an open line of communication between the developer, agency, management and retailers. Everyone should be educated about the potential impact, time necessary and problems associated with deployments. All teams need to be coordinated around a fixed deployment slot to prevent embarrassing mis-messaging. For example, a marketing department sending out a 50% discount voucher should not happen at the same time as an update or when the site is down. It is useful for team members to agree fixed deployment slots ahead of time to avoid individual parties pushing for rushed deployments that may not be appropriate at that moment.

Break it down

We have all heard that “less is more” and in fact, sometimes doing less more often can be the best approach. Breaking up a large release into smaller deployments can be very useful in identifying issues and breaking down of downtime to lessen the overall impact of the changes on consumer experience. In essence, it’s important to ensure all issues are resolved before deployment, enabling a rigorous checking process and also that it feeds into the rollback strategy.

Returning to our “fail to prepare, prepare to fail” adage, without the right development processes and policies in place, it is very easy for a developer to forget to commit all of their code to the server before deployment. Adherence to proper deployment protocol, rigorous checks and testing will ensure that complete code will be ready to switch from staging to product each and every time.

The deployment process will never be completely issue-free or “de-risked”, but by taking a few simple logistical steps teams can prepare for the worst whilst doing their best to ensure that the worst never happens.

Preparation checklist

Finally, here is a summary of what you can you do to ensure that the deployment of your new platform, or of important revisions to your existing one, run seamlessly and effectively:

  1. Have a roll back strategy. A clear strategy, allows you to prepare for the unexpected and gives you a second chance to undo the deployment if necessary.
  2. Check payment processes. Payment integrations can be difficult to properly test in the build process do manual tests before you go live.
  3. Keep development environments separate.
  4. Think about timing.
  5. Never deploy on a Friday. This can set you up for hard-to-solve issues over the weekend when people can be difficult to reach.  
  6. Consider database processes. Be aware of database processes that could take a long time to undertake.
  7. Communicate.
  8. Minimise the size of deployments. Breaking up one big release into lots of smaller deployments means you can quickly identify where issues are coming from.
  9. Document. By using a ticketing and bug tracking system to document your code, you can check commits against ticket numbers in order to ensure that all issues are resolved before deployment.  
  10. Ensure that the right deployment policies and processes are in place.

Darryl Adie is managing director of Ampersand Commerce.

Tags:

Replies (0)

Please login or register to join the discussion.

There are currently no replies, be the first to post a reply.