Your deployments: who, what, where and when.
Go to file
R Tyler Croy 6414bb98d4
Add a simple Rocket hello world
2019-11-15 19:34:51 -08:00
doc Rename all the asciidoc documents to .adoc and re-create the README 2019-11-15 19:34:50 -08:00
features/api Updated after review comments. 2015-05-07 19:10:48 -04:00
src Add a simple Rocket hello world 2019-11-15 19:34:51 -08:00
.gitignore Add a simple Rocket hello world 2019-11-15 19:34:51 -08:00
.travis.yml Travis can't deal with sudo comand in install. If sudo is there it 2015-04-09 16:38:26 -04:00
Cargo.lock Add a simple Rocket hello world 2019-11-15 19:34:51 -08:00
Cargo.toml Add a simple Rocket hello world 2019-11-15 19:34:51 -08:00
LICENSE.txt Remove the old Groovy version of the application 2019-11-15 13:42:25 -08:00
README.adoc Rename all the asciidoc documents to .adoc and re-create the README 2019-11-15 19:34:50 -08:00

README.adoc

<html lang="en"> <head> </head>

DeployDB

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 can occur is difficult.

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:

  • where a particular version of code has been deployed

  • when that artifact was deployed and why

  • what the verification status is of the artifact

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

  • 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)

Goals/Requirements

  • Provide a single source of truth for:

    • which artifacts have been deployed to which environments

    • the success of a deployment, between the act of deployment and the 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.

  • Integrate with existing orchestration tools to drive deployments to a particular environment

  • Integration points for external tools for:

    • providing verification data around a specific deployment (e.g. "Deployment X was verified by Jenkins job <jobname~ build =5")

    • providing deployment start/finish information for environments

    • providing read access to deployment, artifact and environment information 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 doesnt have to be promoted together

  • Deployment failures should have one of three outcomes:

    • Deploy the last known good Deployment to the environment

    • Hit these webhooks (e.g. pagerduty)

    • Do nothing/record and ignore it

An awful diagram

                                    2) publish
                        +----------+   artifact +----------+
      +---------------> | TravisCI +------------+  Bintray |
      |                 +----+-----+            +-----+----+
      |                      |                        |
      | 1) webhook           |                        |    3) webhook
      |  (run tests)         |                        | (artifact available)
      |                      |                        |
      |                      |                        |
+-----+----+                 |                 +------+------+                +----------+
|  GitHub  |                 +---------------> |  #DeployDB  +--------------> |  Heroku  |
+----------+                                   +-------------+                +----------+
               5) report deploy/verification                4) webhook
                   success                                 (deploy artifact
                                                            to environment)
</html>