Engineering release checklists for production, UAT and frontend UI

Three checklists guard what ships. The production checklist covers the service, the UAT checklist covers sign-off with the product team, and the frontend UI checklist covers what the user sees. Run each one before the matching step.

For the general release flow, see the release checklist.

1Production checklist

Related pages: Logging system, Application health checks and status pages.

• Are long-running processes such as email delivery run in background jobs?
• Are there redundant (at least two) web and background processes running?
• Are we using SSL? Never send credentials unencrypted over public network. Always use encryption (such as HTTPS, SSL, etc.).
• Are API requests being made via a separate subdomain (api.example.com)? Even if the same app, this gives us architectural flexibility in the future.
• Are we monitoring performance and uptime?
• Are deploys done manually at a scheduled time when teammates are fresh and available if something goes wrong?
• Do deploys follow a well-documented script?
• A method exists for replicating the state of one environment in another (e.g. copy prod to QA to reproduce an error)
• All repeating release processes have been automated

Variables

• No secrets are stored in version control
• Is config stored in environment variables?
• Are new variables deployed?
• Server environments are up-to-date
• A plan for updating the server environments exists

Back up

• Are we backing up our production database?
• Backups are running
• Restoring from a backup has been tested
• Rolling back a deployment is possible

Logging

• Logging is turned on
• There is a well defined process for accessing and searching through logs
• Logging includes exceptions and stack traces where appropriate
• Are we sending logs to a remote logging service?

Error Tracking

• Are we tracking errors?
• Errors can be mapped to stack traces

2UAT checklist

User Acceptance Testing can be a daunting and frustrating experience. Too often, the exercise becomes an ordeal of tight deadlines, stress, and system issues. While UAT will always be a high-effort activity, good preparation, responsiveness, and follow-up will multiply your chances of success.

The bug loop during UAT keeps QC between the UAT team and developers:

 +--------------------------+     +-------------+  in scope  +-----------+     +-------------+
 | UAT team logs bug        | --> | QC reviews  | ---------> | DEV fixes | --> | QC verifies |
 | with the UAT label       |     +-------------+            +-----------+     +-------------+
 +--------------------------+            |                                            |
            ^                            | out of scope                               |
            |                            v                                            |
            |                  +----------------------+                               |
            |                  | Log as Change Request|                               |
            |                  +----------------------+                               |
            +---------------------- back to the UAT team to confirm <-----------------+

2.1Before UAT

• All features are completed by the development team.
• All features are fully tested by (internal) QC.
• All features are fully deployed to staging or UAT environment.
• UAT Plan (Schedule, Role, Communication method,...) should be agreed upon between the Product and Development team

2.2During UAT

• All the bugs need to be logged and tag with UAT labels.
• All the bugs logged by UAT team should be assigned to QC team to review before passing them to DEV.
• After DEV team have fixed the bugs it should be assigned back to QC to verify before going to UAT team.
• If the bugs found are not covered by Test Cases of QC team, a new Test Case should be added to the Test Case set.
• If the bugs found are not in the scope of the original requirements, it should be logged as Change Request.

2.3After UAT

• All non-cosmetic defects should be fixed
• Outstanding defects that are not fixed should be communicated to the UAT team and got their approval
• All parties need to Sign-off UAT officially via Email/Paper or Jira log...
• UAT test report should be conducted by UAT/QC team and sent out to all parties

3Frontend UI checklist

Frontend engineering is not just about producing high quality code but also attentive design. Whether you work on a design or transform a design to code, make sure the below checklist is done before you ship.

• Is relative spacing to UI elements as base unit of 4?
• Does your relative spacing match the relative spacing of similar UI elements?
• Does it look good on desktop, tablet, and mobile?
• Are you using existing elements / components where appropriate?
• Are you using the right colors from the design system?
• What happens to text when it gets too long? (e.g. truncation, wrapping, etc)
• Are all interactive states accounted for? (e.g. default, touch, hover, disabled, etc)
• Are empty states accounted for?
• Are error states accounted for?
• Are loading states accounted for?
• Are we using correct writing styles to communicate?
• Are existing patterns being used for similar actions/items? (e.g. text link vs. secondary button, back arrow vs. back link, tooltip vs. exposed helper copy)
• Does your icon choice communicate effectively?

3.1State matrix

For every component that shows data, confirm each state has a design and has been seen in the browser:

3.2Read on

• Tech ecosystem
• Code style
• Writting test
• Logging and monitoring