DevOps Checklists: A Multiplatform Toolset for Markdown Checklists (Part 3)

Search for a command to run...

No comments yet. Be the first to comment.
The why and how of using DevOps Checklists when not everything is (yet) done as code.
It is easy to think of code as only a computer thing, but in truth, humans have been codifying all kinds of knowledge for centuries. There is one type of human knowledge that is more like computer code than anything else: and that is process executio...
Why Least Privilege Security Engineering Is Frequently Skipped or Done Loosely In a previous life, I was on a team that reviewed the IAM policies specified by developers when they created new Cloud applications or required additional permissions for ...

Obscuring sensitive information like AWS account IDs in screenshots and videos is tedious and error-prone. Even with video editing tools that simplify the process, I still have to repeatedly add and remove blurring boxes as the view changes. You know...

AWS CloudShell joins the ranks of hostless shells for operating in your cloud environment. Cloud shells are a huge help to training and enablement scenarios because they remove the pain of fussy configuration of a user-owned endpoint - which can have...

There are always those who feel checklists are an unnecessary waste of time because they think they can always remember the basics of the steps involved to complete a task. Many are also not aware of the huge, cross-discipline benefits that can come ...

On this page
This article is the third and final of a series. Part 1 justified that human-performed DevOps checklists are essentially source code, and according to GitOps principles, belong in Git just like any other code required for successfully managing a software stack. Part 2 dug into the rich but often overlooked, support for interactive checklists on GitHub and GitLab. In this article, we dive into the why and how of using rich desktop editing tools for checklist creation and completion.
“Dual-pain” is not misspelled here — while developers may consider a live rendering window an upgrade to coding in raw markdown, it is very cumbersome for those who do not have a developer role, but need to author Template Checklists or complete Tracking Checklists.
The interactivity of checklists on GitHub and GitLab should generally be used for Tracking Checklists as they facilitate collaboration through immediate, shared updates and do not require Git commits or merges during real-time operational events.
There may be times when visual, desktop-based utilities offer advantages over this model, such as:
Combining Typora and CopyQ expands checklist execution and authoring options. CopyQ allows the insertion of standardized markdown snippets using hotkeys and Typora can directly receive markdown and immediately renders it. This allows adding the following additional completion marking capabilities:
In the past I have had my favorite code editor (VS Code) loaded up with many markdown extensions — each one completed different parts of the puzzle and did it in different ways. Sometimes they conflicted or even prevented editing the markdown by no longer recognizing specific keystrokes. I have removed those plugins and instead run a plugin that simply opens a file type in my operating system’s default application for markdown files and configure Typora to handle markdown extensions in the operating system.
The elimination of cognitive load during a stressful activity, such as managing IT changes, is also a huge benefit. No matter how sharp you are, humans have limits as to how many things they can juggle in any situation — but the sheer risk of production changes saps even some of that capability away because we are being extra vigilant to ensure everything is done just as planned. Under these conditions, getting some markdown code wrong or having to keep recalling the need to properly format can be very distracting.
A primary way around this dilemma is to prepare a copy of a template checklist in advance of the change event to the degree that it is possible. Filling in versions, titles, change dates can usually be done a few days ahead of time. Typora can be used for this by simply copying the body portion of an Issue or Merge/Pull Request in, and when done, pasting it over the body content when done editing.
If your checklist execution procedures require the insertion of screen captures, log data or inserting names and dates and versions — then editing the markdown will be required and this is where Typora will shine by making it nearly as easy as using Google Docs or your favorite word processor. Using Typora for execution does not allow easy real-time collaboration — so there is a potential trade-off if the checklist is used collaboratively.
Across my professional and personal projects, I use all of Windows 10, Mac OS (Catalina) and LinuxMint for editing code and markdown. I use Visual Studio Code on all of them as my primary text editor. These operating systems are also common across DevOps teams — many times the same team will have at least two of these.
Typora and CopyQ both run on all three OSes as well and provide a consistent user experience on all platforms.
Paid for checklist SaaS solutions can represent a lot of adoption friction for team tooling — not just because of cost, but due to:
Typora is $15 lifetime for 3 devices and CopyQ are free and there are no other elements to the solution that carries a cost. The package manager for your OS may have the last free version of Typora (0.11.18) available - but I have to say that at $15 Typora pays for itself in many times over. For instance, without Typora I don't bother doing markdown tables at all and with it, they are a breeze.
If you have team members or teams who do not like Typora, CopyQ can provide value by itself in that a standardized set of Markdown insertions can be defined and shared via a CopyQ configuration text file in Git. This can allow the establishment of some conventions for authoring and executing checks regardless of the editor in use.
Time-date stamps on “done marking” may be desirable or required by your checklist execution methodology. Some checklists may be multiday or long-running — even if completed at one time. Time-date stamps add value by creating a historical time record of completion time and elapsed time — which allows for predicting ops events duration and event correlation if there are problems with a change.
As mentioned earlier, GitLab’s markdown interactivity does provide these stamps in the discussion log — however, if you ever had to audit a checkbox for completion or timing — you must review the entire log for all toggles of the checkbox in question to get the information. In addition, if you have checkboxes that have the same text repeated, it will be difficult to sort out which ones are being manipulated in the audit log.
The premade stamps provided here all have CSS colors — but also use standard markdown bold so that they stand out reasonably well with or without CSS rendering.

The following instructions have been tested on Windows 10, OSX and Linux (LinuxMint 19.x).
Installation on Windows (Chocolatey)

Installation on Mac (Brew)

Typora is only tested on Ubuntu.
Here are the Linux installation instructions: http://support.typora.io/Typora-on-Linux/
CopyQ in public package repos is published as “CopyQ”: https://copyq.readthedocs.io/en/latest/installation.html
These settings are optional, but helpful for the concept of Markdown Checklists. Access these settings from File => Preference:
**Images Insert** => “Copy image to current folder (./)”
**Save & Recover** => “Auto Save”
**Privacy** => “Send Anonymous Usage Info”
Configure CopyQ with TODO, DONE, SKIPPED and RECORD HERE Stamps
The following snippets give you a minimum to start with and also serve as examples to customize for your own work. Using the technique of distributing your own command ini allows you to standardize across your team.
While we are pairing CopyQ with Typora, it works fine with any Markdown editor.
Import this CopyQ settings import file: https://gitlab.com/darwinjs-ideas/GitOpsforHumanProcessedChecklists/-/blob/master/copyq-command-import.ini
Here are the hotkeys. They render with background colors in Typora (renders CSS) and without the background color on websites like Github and Gitlab. The bold and square brackets make the stamps recognizable when colors are not rendered.
_REPLACE_WITH_ <whatever was typed in response to the prompt>This article series has set out to communicate some foundational ideas about managing DevOps procedures in a GitOps world.
First, we established that the “human code” we find in our DevOps solutions is just as critical as computer code and therefore belongs in git.
We went on to claim that “human code” can be recognized because it takes the form of checklists, which reassemble computer code in that they are exacting, ordered and sometimes conditional instructions for accomplishing the desired outcome.
We touched on the evidence-backed claims in the highly recommended book “The Checklist Manifesto” that the helpfulness and necessity of checklists positively affect all individuals and teams no matter how smart they might be.
The templating and interactive checkbox features of GitHub and GitLab were highlighted as critical enablers for integrating of checklists into GitOps software change-management workflows and serve as working example repositories on both were also provided.
Finally, we discussed some rich multiplatform desktop tools to help with ease of editing and standardization of Template Checklist creation and Tracking Checklist completion. Working code examples for configuring CopyQ were also provided.
It is my hope that this three-part deep dive will help you, your team and your organization to experience the massive quality improvements that the simple concept of collaborative checklists has to offer.
“GitOps for Human Processed Checklists (Part 1)”
“GitOps for Human-Processed Code (Part 2): Interactive Markdown Checklists on GitHub and GitLab”
CopyQ command import file for stamps discussed in this article.