2019-11-16 03:31:52 +00:00
|
|
|
= DeployDB
|
2014-12-17 20:04:26 +00:00
|
|
|
|
2014-12-17 19:15:48 +00:00
|
|
|
**Who, what, where and when.**
|
|
|
|
|
|
|
|
== The Problem
|
|
|
|
|
|
|
|
As a service-oriented infrastructure grows, testing and managing/driving
|
|
|
|
deployments with the oft used "all together now" approach becomes untenable.
|
|
|
|
|
|
|
|
Tracking versions of application and configuration management code through a
|
|
|
|
consistent pipeline of tiered environments where verification of those changes
|
2015-01-02 22:40:08 +00:00
|
|
|
can occur is difficult.
|
2014-12-17 19:15:48 +00:00
|
|
|
|
2019-11-16 03:31:52 +00:00
|
|
|
=== Internals/Hacking
|
|
|
|
|
|
|
|
* <<doc/hacking.adoc#,Hacking DeployDB>>
|
|
|
|
* <<doc/internals.adoc#,Data model/Internals>>
|
|
|
|
* <<doc/config.adoc#,Configuration>>
|
|
|
|
* <<doc/auth.adoc#,Authentication>>
|
|
|
|
* <<doc/workflow.adoc#,Workflow>>
|
|
|
|
* <<doc/webui.adoc#,Web UI Design/concepts>>
|
|
|
|
|
2014-12-17 19:15:48 +00:00
|
|
|
== The Solution
|
|
|
|
|
|
|
|
DeployDB is a tool to provide a single source of truth for artifact-based
|
|
|
|
deployments through multiple environments. It is intended to fit within an
|
|
|
|
existing infrastructure where CI and deployment orchestration are already
|
|
|
|
provided by other tools (e.g. Jenkins, Rundeck).
|
|
|
|
|
|
|
|
As a user of DeployDB, you should be able to understand exactly:
|
2014-12-18 03:07:35 +00:00
|
|
|
|
|
|
|
* where a particular version of code has been deployed
|
|
|
|
* when that artifact was deployed and why
|
|
|
|
* what the verification status is of the artifact
|
2014-12-17 19:15:48 +00:00
|
|
|
|
|
|
|
|
|
|
|
== Terminology
|
|
|
|
|
|
|
|
* **Artifact**: a singular versioned file which represents an
|
|
|
|
iteration of code to be deployed.
|
|
|
|
* **Deployment**: taking an artifact, or artifacts, and
|
|
|
|
delivering and executing them inside of an environment.
|
|
|
|
* **Environment**: a collection of applications and configurations for executing
|
|
|
|
services together across a cluster of machines.
|
|
|
|
* **Pipeline**: a set of deployments and promotions defining the relationships
|
|
|
|
between each environment
|
|
|
|
* **Promotion**: a set of criteria for determining whether a deployment is
|
|
|
|
suitable to progress to the next environment in the pipeline
|
2014-12-19 04:38:55 +00:00
|
|
|
* **Service**: a collection of artifacts representing a conceptual service
|
|
|
|
provided to customers (e.g. "the authentication service" which might consist
|
|
|
|
of the "auth.war", "puppet-mysql", "puppet-jetty" artifacts)
|
2014-12-17 19:15:48 +00:00
|
|
|
|
|
|
|
== Goals/Requirements
|
|
|
|
|
|
|
|
* Provide a single source of truth for:
|
2014-12-17 20:52:34 +00:00
|
|
|
** which artifacts have been deployed to which environments
|
|
|
|
** the success of a deployment, between the act of deployment and the
|
2014-12-17 19:15:48 +00:00
|
|
|
follow-on validation of the artifacts deployed
|
|
|
|
* Provide a centralized synchronization point for coordinating deployments
|
|
|
|
across environments as defined by a pipeline.
|
|
|
|
* *Not* provide redundant functionality already provided by orchestration
|
|
|
|
tools such as Rundeck or Jenkins.
|
2014-12-17 20:04:26 +00:00
|
|
|
* Integrate with existing orchestration tools to drive deployments to
|
2014-12-17 19:15:48 +00:00
|
|
|
a particular environment
|
|
|
|
* Integration points for external tools for:
|
2014-12-17 20:52:34 +00:00
|
|
|
** providing verification data around a specific deployment (e.g.
|
2014-12-17 19:15:48 +00:00
|
|
|
"Deployment X was verified by Jenkins job <jobname~ build =5")
|
2014-12-17 20:52:34 +00:00
|
|
|
** providing deployment start/finish information for environments
|
|
|
|
** providing read access to deployment, artifact and environment information
|
2014-12-17 19:15:48 +00:00
|
|
|
contained with DeployDB
|
|
|
|
* Integration points should be exposed via a command line, Ops-friendly,
|
|
|
|
interface
|
|
|
|
* Configuration should not live in the data store and be easily driven by
|
|
|
|
configuration management tools (e.g. Chef, Puppet)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
== Use-cases/questions
|
|
|
|
|
|
|
|
* How do we set up a new application/service in DeployDB?
|
|
|
|
* How does promotion of one application through an environment work so that
|
|
|
|
the entire environment doesn't have to be promoted together
|
|
|
|
* Deployment failures should have one of three outcomes:
|
2014-12-17 21:01:03 +00:00
|
|
|
** Deploy the last known good Deployment to the environment
|
|
|
|
** Hit these webhooks (e.g. pagerduty)
|
|
|
|
** Do nothing/record and ignore it
|
2014-12-17 19:15:48 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
== An awful diagram
|
|
|
|
|
|
|
|
2) publish
|
|
|
|
+----------+ artifact +----------+
|
|
|
|
+---------------> | TravisCI +------------+ Bintray |
|
|
|
|
| +----+-----+ +-----+----+
|
|
|
|
| | |
|
|
|
|
| 1) webhook | | 3) webhook
|
|
|
|
| (run tests) | | (artifact available)
|
|
|
|
| | |
|
|
|
|
| | |
|
|
|
|
+-----+----+ | +------+------+ +----------+
|
2014-12-17 20:04:26 +00:00
|
|
|
| GitHub | +---------------> | #DeployDB +--------------> | Heroku |
|
2014-12-17 19:15:48 +00:00
|
|
|
+----------+ +-------------+ +----------+
|
|
|
|
5) report deploy/verification 4) webhook
|
|
|
|
success (deploy artifact
|
|
|
|
to environment)
|