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.:
-
Redis (e.g. ElastiCache)
-
Kafka
-
etc
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
environments:
- dev-alpha
- dev-beta
- integ
- preprod
- prod
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. |
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.
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.