Promotional Deployment

Akamai Pipeline: Automate the Promotion of Changes Between Different Environments

May 11, 2018 · by Sid Phadkar ·

Promotional Deployment (Update, October 2018: Promotional Deployment is now known as Akamai Pipeline) is a terrific new package for Akamai CLI that enables you to automate the promotion of changes between different environments in your deployment pipeline. This means you can now integrate CDN changes into your deployment pipeline by simply parameterizing a single configuration file to cater to different environments.

As with any other CLI command, you can easily integrate Promotional Deployment into your build automation tools. That would enable you to, for example, automatically promote changes after a series of tests are run and successful. Promotional Deployment is an exciting new addition to Akamai for DevOps, and I highly recommend checking out this video that explains how you can get all the benefits (spoiler alert: I'm the presenter).

So, you’re probably asking, how does this work? A typical automated pipeline consists of lower environments (dev, QA, integration, etc.) where code flows through. As part of the continuous integration cycle, a change is made in the lowest environment (assume dev), then it’s tested out completely there, and then it’s promoted to the next environment (assume QA), and so on.

With Akamai Promotional Deployment, this entire testing-and-promotion process is automated once the code is first checked in via your build-automation tool (e.g., Jenkins, CircleCI, Travis CI, etc.).

And it’s easy to get started. The process consists of two primary elements: 1) a one-time setup to replicate your pipeline, and then 2) a recurring promote command you can use to promote changes between environments.

1) One-time Pipeline Setup

The first step in getting started with Promotional Deployment is to simply install the package. If you are already using the Akamai CLI, simply run:

akamai install promotional-deployment

A create-pipeline command then lets you define different environments and even create them based on an existing configuration if required. Typically this is a one-time setup, but can be repeated as often as required. We have users who use one pipeline for eternity and others who are used to setting up a new release pipeline every month.

Let’s look at a hypothetical use case. Assume I want to define three environments: Dev, QA, and Prod, based off a configuration for my website I will run the following to create a new pipeline called MyPipeline:

akamai pd new-pipeline -p MyPipeline -e Dev QA Prod

This creates a pipeline folder structure in your back end that contains variable definition files and configuration snippets that break down your configuration. The variable definition files will allow you to define variables that are different across your environments (e.g., origin hostnames, content provider codes, etc.). You can parametrize any variable you want using “${env.” in your configuration file to customize this for your needs.

2) Recurring Promotion of Changes

Once you’re finished with the one-time pipeline setup, you can then make a configuration change in the rule snippets that are generated in the local folder structure. A promote command will then enable you to promote configuration changes within the pipeline as often as required. In our case:

akamai pd promote -p MyPipeline Dev (to promote to change to Dev environment)akamai pd promote -p MyPipeline QA (to promote to change to QA environment)akamai pd promote -p MyPipeline Prod (to promote to change to Prod environment)

As mentioned, you can then simply integrate these commands into your build-automation tool. In the example below, I have set this up within my Jenkins build job list:

For more on this topic, check out "Move Faster with Akamai Pipeline and Federated Configuration Development" and "How-To: Using Jenkins and Akamai Pipeline Together".

Sid Phadkar is a product manager at Akamai Technologies.