- Maintaining Environments
- Simplifying CI/CD
- Creating a pipeline
- Advanced Pipelines
A pipeline is a group of apps that share the same codebase. Each app in a pipeline represents one of the following steps in a continuous delivery workflow:
A common Akkeris continuous delivery workflow has the following steps:
- A branch is created in a repository and pull request is made.
- Akkeris creates apreview app for the pull request, allowing developers to review the change.
- When the change is ready, it’s merged.
- The master or central branch automatically deploys to the apps in the development stage.
- When it’s ready, the application is promoted to staging apps, and then production.
Regardless if you maintain an environment thats named differently than the pipeline stages, Akkeris can still help with CI/CD tasks and managing environments. Any set of applications (one or more) can be placed into any stage, and during a promotion the image from the previous stage is pushed to all apps downstream.
If for example you have a
prod environment, you can seperately add your
dev app to the
development environment and the
stage apps to the
staging pipeline step. When the
dev app is promoted its bit-by-bit image (seperate from its configuration or resources) is moved forward to both the
stage apps as they are both in the
Once you’ve defined a pipeline, you and your team no longer have to worry about building and releasing outside of the apps in your
development environment. Instead,
aka pipelines:promote will copy your app’s build artifact (i.e. slug) to the downstream app(s) as a new release. In addition pipelines allow for additional functionality such as preview apps and automated CI/CD.
In addition the pipeline workflow tool can be quite useful when managing multiple region deploys. Consider if you had tweleve different regions your production app may run in. All twelve apps can be simultaneously deployed to with a promotion of a
stage app to
prod by adding all twelve apps to the
Creating a pipeline
For example say we have
myapp-space-qa we could create a new pipeline using:
$ aka pipelines:create myapp
Adding apps to a pipeline
Then we can add both apps to the pipeline
aka pipelines:add myapp -a myapp-space-dev -s development app id=d3dd5715-66a8-435b-b5a5-2252a56b6c8e, name=myapp-space-dev id c21b5e30-ef20-4685-b472-4c59fcce086e created_at 2017-05-16T18:52:03.467Z updated_at 2017-05-16T18:52:03.467Z stage development pipeline id=13a3e3c3-a375-4623-bc6c-2a1405910733, name=myapp
aka pipelines:add myapp -a myapp-space-qa -s staging app id=d3dd5715-66a8-435b-b5a5-2252a56b6c8e, name=myapp-space-qa id c21b5e30-ef20-4685-b472-4c59fcce086e created_at 2017-05-16T18:52:03.467Z updated_at 2017-05-16T18:52:03.467Z stage development pipeline id=13a3e3c3-a375-4623-bc6c-2a1405910733, name=myapp
aka pipelines:add myapp -a myapp-space-stg -s staging app id=d3dd5715-66a8-435b-b5a5-2252a56b6c83, name=myapp-space-stg id c21b5e30-ef20-4685-b472-4c59fcce0863 created_at 2017-05-16T18:52:03.467Z updated_at 2017-05-16T18:52:03.467Z stage development pipeline id=13a3e3c3-a375-4623-bc6c-2a1405910733, name=myapp
Promoting an app
Now that we have both apps in our pipeline we can promote the code on myapp-space-dev to myapp-space-qa and myapp-space-stg.
aka pipelines:promote -a myapp-space-dev Promoting app ⬢ myapp-space-dev ... ✓ = myapp pipeline (development -> staging) Promoted: ⬢ myapp-space-dev (Release: e06899ed-48c3-456e-b2e9-2536e1ae4973) To: ⬢ myapp-space-qa ⬢ myapp-space-stg
We can now see the release on the
myapp-space-qa of the build from
myapp-space-dev, note that
myapp-space-qa retain completely separate config vars and environments (which are not promoted or changed).
aka releases -a myapp-space-qa • v1 (13616620-2cc5-4a61-851b-819c01734dad) - current Build: d4128fa1-ac32-4ae5-ba25-c16dd7415184 Created: 2017-05-16T18:56:45.359Z Status: succeeded Description: Promotion from myapp-space-dev
Multiple apps can be at any one stage in a pipeline, the first app found will be promoted, however when promoting you may specify a specific app to promote and the release id on that app to promote (in addition to explicitly specifying a target app). This allows you to establish more complicated workflows/pipelines.
A simple staging to production pipeline:
myapp-staging ---> myapp
Or, a team’s more complex pipeline:
myapp-jim-dev --- \ ---> myapp-staging ---> myapp / myapp-kim-dev ---
Pipeline Status Checks
Pipeline status checks allow a third party system to report a state of
error about a release through the Platform Apps API. The third party systems check can then be required to be successful before any release is allowed to be promoted to any pipeline stage. A status check can be reported on any release, to create a new status check see the Release Statuses section of the Apps API.
Adding Required Status Checks
Specific stages of a pipeline can require that one or more release statuses on a release are in the
success state to allow the release to be promoted. To add required statuses to a pipeline and stage while adding an app to a pipeline stage run:
aka pipelines:add -a [appname-space] -c my-status-check -c my-other-check -s staging`
Updating Required Status Checks
To update an existing pipeline, use
aka pipelines:info [PIPELINE_NAME] to get the pipeline coupling id to update, then run:
aka pipelines:update PIPELINE_COUPLING_UUID -c my/status-check
Removing Required Status Checks
To remove pipeline status checks, run the update command without any
-c option and all status checks will be removed. Removing status checks does require elevated access privileges.
aka pipelines:update PIPELINE_COUPLING_UUID
Viewing Required Status Checks
To view the pipeline status checks added to couplings, run:
aka pipelines:info PIPELINE_NAME ᱿ staging Id: eda4a600-fa5b-4595-b378-93733a6a231c App: appa-default (f004d613-86a5-413b-86da-405526e098ec) Status Checks: ᱿ staging Id: 8e754b16-c1c5-4861-bf85-f6bbd5180206 App: appb-default (9879a6f8-a7d5-42de-8154-a6cea1824b00) Status Checks: ᱿ production Id: 08f4d458-a492-44c0-9a78-667d8b24644d App: appc-default (60f53f16-e70b-4214-bb50-790b0c7d441c) Status Checks: my-status-check, my-other-check
The name of a status check (e.g.,
my-status-check) is typically referred to as a "context".
To get a list of status checks available for a pipeline, run:
aka pipelines:checks PIPELINE_NAME