5 Most Common Deployment Mistakes

Admittedly, there is no such thing as the “best deployment procedure”, but there are definitely some obvious common deployment mistakes. Here is a list of them and some ideas on how to avoid them.

Deploying infrequently

A lot of people still seem to believe that you should release when you’re ready – the traditional way of shipping software (or should we say “conservative”?) suggests that every code change must be approved by other team members and the project leader before it goes live. This often involves long online and offline discussions, followed by a more or less extensive code freeze period. Most developers have probably been involved in a project like this, they’ve worked overtime to meet a deadline, not getting enough sleep or time for their social life.

It’s not necessary to make releases this stressful. Why not deploy more frequently? Instead of feature-based releases, try to implement time-based releases and deploy as often as you can. Using a tool like DeployBot can help you to set up a process with short-lived feature branches and dynamically created staging environments. You can stop discussing code freezes with your fellow developers now and get back to work (or to your hobbies). 

Talking about setting up a deploying pipeline… It’s a good idea to think about automation, which brings us to the next point: try to automate as many things as possible and try to avoid manual deployments.

Deploying manually

Whether it’s laziness or the fear of change, some people seem to be quite reluctant to consider reviewing and altering their workflow. “Never change a running system”, we’ve all heard that. When it comes to software deployments, it makes sense, though, to evaluate existing processes now and then. Above all, you should consider automating things in your deployment pipeline.

So, what exactly is the problem with manual deployments? First of all, manual deployments lack consistency. It’s easy to forget something on the way, and if that “something” is vital, you’re risking downtimes. Also, manual processes often lack good documentation: who did what and when and why? 

The more people are involved, the more complicated it gets. Maybe one of your co-workers sent long emails, maybe a fellow developer one wrote something down in a chat window, and then there was this creative approach by a third team member who told you about it on the telephone afterwards. If something goes wrong, good luck finding the actual mistake – such an investigation can be time-consuming as well as frustrating.

Automation will help you to avoid mistakes and make workflows more transparent. Of course, that doesn’t mean that you should automate everything. Sometimes it’s a good idea to deploy manually, especially to a production environment. Automatic deployments in a production environment can lead to surprising results – and quite often it’s not a nice surprise. Please stick to manual deployments for your production sites to avoid downtimes.

Waiting for the right moment

Ever heard yourself or your co-workers say "let's wait for the weekend before we push the changes to production"? Has your project manager suggested that you deploy something late at night during low-traffic hours? In that case you should probably ask yourself if you really trust your deployment pipeline. Closely related to the first two common mistakes is this one: waiting for the right moment instead of deploying changes when they happen.

Most of the big players deploy during working hours, with good reason. After all, this is when most people are online and can react. Deploying during low-traffic periods can be the right approach for crucial systems or services, but why not try a different strategy? Deploying during business hours has another advantage: you don’t need to steal family time from anyone in your team. Plus, in case of trouble you have the other team members around and you can work together to solve the issue. Which brings us to the next point: do you have a backup plan?

Not having a Backup Plan

Even after extensive tests on a staging environment things can break. Most of us have been in a situation where the shiny new feature didn’t work as expected or – worst case scenario – broke an entire system, which is why it’s good to have a backup plan. In order to avoid further complications you should not only carefully plan backups for your data, but also implement a safety net for your deployments.

A tool like DeployBot can help you to develop a good release strategy. It works with various version control platforms (e.g. GitHub, Bitbucket, GitLab, etc.) and makes it pretty easy to roll back to a previous software version. 

Forgetting to monitor the changes

You’ve pushed your code, it’s running fine without any trouble, time to go back to work and develop the next cool feature. But wait, are things really fine? Have you checked the performance, or rather: have you set up a tool or service which does the monitoring for you? DeployBot integrates with monitoring and error tracking solutions like HoneyBadger, Bugsnag, and New Relic.

All three services offer uptime and performance monitoring for your applications as well as sending out notifications. This way you can keep an eye on your code after you’ve released it and track how deployments affect your applications.

Conclusion

There are multiple ways to deploy new versions or features of your applications, and there is no one-size-fits-all solution. Before deciding on a strategy which works for you and your team, have a look at the common deployment mistakes and try to avoid them:

• deploying infrequently
• deploying manually
• waiting for the right moment
• not having a backup plan
• forgetting to monitor the changes

I hope this was useful – if you have any feedback, please leave a comment. In our next article we’re going to check out the 4 most common DeployBot mistakes – stay tuned and happy deploying!