Perhaps you don't call it a "go-live cascade" like we do here at Diagram, but I truly hope that prior to a website or app deployment, you create a checklist of tasks that need to be completed prior, during, and immediately following that "hit the button" moment. If not, keep reading and we'll explain all the details.
What's Included in a go-live cascade?
Our internal go-live cascades include a step-by-step breakdown of the deployment process, even going so far as to list expected times when they will occur. The cascade also includes:
- details about the deployment including client, date, time, and credentials for accessing the different environments.
- the names of all persons involved in the deployment from the strategist and project manager to the developers and the QA Engineer.
- a list of all tasks that comprise that particular deployment and the issues that were discovered and logged in our tracking software during quality control checks.
- details on the content that will have to be updated or created anew after the code is pushed to the live environment.
- information about third-party integrations and user accounts that need to be setup.
- QC tasks that need to be completed after the push and who will complete those tasks.
- clean-up steps that need to be taken once the push and QC checks are done.
- our most recent addition, a list of known issues that have been observed by our team and can be shared with the client so they don't report them during the UAT process.
You have to admit, that's a lot of detail to keep straight in your head without having it all spelled out in front of you. Better to play it safe and jot it all down ahead of time.
Why a Go-Live Cascade?
The simple answer was stated immediately above this section... "that's a lot of detail to keep straight in your head without having it all spelled out in front of you."
Think about deployments in which you've been involved. How many tasks were assigned to you? To your QA person? To your devs? To your project manager? How about all the details and steps involved in each one of those tasks? That's a lot of somethings that I'm sure you don't want to be struggling to remember in the heat of the moment, amirite?
We decided that was a little too much for us to remember as well.
As our customer base and the complexity of their projects grew, we realized it would be in the best interests of both us and our clients if our deployment procedures were standardized. With such steps in place, it would be easier for new Diagram team members to catch on to how things are done, no matter to what client and project they might find themselves assigned.
To this end, one of our Project Managers, who had a background in web application development and database administration and had taken part in deployments in a variety of roles, stepped up. She noticed that there were many tasks common to all deployments, regardless of the client or the scope of the project. To make things simple, and to ensure these tasks would never be missed, she committed them to one of our earliest go-live cascades. Now our cascades include items as diverse as incorporating analytics code and applying the proper user credentials, removing test accounts, deleting test content, setting up a sitemap, creating utility and error pages, and establishing robots.txt files, among many others. They're all basic steps, but, being so basic, they can be easily overlooked.
In an attempt to future proof our deployments from these potential oversights, she created our first go-live cascade with assistance from our Senior QA Engineer. Although initially hesitant to have to add another step to the process, other team members involved in deployments quickly adjusted to these cascades even going so far as to help contribute information for their creation. The rest, as they say, is history.
Now we rely on these cascades to guide the entire deployment process for everything from full site launches and CMS version upgrades to implementing multi-departmental content approval workflows and simple styleguide updates.
How Do You Set Up a Cascade?
Honestly, a go-live cascade can be created in something as simple as Microsoft Word or Google Docs. Perhaps your company prefers Evernote or some other note-taking apps that provides a thorough means of sorting and storing finished cascades. The key is to be able to organize everything simply and keep a record of what was done for easy reference later.
Diagram uses Microsoft OneNote 365. Why? It's incredibly organized, cloud-based, and can be shared and updated live (I am not being compensated in any way for this endorsement).
Basically we have a shared environment in OneNote with Section Groups set up for all our clients. Within each client group is a Section where new cascades are created and old ones are stored in perpetuity. This information can be accessed by any of our employees to either see what was done on a past deployment or to drive creation of a new cascade for an upcoming go-live event.
In most cases, when a deployment request is scheduled and approved by our Tech Lead, the QA Engineer involved in the testing will begin developing the go-live cascade.
When a majority of the cascade is fleshed out, a link to the OneNote document will be shared with the rest of the team for them to view and edit as necessary. Having these extra sets of eyes on the document ahead of time is a good idea because it's possible they will remember a step or two that may have been overlooked. As I said earlier, it's not always easy to keep all this information in your head especially when you're working on multiple projects with a variety of clients all at the same time.
Once everyone has provided input and approved the cascade, it is kept in OneNote and then referenced during the deployment.
Also worth noting, our cascades make extensive use of checkboxes, which are a default feature of the OneNote app. Watching as QC items are checked off by our team members leaves me with a huge feeling of accomplishment. Just me? I hope not.
Do You Have Experience With Go-Live Cascades?
If so, tell us about it! How has having a system such as this in place helped your deployment process? Have you found yourself needing to refer to old cascades for whatever reason? Why? I'm also curious what you call these documents.
Leave a comment!
