Software Deployment

Software deployment is a big deal; without it, you wouldn’t be able to push any updates, fix any bugs or, hell, even push your product live in the first place! So, understandably, it can be pretty brutal when something along the line goes wrong.

Whether it falls down to a lack of proper testing or neglecting to run required DevOps scripts, deployment isn’t something that you can just rely on your memory for and hope for the best. Potentially your entire project can be shut down with one wrong move, so you need a documented, fool-proof way to guarantee that won’t happen.

Which is why you’re here! By following this checklist for each stint of software deployment, you can ensure a consistently solid approach to updating and fixing the product you’ve worked so hard on.

After all, won’t it be nice to deploy a bug fix and not worry about causing over a dozen more?

We thought so; let’s get started!

First things first, your software deployment needs to kick off with collecting the code that needs implementing. Although an obvious step, it is vital that you are certain that the update you later apply is the correct one.

This can be done by checking the completed user stories within your project management software or by checking the original message which prompted you to start off the deployment process. Either way, head to the correct fork in your code repository and get a hold of the update you need to implement.

Record a copy of the code using the form field below.

This is a nice and easy step to follow up with – you should now enter your code version’s release notes in the form fields below.

Although mostly for documentation purposes, this can greatly help in the event that you need to roll back to a particular update, or wish to track down the moment when a bug first occurs.

This will vary depending on your team’s setup and the project you’re working on, but in general, you must now check that the server you need to upload your code to is set up correctly and running smoothly.

If you only use one server, this should be easy. If, however, you need to organize a new server for your code, we have a handy little server setup process to help you on your way.

In order for your pre-production tests to be accurate, you need to ensure that your staging environment is set up correctly. To this end (and only if required), you need to make any necessary configuration changes to the environment, ready for your update to be put through its paces.

The method for this will vary depending on the setup of your server and staging environment, along with the configs that are required. In general, though, you’ll want to create a backup of your production server, copy that backup, make your alterations, then update your test server with the altered backup.

Don’t forget to restart the server after any changes are made!

The time has come in your software deployment for you to test the updates in the staging environment. To start us off, upload your new code to the testing environment.

This can be done (if using open source development) by merging the appropriate repo branch with your test environment and selecting the upgrade to be “Immediately”.

Whether you’re using automatic tests, manual tests or (better yet) a mixture of the two, now is the time to run them. Put the new update through its paces in the test environment and note your findings.

At the very least you’ll want to be running several integration and unit tests, but a good practice is to also just go through the test environment and see if any new vulnerabilities have been exposed by the update through simulating a normal user.

For example, if the update is to your login page, make sure that no hidden fields or data is shown by entering an incorrect password, etc. Be as thorough as possible and note down your findings for review shortly.

If you haven’t got set tests already set up, why not take a look at our software testing tutorial to get you off the ground?

This stage in your software deployment is pretty self-explanatory. You must now go over the results of your tests and assess whether or not the code is fit to deploy. Record the status of the test results in the form field below (which can be edited if you desire).

Now, we do not mean that the slightest error or bug should cause the delay of a major update; there will always be small errors which are missed or caused by an unforeseen effect. However, any problems caused by the code should be weighed up against the benefit (and functionality) of the update.

For example, it does not make sense to delay an entire feature’s release because of a relatively harmless bug, such as a user’s date of birth no longer showing on their profile.

Assess the test results, notifying the developers and returning the code (with a copy of the test results) if it is not up to scratch. Otherwise, note any new minor problems as a new user stories in your project management software and carry on this checklist.

Now that you’re certain the update won’t completely kill your site, it’s time to merge it into the production environment. This is done in exactly the same manner as with your test environment, and so should pose little to no problems at this stage.

In the final step before you set the update to be live, you need to assess whether it is necessary to run any DevOps scripts in order to update your databases. If so, these scripts must be executed now in order to support the code.

Use the sub-checklist below to keep track of the areas you still need to run scripts in.

Usually, this will only be required when there is a significant updated being deployed, however, you must be incredibly thorough when running these. You need to ensure that every one of your databases is updated with the correct scripts.

Although the databases you need to update will vary, the sub-checklist can easily be edited to suit your needs.

The big moment is here, and it’s to set your changes to be live! Push your updates in the production environment onto the live version of the site and rejoice in the gloriously sparkly new updates. Record the date of the live deployment in the form field below.

Consider that, if this is a large update, you may want to schedule and announce some downtime whilst this occurs.

The final step in the software deployment checklist is to check your live server for bugs once the changes have been applied. This should be as thorough as possible, as it is much better for your team to notice a bug and record it than leaving the job to your customers.

If you find a critical bug which cannot be ignored, it may even be worth considering a server roll-back, but (thanks to your previous checks) this should not occur. Instead, any minor bugs which are picked up should be reported as new user stories within your porject management software.

Congratulations on completing the software deployment checklist! Enjoy your new-and-improved product, and don’t forget to keep an eye out for new bugs that are spotted down the line.

Josh Berkus on LWN.net – The Seven Deadly Sins of Software Deployment

Atlassian Documentation – Establishing Staging Server Environments for JIRA

GitHub Developer – Delivering Deployments

GitHub Gist – Deploy Your Site With Git

Brandon Yanofsky – Why You Need To Start Using a Staging Environment

Kyle Young – DevOps 101: Best Practices for Optimizing and Automating Your Infrastructure

Acquia Help Center – Deploying Your Code To Production

Git Workflow

User Story Template

Sprint Planning

Scrum Project Management

Software Testing Tutorial

Software Debugging Process