How to Make a Go-Live or Release Checklist

I have talked about good processes before and one of the best processes you can have are checklists for important steps. No step is more important than taking your code live.

The purpose of a Go-Live checklist is to make certain that you have covered all your bases, run all your tests, allowed the client to check your work and approve it, make sure there are no regressions, and make sure that you have any special steps documented and ready to be followed. These checklists should be written long before going live. They should be referred to over and over again until you are certain you have worked through it.

At the start of your project, you should create a generic Go-Live checklist specific to regular releases of code to production. Then, for each planned release, a copy of this checklist should be used to create one specific to that release. Then, any additional steps should be added if needed.

I am going to provide several examples of these Go-Live Checklists. First, an example of a small checklist for a simple release. Next, an example of a more complex release. And finally, an example of a list that would be used for the very first launch of a new website or web application.

In the examples below I will use a fictional development agency called “ACME Dev” and a fictional client company called “Big Business”.

Before I dive into the examples of a Go Live/Release Checklist, I will go over what goes into Going Live with a new site and with releases.

What Goes into a Go Live/Release Checklist?

These checklists are meant to perform a high-level coverage of pre-launch and launch-day activities. They help us and guide us so that when we are busy or stressed we have one less thing to focus on and organize in our minds. It provides us with simple clear steps to ensure the launch/release goes as well as possible.

Code Complete

First, the checklist needs to make sure all the stories or tasks are completed from a code standpoint. When launching, we call this “code complete”. When releasing you can call it that or just “feature complete”. This ensures that we have gone over all the planned work before having the final tests and checks run on the website. If you need more information on writing stories, checkout my previous article here.

UAT Testing

Next, there are the UAT tasks. UAT, or User Acceptance Testing, is a step where we ask the client or product owner to review the site to make sure they are happy with the state it is in. This does two things, it builds confidence in the upcoming launch/release, and it has the client invest themselves more in the project with their approval.

QA Testing

With QA testing, we have a dedicated Quality Assurance tester going through their standard tasks and any specialized tests specific to the project. As a developer, you shouldn’t be expected to be the only one testing the results as you are too close to the code and can easily miss things. Especially if you are rushed. QA’s job is to provide independent verification. It should be done along the way prior to the release steps, however, there should be a larger check done right before as well.

Tested on Stage

When planning a release, we should always test on a staging environment that is as close to production as possible. This includes having a fresh copy of the production database on the environment and the environment having all the basic features (search indexes, databases, file storage, web server, PHP version, etc) that the production environment has. Even if they don’t have the same level of performance, storage, and memory as production. This helps catch differences between local/dev environments and production.

With most of my projects, we have the local environment on each developer’s machine (usually run from a Docker container), a Dev or Development environment that is more similar to stage and prod where we can test experimental new features, a Staging environment where final testing takes place, and finally, the production environment where the site or application lives.

Content Complete

Being content complete is critical to a new site or rebuilt site launch. This ensures that we have all landing and marketing pages in place with carefully considered content. Fixes any broken links. Ensures product pages are built to satisfaction. And really just makes sure that the site will have the fullest positive impact on launch day. Both with site visitors and with search engines.

Load Testing

In load testing, we are using tools to simulate a large spike in traffic on the servers. This tells us whether or not the site can handle a sudden influx. With proper caching tools such as using a CDN, Varnish Caching, Server Caching, and even intermediate tools such as those offered by CloudFlare, you can often avoid any problems with traffic spikes.

Performance Testing

With performance testing, we are checking to make sure that the site loads and renders within an acceptable timeframe. You will always want to get this as low as possible. Preferably having the site loaded and rendered in less than 1 second. However, to avoid search engine hits it should take no longer than 3 seconds. With modern tools, this is very achievable.

There are a number of tools on the market including Google Lighthouse (which covers a lot more than performance), PageSpeed Insights, GTMetrics, and much much more. There are a ton of factors that can affect performance. I will write an article on this in the future. Testing should be for both desktop and mobile, but especially mobile as those users are the most likely to experience issues, and more and more people are using their phones to navigate the web. Be ready for them.

Security/Penetration Testing

Security is critical for your website. Especially if you are selling things or taking in user information through forms. Keeping information, especially PII (Personally Identifiable Information), safe is critical to long-term business success. There are a number of tools out there for this, including tools specific to your platform such as WordPress, Drupal, or AEM (Adobe Experience Manager).

For capturing data, and maintaining compliance with CCPA (California Consumer Privacy Act) and GDPR (General Data Protection Regulation, a European law), it is recommended that you do not store any personal information on your website itself for users. Instead, offload the storage and security of that to a tool such as Shopify or MailChimp. This will protect you in the case of a breach and lower your liabilities.

Accessibility Testing

Accessibility is far more important than many people realize. It also covers a number of different impairments that people may have. Everything from limited vision to color blindness to full blindness. Other impairments can include auditory, cognitive, neurological, physical, and speech.

It is important not just to your users, but to your business as it can open you up to unexpected liabilities. A few years ago, the pizza chain Domino’s was sued by a blind man because their website made it impossible for him to order a pizza, effectively denying him access and violating his rights under the ADA (Americans with Disabilities Act). They lost that lawsuit and are now required to make their website accessible by law. Don’t leave yourself open to such lawsuits.

There are a number of tools you can use to help you with this. Some cover more than just accessibility, such as Google Lighthouse.

Implement 301 Redirects

301 redirects are a tool used to both guide users to the appropriate new pages and help guide search engines to where content has moved permanently to. This is most often used in site rebuilds where paths and architecture change. It is also used when migrating from one domain name to another.

Code Freeze

This is the point where the code should not change at all. If it needs to change then the launch needs to be rescheduled.

Content Freeze

This is more of a CYA so that there is no data loss during launch and a point where the client can set a goal to be done with all content changes needed for launch.

DNS TTL Reduction

We ask that the client’s IT reduce the TTL (Time To Live) for their DNS settings to about 5 minutes. We do this a few days before launch so that when we direct the domain at the new servers the DNS changes propagate as fast as possible. In my experience, if the site is setup on CloudFlare for DNS, the change will propagate in seconds, not minutes. Thus, I recommend using them or a service like them.

SSL Certificate

Search engines will demerit you for not having SSL setup on your website. Even on a simple blog these days. This is because SSL secures website transactions with the user and will help protect the user’s data in transit. And this is required, in part, because you can easily get free certificates on most hosts using the Let’s Encrypt tool.

HTTPS Redirect

This ensures all connections have been secured.

Smoke Test

Smoke testing is a general click-through review of a site to check for any obvious problems or breakage. It is not in-depth and cannot replace full QA testing.

Go/No Go

The Go/No Go call is just like it sounds. It is the final decision of the client or product owner on whether or not to go through with the launch. This is a critical buy-in that should not be skipped.

Flip DNS (to go live)

In this step, we are making the site live to the public. We have the client’s IT or DevOps people change the domain DNS to point to the new web server so that everyone can see your work.

Record Tag and Announce

A habit I have gotten into that is very helpful and effective is to record the current branch/tag that is deployed on production before doing so. In this step, I create a post in the Microsoft Teams channel for the given project. In that post, I title it with the current date and state that it is a code deployment. Then in the body, I list the database backup status (is it done or is it running), the currently deployed production build branch/tag, and the build branch/tag that I will be deploying.

I may also include special details or steps that are particular to this release. It is also a good idea to list all the changes that will be deployed as a record. Finally, I will also comment when each deployment step is completed.

I do this for multiple reasons. To keep track of changes and when they are launched. To inform the team about releases. And to help guide a rollback if needed. You don’t want to forget which tag was on production before deploying. That would make a rollback much harder and more stressful.

I also recommend emailing the client at the beginning and end of the deployment as well as recording in your documentation (such as in Confluence) the release details.

Clear CMS Cache

Content management systems use their own form of caching and it is important to clear it after a launch to ensure that everything served to the user is fresh and up to date.

Clear Varnish Cache

Varnish caching is at the server level and performs a similar function to the CMS cache. It can reduce traffic to the application itself which means faster response times for the user and reduced server load.

Re-Index Search

Your site search should be re-indexed after (or right before) launch to ensure the content is up to date in the search results. We use Apache Solr for our search index and it is important to make sure it is fresh. Though there should be processes in place to keep the index updated regularly.

Post-Launch Smoke Test

This is just like the regular smoke test, only done after launch. We are being thorough here and this is a highly-recommended step to take.

Submit Site Map

Don’t forget to submit your latest site map to Google and other search engines. This helps generate traffic to your website.

Simple Release

In this, we are performing a regular everyday release. There is nothing special going on here. The process should be straightforward and repeatable.

Pre-Release

Release Day

Complex Release

In this release, I am basing this off of an upgrade of a Drupal site that had gone a long time without core Drupal updates. Between the old version and the newest version of Drupal and many of the modules it became required to be on at least PHP 8.0 if not 8.1. The site was on PHP 7.4 and the existing version didn’t fully support PHP 8.0. Because of this, I had to do the update in two stages.

First, deploy the newer version of Drupal that was fully compatible with PHP 8.0 and 8.1. Then take some intermediate steps to swap out a deprecated admin theme and switch the server to PHP 8.1. And finally, I deployed the newest version of Drupal in the second step to take us all the way there.

Pre-Release

Release Day

Full New Site Release

In this, we are launching a site rebuild for the first time. Because of this, there are many more steps we are taking to ensure a solid successful release.

Pre-Launch

Launch Day

Conclusion

This checklist is meant to be a helpful template and a guide to best practices. Please let me know if you found this useful and have any suggestions for changes. Thanks!