Request For Comments (RFCs)
  • Request for comments (RFC)
  • RFC 001: Matcher architecture
  • RFC 002: Archival Storage Service
  • RFC 003: Asset Access
  • RFC 004: METS Adapter
  • RFC 005: Reporting Pipeline
  • RFC 006: Reindexer architecture
  • RFC 007: Goobi Upload
  • RFC 008: API Filtering
  • RFC 009: AWS account setup
  • RFC 010: Data model
  • RFC 011: Network Architecture
  • RFC 012: API Architecture
  • RFC 013: Release & Deployment tracking
    • Deployment example
    • Version 1
  • RFC 014: Born digital workflow
  • RFC 015: How we work
    • Code Reviews
    • Shared Libraries
  • RFC 016: Holdings service
  • URL Design
  • Pipeline Tracing
  • Platform Reliability
    • CI/CD
    • Observability
    • Reliability
  • RFC 020: Locations and requesting
  • RFC 021: Data science in the pipeline
  • RFC 022: Logging
    • Logging example
  • RFC 023: Images endpoint
  • RFC 024: Library management
  • RFC 025: Tagging our Terraform resources
  • RFC 026: Relevance reporting service
  • RFC 026: Relation Embedder
  • RFC 027: Pipeline Intermediate Storage
  • RFC 029: Work state modelling
  • Pipeline merging
  • RFC 031: Relation Batcher
  • RFC 032: Calm deletion watcher
  • RFC 033: Api internal model versioning
  • RFC 034: Modelling Locations in the Catalogue API
  • RFC 035: Modelling MARC 856 "web linking entry"
  • RFC 036: Modelling holdings records
  • API faceting principles & expectations
  • Matcher versioning
  • Requesting API design
  • TEI Adapter
  • Tracking changes to the Miro data
  • How do we tell users how to find stuff?
  • Removing deleted records from (re)indexes
  • RFC 044: Tracking Patron Deletions
  • Work relationships in Sierra, part 2
    • Work relationships in Sierra
  • Born Digital in IIIF
  • Transitive hierarchies in Sierra
  • RFC 047: Changing the structure of the Catalogue API index
  • RFC 048: Concepts work plan
  • RFC 049: Changing how aggregations are retrieved by the Catalogue API
  • RFC 050: Design considerations for the concepts API
  • RFC 051: Ingesting Library of Congress concepts
  • RFC: 052: The Concepts Pipeline - phase one
  • RFC 053: Logging in Lambdas
  • RFC 054: Authoritative ids with multiple Canonical ids.
  • RFC 055: Genres as Concepts
  • RFC 055: Content API
    • Content API: articles endpoint
    • Content API: Events endpoint
    • Content API: exhibitions endpoint
    • The future of this endpoint
  • RFC 056: Prismic to Elasticsearch ETL pipeline
  • RFC 57: Relevance testing
    • Examples of rank CLI usage
  • RFC 059: Splitting the catalogue pipeline Terraform
  • RFC 060: Service health-check principles
  • RFC 060: Offsite requesting
    • Sierra locations in the Catalogue API
  • Content-api: next steps
Powered by GitBook
On this page
  • Deployment
  • Continuous deployment
  • Deployment visibility
  • Deployment tool
  • Continuous integration
  1. Platform Reliability

CI/CD

Continuous Integration / Continuous deployment

Deployment

Continuous deployment

When test pass against a build in a CI environment those changes are deployed to production.

We need:

  • To be satisfied that tests in CI ensure that a build is promotable to production.

  • To build on the release tool to ensure the deploy step can actually trigger deployments.

  • To be able to quickly roll-back to a known good code point if a deployment is broken.

  • To connect tests to deployment!

Deployment visibility

We want to be able to see who recently deployed what & when.

We should provide an authenticated web dashboard showing deployments.

We want to know:

  • What was deployed, referencing:

    • The PR that was deployed

    • The tests that have been run against the deployed changes (pre/post deployment)

    • The status of a deployment:

      • e.g. when a change is available but not deployed

  • When was a change deployed

Deployment tool

The release tooling as currently used is too complicated.

We should have a single step deployment tool that takes deploy-able artifact(s) from a build and deploys it to an environment.

> cd my_project
> wellcome_release_tool deploy build123 staging
Congratulations abc123 (PR123, PR345) deployed to staging!
> 

Continuous integration

In order to ensure that developers are able to work quickly and effectively together we should:

  • Reduce build times

  • Reduce test times

  • Provide clear and understandable, well documented build tooling

PreviousPlatform ReliabilityNextObservability

Last updated 10 months ago