Skip to content

Instantly share code, notes, and snippets.

@aabs

aabs/cloud-deployment-pipeline-requirements.md

Last active September 12, 2018 14:11
Show Gist options
  • Save aabs/836e0162f76aced8fadda8be2e7f726f to your computer and use it in GitHub Desktop.
Save aabs/836e0162f76aced8fadda8be2e7f726f to your computer and use it in GitHub Desktop.
Download ZIP
A checklist of capabilities that a useful cloud migration model would exhibit
Raw
cloud-deployment-pipeline-requirements.md

Creating a useful cloud migration model

This is a transformation of Adrian Colyer's Checklist to turn it into a working model for a cloud transformation. The assumption is that the original checklist can suffice for any services that are deployed on the build pipeline, but the question to answer here is about how the environment is provisioned, deployed, monitored and governed in such a way as to fit the architecture implicit in the service checklist.

Configuration and Secret Management

  • Config is supplied via environment variables.
  • Anything that doesn't vary between deploys should not be externalised.
  • Deployment orchestrator should supply config as it deploys a service
  • Secrets should never be supplied as config
  • Desired deployment state should be declaratively described in code in a VCS.
  • Desired state should be constantly checked and applied by a Reconciliation Loop

Dependency Resolution

  • external dependencies should be resolved through a discovery platform
  • Never use IP addresses, always use DNS

Operational Practices

  • Production environments should be constantly chaos tested
  • Production environments should be able to immediately recoiver from the abrupt failure of ANY element of the infrastructure and application.

Infrastructure

  • Infrastructure is specified as code in a VCS
  • Infrastructure for all environments is managed by a build pipeline
  • Service operation should not be interrupted by infrastructure reconfigurations
  • infrastructure specifications should be declarative

Hallmarks of a continuous delivery deployment pipeline

  • Build Pipelines are supplied as code in a VCS
  • Deployments do not destroy or mutate previous versions of a service
  • Same deployment model is used in all environments
  • Fully automatic smoke tests after every deployment in all environments
  • Production deployments pipeline includes:
    • rolling blue/green deployments
    • canary builds
  • Access into all external services is via an intelligent gateway/reverse proxy
  • Deployments during office hours should be preferred
  • build pipeline should allow/prefer(?) triggering the builds of dependent downstream systems (is this compatible with service versioning?????)

build pipeline rolling blue/green deployments

Novel components implied by these requirements

  • Intelligent entrypoint into each service or environment:
    • Reverse proxying
    • A/B testing
    • Production cut-over
    • Throttling
    • Circuit Breaker
    • Failover
    • Feature switch
    • Canary Release
    • Dark Launch

Useful Links

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment