Deployment (especially deploying for clients and employers) can be an extremely stressful moment. We tend to go over our QA checklists in our minds, anxiously await our team leads code review, and wait for the final merge.
Things tend to go sideways when strict process and policy is not in place to guide the deployment. The simple act of following a mandated process allows your entire team visibility into each and every deployment and allows for easier post mortem should a deployment not go as planned.
In this quick-hit article, we will outline a step-by-step process (with some optional steps) that you can take with you and try to tailor it to your team’s own deployments.
If you already have a process in place, it’s also a great idea to have a wiki of sorts for your entire team to view.
Before we jump in here, I need to let you know that at FlowPress, we use Git for version control and GitHub for repositories. On top of this, we also use a Build server. In the past we’ve used everything from Jenkins to Travis but are currently mostly using Circle CI.
For the uninitiated, Git is a version control system that primarily allows you to control access and manage multiple repositories. A build server or CI/CD system (continuous integration/continuous delivery) allows developers to work collaboratively and commit to a master branch. This keeps things squeaky clean and makes tracking changes and issues much more manageable. The below checklist places importance on these tools and we highly recommend you have/keep them in your arsenal.
Anyways, without further adieu, let’s check out an example checklist!
Step 1: What are you even deploying?
Gather the code that you are deploying or merging. Whenever you make a change to a particular page, you do not need to redeploy all pages on a site right? So collect the specific code changes you are going to deploy before doing anything else.
Step 2: Keeping copies.
Make sure you keep a copy of not only the new code you are going to deploy, but also maintain a clean copy of the current production site. This includes running a backup of production. Please, please, please, never deploy without running a backup of your production site.
Step 3: Administration station
It is always beneficial to your team, your managers, your clients…everyone really, to keep accurate deployment note. Most people call these “release notes”. Note down the current version of WordPress you are deploying to as well as the specific goal of the code being released. If the code being deployed is related to a task in your project management software, you should definitely link to it here. If you use Jira, you can make release notes directly within the app, you can make them in GitHub directly if you choose, or you can use any number of free and publically available GitHub and PM extensions in order to do so. Just make sure you do so.
Step 4: Staging makes the difference
You want to be able to thoroughly test your changes before going live, right? You know the code looks good and works locally but you want to see that the actual site isn’t affected by this deployment, right? Well, then, you need staging.
We won’t get into the benefits of a staging site here as we’ve discussed it in other articles but it is absolutely a requirement to have an up to date staging site. If you are unaware, a staging site is an exact replica of your website that lives on the web and is accessible by a unique URL and is hidden from search engines. Only your team should know how to find and access your staging site.
You can create a staging site with one-click if you have a managed WordPress hosting provider (most offer this feature), via cPanel or Plesk, or manually. wpbeginner did a great piece on this a while ago that you should check out if you don’t have a staging environment.
Make sure that you keep staging up to date as an exact mirror of your live site. If you are unsure whether or not you have an exact replica on staging, make sure you copy over production to staging before deploying code to your staging site.
If you’re using the tools we recommended at the beginning of this article, you can deploy to staging by merging the repo branch containing your recent changes to your test environment. You may need to set an upgrade time for your deployment (if your version control software calls for it), set it to “Now” or “Immediately”.
Step 5: Test, test, test, then test some more!
With your Staging site up and running smoothly, deploy your code changes to staging. Then thoroughly test your site. Click through as much as you can. If you have an especially large site or just want to make sure you don’t miss any small changes, you can use a tool like Ghost Inspector to make visual regression tests. These tests will let you know if anything that you deploy causes visual changes to your site (wanted and unwanted). It’s just important that you make sure to keep the tests accurate and up to date.
If you’re a more advanced developer or team, you’ll have unit tests and integration tests galore anyways…right?
Step 6: Deploy!
Now that we know that your site and business won’t explode when you deploy, you can go ahead and deploy or more accurately, merge into production. Do this by following the same steps we mentioned in the Staging section of this article.
If you have DevOps scripts or a software stack that you use for testing purposes, immediately after this step is the best time to go ahead and run those.
Step 7: Live and let live!
Now that your master/production branch has your most recent code changes deployed to it, it’s time to set it to the live version of your website. There should be no surprises here as we’ve already done this a couple of times before 😉
Step 8: Test then rest!
It’s time for a final run of testing. If you have testing tools, don’t simply wait for them to run on their schedule. Force another run of all of your tests and keep an active eye on them.
It’d be next to impossible to create an all-encompassing in-depth list that would be suited to everyone, but the list above provides a baseline that you can take with you, make your own, and build a process around.
Remember, the larger the requirement list, the more your team will skip steps. It’s important to create deployment processes that developers can work within with their own styles while also ensuring they hit certain milestones along the way.
And that’s all for now. Happy deploying!
