As the hard work of a software development project comes to an end, there is one last hurdle that teams must jump to ensure a successful outcome: deployment. Strategic planning for a seamless transition is vital, but often overlooked. Nothing gets a client or teammate’s attention faster than finding errors in their production environment. Here is an overview of the repeatable five-step deployment procedure we use to bring a project into its final stage.
1. Plan for Deployment During Development
It’s important to track any significant updates made to the application while it’s being developed, including changes made to the database, network, security rights, and the application’s configuration. Establish a tracking process so developers can easily access the information and collaborate on resolving problems and making improvements. I recommend tracking updates directly within the issue in your project management software. For example, in Jira, it’s easy to add a “Deployment Notes” field for this purpose.
Create a build process that automates the creation of deployment-ready packages for different environments. Setting up deployment pipelines help reduce human error.
2. Establish a Deployment Plan Template
We use a template that can be copied and reused for each software deployment. It includes six sections:
- Changeset Details – A list of the changesets to be deployed. If a changeset includes code from multiple developers, confirm with all those involved.
- Communication Plan – A list of stakeholders to notify when a deployment occurs, is interrupted, or performed incorrectly. The plan should also include developers with domain knowledge who can help in case of emergency.
- Deployment Tasks – Changes that need to occur outside of the build, including the essential updates listed in section 1 above.
- Code Deployment Details – Step-by-step instructions on how to deploy the latest build. It should be detailed enough so a new developer can do it if necessary. Be sure to include “gotchas” and other things to look out for.
- Testing Plan – A brief description of what should be tested and by who.
- Lessons Learned – A retrospective on the deployment. Use it to refactor the template to make future releases easier.
3. Prepare Code and Database Changes
Use the build process to create the deployment packages. Create a database script for any schema and data updates. Run it in the staging environment first to ensure there are no errors when it’s run in production. These files can be included in your template or attached to the issue, so they don’t get lost.
4. Deploy Changes
Your deployment will vary depending on your tools and level of automation. Start working your checklist by switching to your latest build and making any database and environmental updates.
5. Test Changes and Notify Client
Test the changes to ensure they are in place. I set up test users and data in production environments to make testing easier. They don’t need to be full regression tests - enough testing should have been done in the staging environment to confirm the functionality is there. Simple smoke tests are enough to make sure the new code is in place, and there are no database or security errors.
After the testing is done, there’s nothing left to do except notifying the stakeholders in your communication plan. If you have additional questions, please 
. We’re here to help.
