Service Provisioning and Deployment Checklist

Posted on Thursday, May 9, 2019

Application and Service Provisioning and Deployment

Are all of our automated administrative operations restartable? Automated operations such as deployments, failovers and restarts should be as easily restartable as they are startable. If a failure occurs it should be possible to manually restart the process without adverse side effects. This means that prerequisite state should be persisted and external interactions should be idempotent.

Can we support geo-distribution / multi-region deployments?

Delivery pipelines should not be bound to any specific geographical location or region. Catalgoue the services that are required from compute/resource providers and be aware of any regional limitations in those services (e.g. as of May 2019 AWS Fargate is note supported in Paris, Ningxia, Stockholm etc).

Have we automated provisioning and installation?

Database migration tools and container runtimes, provisioning, installation and schema upgrading should be managed by tooling.

Are configuration and code delivered by development in a single unit?

Services that treat configuration and code as a unit and only change them together are often more reliable. If a configuration change must be made in production, ensure that all changes produce an audit log record so it’s clear what was changed, when and by whom, and which servers were effected (see section 2.7). Frequently scan all servers to ensure their current state matches the intended state. This helps catch install and configuration failures, detects server misconfigurations early, and finds non-audited server configuration changes.

Is infrastructure disposable and immutable?

Infrastructure should be defined as code and should easy to deploy via an automated pipeline. Application services should respond to SIGTERM and potentially SIGKILL and should not require any special shutdown procedure. Design so that clean-up operations are as quick as possible or eliminated entirely.

Is the unit created by development used all the way through the lifecycle (test and prod. deployment)? The deployed artifact (executable, JAR or container) should be built once before testing and at each stage of the delivery pipeline. Configuration changes between stages should be minimal (values and not code structure changes).