Update the internals docs to include more details about the configuration files needed
This commit is contained in:
R. Tyler Croy
parent
ec8b4bfe0f
commit
1731c576ee
|
|
@ -7,6 +7,9 @@ components within the conceptual "DeployDB box."
|
|||
|
||||
== Web hooks
|
||||
|
||||
"Web hooks" in this section technically covers "web hooks" but also public APIs
|
||||
that other services like Jenkins might use to trigger changes in the DeployDB
|
||||
system.
|
||||
|
||||
== Events
|
||||
|
||||
|
|
@ -15,16 +18,69 @@ components within the conceptual "DeployDB box."
|
|||
Outgoing events
|
||||
|
||||
* Artifact is ready/available
|
||||
* Deploy completed
|
||||
* Verification of a deployment completed
|
||||
* Deploy completed with success/failure indicated in the payload
|
||||
* Status change of a Deployment (e.g. a promotion criteria was met)
|
||||
|
||||
=== Triggers
|
||||
|
||||
Inbound events, there's a large symmetry between <<Notifications>> and Triggers.
|
||||
|
||||
* Artifact of a new version is available
|
||||
* Deployment has completed
|
||||
* Verficiation completed
|
||||
* Create a Deployment
|
||||
* Change status on a known Deployment
|
||||
|
||||
|
||||
=== Configuring Webhooks
|
||||
|
||||
[source,yaml]
|
||||
.webhooks.yml
|
||||
----
|
||||
artifact:
|
||||
- created:
|
||||
deployment:
|
||||
- created:
|
||||
- http://jenkins.example.com/job/notify-deploy-created/build
|
||||
- completed:
|
||||
- http://jenkins.example.com/job/notify-deploy-completed/build
|
||||
promotion:
|
||||
- completed:
|
||||
----
|
||||
|
||||
|
||||
=== Web hook payloads
|
||||
|
||||
|
||||
[source,json]
|
||||
.Artifact created
|
||||
----
|
||||
{
|
||||
}
|
||||
----
|
||||
|
||||
|
||||
[source,json]
|
||||
.Deployment created
|
||||
----
|
||||
{
|
||||
}
|
||||
----
|
||||
|
||||
|
||||
[source,json]
|
||||
.Deployment completed
|
||||
----
|
||||
{
|
||||
}
|
||||
----
|
||||
|
||||
|
||||
[source,json]
|
||||
.Promotion completed
|
||||
----
|
||||
{
|
||||
}
|
||||
----
|
||||
|
||||
|
||||
|
||||
== Queueing
|
||||
|
|
@ -47,7 +103,7 @@ information into a database. This should be abstracted through a JDBC connector.
|
|||
|
||||
|
||||
|
||||
== Environments/Pipelines
|
||||
== Environments/Pipelines/Promotions
|
||||
|
||||
Current thinking: if pipelines are defined in "configuration" as are
|
||||
"environments" then the actual registration of an artifact probably shouldn't
|
||||
|
|
@ -56,6 +112,8 @@ 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
|
||||
|
||||
[source,yaml]
|
||||
.pipelines/devtoprod.yml
|
||||
----
|
||||
|
|
@ -63,32 +121,48 @@ environments:
|
|||
- dev-alpha
|
||||
- dev-beta
|
||||
- integ
|
||||
- preprod
|
||||
- preprod:
|
||||
promotions:
|
||||
- prod-preflight
|
||||
- manual
|
||||
- prod
|
||||
----
|
||||
|
||||
|
||||
The Pipeline concept allows for the configuring of a linear set of Environments
|
||||
for Artifacts to be passed through. At each step of the way the Promotions
|
||||
defined for a given Service traversing the pipeline will need to be
|
||||
validated. E.g. the "FoaS" Service much execute its Promotions between
|
||||
`integ` and `preprod`, but before going from `preprod` to `prod` the
|
||||
`prod-preflight` and a `manual` Promotion must be satisfied.
|
||||
|
||||
|
||||
=== Services
|
||||
|
||||
[source,yaml]
|
||||
.services/foas.yml
|
||||
----
|
||||
|
||||
name: "Fun as a Service"
|
||||
artifacts:
|
||||
- foas
|
||||
- puppet-foas
|
||||
- puppet-mysql
|
||||
- com.github.lookout:foas
|
||||
- com.github.lookout.puppet:puppet-foas
|
||||
- com.github.lookout:puppet-mysql
|
||||
pipelines:
|
||||
- devtoprod
|
||||
promotions:
|
||||
- manual
|
||||
- jenkins-smoke
|
||||
- status-check
|
||||
- jenkins-smoke
|
||||
----
|
||||
|
||||
|
||||
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.
|
||||
NOTE: The "artifact" declarations in the configuration file are using the
|
||||
`groupname:artifactname` syntax which ensure that we can uniquely identify an
|
||||
krtifact. It is expected that all artifacts have at least a unique
|
||||
`groupname:artifactname` for storage in the data store.
|
||||
|
||||
=== Promotions
|
||||
|
||||
|
||||
[source,yaml]
|
||||
.promotions/jenkins-smoke.yml
|
||||
|
|
@ -104,6 +178,10 @@ jobs:
|
|||
`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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
[source,yaml]
|
||||
.promotions/status-check.yml
|
||||
|
|
@ -118,3 +196,7 @@ 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.
|
||||
|
||||
|
||||
`A *manual* promotion is a special case scenario where the UI for DeployDB is
|
||||
going to need to present a button to a user to click
|
||||
|
|
|
|||
Loading…
Reference in New Issue