How Akamai Works With Your Source Code Management and DevOps Workflow

October 22, 2019 · by Dale Lenard ·

One of the common challenges in the DevOps world is how to incorporate a source code management (SCM) repository—such as Git or others—into a DevOps workflow. Typically, it looks like this:

DevOps workflow with SCN

But specifically how does this look (and work) if you’re an Akamai customer?

In this blog post, we’ll discuss SCM repositories and how Akamai products and tools can work with them to improve your DevOps workflow. 

Here’s the short answer: With the broad offerings in Akamai for DevOps, Akamai can be tightly integrated into DevOps-with-SCM workflows, allowing you to start using infrastructure as code (or, more specifically for Akamai, using your Akamai config as code).

Now, let’s take a deeper look at this answer.

The illustration below gives an overview of how Akamai can be part of a DevOps workflow that incorporates a source code management repository. Namely, there are four key Akamai components here:

DevOps with SCM & Akamai
Akamai embedded into an SCM repository and DevOps workflow utilizing Akamai Pipeline, Sandbox, mPulse, and DataStream

One of the easiest ways for you to utilize the infrastructure-as-code approach mentioned above is with Akamai Pipeline, which enables you to treat configuration changes just like any other piece of code within your workflow. Akamai Pipeline allows for SCM integration while also enabling you to deploy and activate your Akamai configurations via APIs. This makes your DevOps workflow even faster and more efficient.

Additional benefits of the Akamai-SCM-DevOps combination

Two other benefits of this overall approach are better version control and branching. Here’s an example: Imagine you have multiple developers working on a release. In a typical agile environment, each developer would be working off individual feature branches for application code development and/or infrastructure changes. Once their work has been successfully tested, they would merge their changes into development for testing, and then build a release and push it to customers. That, of course, is a fairly cumbersome and inefficient process.

With the Akamai-SCM-DevOps approach, however, individual developers now have the capability to make configuration changes and deliver those changes directly through the organization's infrastructure. This could either be done via the JSON file of the property or via snippets with Akamai Pipeline.

But wait, there’s more: For additional efficiency and automation, you can bring in Akamai Sandbox to automate your testing. Akamai Sandbox is an isolated testing environment (i.e., a sandbox) that you can use for testing development versions of property configurations before deploying to the content delivery network. The configuration that you’re testing with Sandbox can either be an existing property configuration or a JSON property passed into your sandbox.


You can realize significant efficiencies via the Akamai-SCM-DevOps approach outlined above. With this approach, your dev team can be making changes through feature branches, with isolated development testing occurring automatically against those feature branches, followed by automated deployments via your SCM repositories and DevOps workflow.

Dale Lenard is a web performance architect at Akamai Technologies.