Release checklist

This article specifies considerations for releasing a new solution. It does not need to be considered for subsequent deploys where other routines should be in place.

Note: This article is not complete and should be updated continuously.

Prerelease considerations

The following questions should be considered before deployment.

  • Where should the site be hosted?
    • Cloud or on-premises?
    • Do we have appropriate access to the hosting environment?
  • What domain(s) should the site be released on?
    • Do the domains need to be registered?
    • Who handles domain registration?
    • Do we have a contact to the client's DNS provider?
  • How should we setup the HTTPS certificate?
    • Will the client manage their own certificates for the solution?
    • If not, do they purchase manual certificates (e.g. DigiCert, GlobalSign) or can we use automatic solutions?
    • If there is manual handling, a routine for renewal must be set up.
  • What is the disaster recovery plan?
    • Do we regularly back up the database?
    • Do we have a plan for restoring the database?
    • Can we do it on our own, or do we need help from the client?

If the site replaces an existing one: - What is the survival plan for the old solution? - Should the site be archived in some way? - Do we need to set up redirects? (Most commonly, yes).

Useful tools

Checklist

Documentation

Every secret and key must be added to the password manager and nowhere else.

Make sure the project has a README.md file in the repository root. The README should contain:

  • Project name and description.
  • Description of the project's tech stack, architecture and design patterns.
  • Information about any integrations with external systems.
  • Information about environments, and where they are hosted.
  • How to set up and run the project.
  • Non-technical prerequisites for running the project.
  • Any environment variables that need to be set, and where to find them.

Site structure

Verify that...

  • Headings have the correct hierarchy (h1, h2, h3 etc.).
  • The site has a functioning header and footer.
  • Additional navigation works as expected, including breadcrumbs.
  • Site search is working as expected.
  • Pagination, filters and sorting is working as expected.
  • Internal links are working as expected.
  • External links are working as expected.
  • The site has functioning 404 and 500 pages.

General functionality

  • Verify that the site can be browsed on mobile devices.
  • Ensure compatibility with all agreed upon browsers. See typical cases in browser support.
  • Check whether the site can be used without JavaScript, or notifies that JavaScript is required.
  • Verify that the site has a lang attribute on the <html> element.

SEO

  • When replacing an existing site, ensure a redirect map of old to new URLs is in place.
  • Make sure redirects to or from the www subdomain are in place.
  • Ensure that there is a functioning sitemap that is correctly linked via robots.txt.
  • Make sure that pages contains the correct meta tags, e.g.
    • Meta title
    • Meta description
    • Open Graph tags
    • Structured data like JSON-LD
  • Meta properties should be automatically populated from the page content.
  • Users can edit meta property values in the CMS.
  • Users should be able to set a page as noindex in the CMS.
  • If the site uses structured data, ensure its validity.
  • If GTM is present, verify that tags are properly set up and working.

Security

  • No secrets may be stored in source code management. If anything was temporarily checked in during development, secrets must be regenerated.
  • A valid HTTPS redirect must be in place.
  • Cookies should be set as secure.
  • The hosting environment must only accept TLS 1.2 or higher.
  • Make sure HSTS (Strict-Transport-Security) is enabled in production. Take care not to apply includeSubDomains if this would cause problems on other domains managed by the client.
  • If the site includes a login, make sure anonymous users should not have access to restricted resources/pages.
  • Captchas should be in place where necessary.
  • XSRF tokens should be used where necessary.
  • The Permissions-policy header should be served.
  • A CSP should be in place.

Accessibility

  • Make sure the site can be navigated using only the keyboard.
  • Preferably there should be a link to skip to main content.
  • Make sure all images supports alt attributes (texts should be present).

Integrity/privacy

  • A cookie consent solution should be in place.
  • Privacy and cookie policy pages should be set up and linked from the footer and cookie consent banner.
  • Make sure the site is not leaking referrer information.

Performance

  • Check the network tab in the browser console for any unreasonably large resources.
  • Test the response time of the site / endpoints.
  • The production environment should use Brotli compression if possible.
  • WebP images should be used when possible.
  • Make sure images are cropped to the correct size.
  • The site should not be serving images or videos that are too large (e.g. images should not exceed 300 kB).
  • If possible, use viewport-appropriate sized assets like differently scaled images on mobile and desktop.
  • Fonts should be served in woff2 or better.

Error handling

  • Verify that the site has a user friendly 404 and a 500 error page
  • Make sure they respond with the correct HTTP status codes
  • It is a good practice to send errors from API in a standardized format

Standard files

  • Make sure the project has a correct .gitignore file.
  • robots.txt must be present and served correctly.
    • It must be configured to block crawlers in non-production environments.
    • It should refer to the sitemap.
  • If using security.txt, verify its validity.
  • Make sure favicon.ico is present.

Tracking & analytics

  • Make sure that the agreed upon tracking solutions are working correctly.
  • If possible, set up Application Insights
    • Verify that telemetry is received by Application Insights.
    • Make sure that logs are persisted in Azure,

Clean up

  • Make sure no errors or logs are left in the browser console.
  • Check for 404 errors from missing resources in the browser console.
  • Consider setting the log level to WARN in production.

Billing

  • Validate the billing arrangements.
    • Hosting environments.
    • Product licenses.
    • Third party integrations like cookie consent management.

Rollback

  • A rollback plan must be in place.

People

  • Relevant people must have time made available to participate or stand by.

Azure

If using Azure, ensure that resources are named according to the naming conventions.

Umbraco

  • Ensure that uSync content syncing is disabled in production.
  • Models builder should have generation enabled only in development.
    • A good practice is to use the Umbraco.ModelsBuilder.ModelsMode.Nothing mode in appsettings.json and then use Umbraco.ModelsBuilder.ModelsMode.SourceCodeManual in appsettings.Development.json
  • Make sure all health checks are green
  • Set "SixLabors.ImageSharp.Web.Middleware.ImageSharpMiddleware": "Warning" in Serilog.MinimumLevel.Override in appsettings.json to avoid cluttering the logs with "Sending image" messages.
  • If hosting on Azure, verify that the solution follows the Azure-specific recommended settings from Umbraco's documentation.
  • Optionally, ensure that the solution uses Umbraco.CMS.RequestHandler.UserDefinedCharCollection to change default behavior of Umbraco's URL sanitization for language-specific letters (ÅÄÖ etc.).

Post-release checklist

  • Set up Pingdom alerts.
  • Update development and staging environments with content from production.

E-commerce

  • Verify that any product feeds are configured and working, e.g. Google Shopping in Google Merchant Center.

All done

Make sure to celebrate 🍾