This document outlines some of the design internals of DeployDB as an application. This does not include the interactions with other services (e.g. CI, deployment orchestration) but rather the interactions between different components within the conceptual "DeployDB box."

Web hooks

Events

Notifications

Outgoing events

  • Artifact is ready/available

  • Deploy completed

  • Verification of a deployment completed

Triggers

Inbound events, there’s a large symmetry between Notifications and Triggers.

  • Artifact of a new version is available

  • Deployment has completed

  • Verficiation completed

Queueing

Queueing is largely required to ensure the delivery of Notifications and other out-bound web hooks.

The queueing interface from the application should be abstracted enough to allow queueing to be backed by different queue providers, e.g.:

Data storage

The data storage layer is what is responsible for persisting runtime information into a database. This should be abstracted through a JDBC connector.

Environments/Pipelines

Current thinking: if pipelines are defined in "configuration" as are "environments" then the actual registration of an artifact probably shouldn’t be in configuration but rather registered via an API.

It might make sense to have that registration API write some YAML to disk or something and allow DeployDB to register artifacts from the same place on disk

pipelines/devtoprod.yml
environments:
  - dev-alpha
  - dev-beta
  - integ
  - preprod
  - prod
services/foas.yml
name: "Fun as a Service"
artifacts:
  - foas
  - puppet-foas
  - puppet-mysql
pipelines:
  - devtoprod
promotions:
  - manual
  - jenkins-smoke
  - status-check
Note
The "promotion" concepts described below are not final and really just brainstorming to flesh out how configuration of promotions as a concept might work.
promotions/jenkins-smoke.yml
type: JenkinsPromotion
jobs:
  - basic-smokes-test
  - basic-perf-test
  - end2end-smoke-test

JenkinsPromotion as a typed concept would require a list of Jenkins job names that would be required to succeed in order to execute the promotion.

promotions/status-check.yml
type: WebhookPromotion
url: /healhcheck
status: 200
timeout: 15

WebhookPromotion would be something that would make a HTTP GET request to the application and see if it’s online before identifying it as "promoted." How this might work with a cluster of applications in one service, I’m not yet sure.