Process-as-Code #c9d9

DevOps at scale requires predictability and consistency. Your application code is versioned. Infrastructure-as-code defines your environments. But what about the process?

On Tuesday I participated in an online panel on the subject of Process-as-Code, as part of Continuous Discussions (#c9d9), a series of community panels about Agile, Continuous Delivery and DevOps.

Watch a recording of the panel:

Continuous Discussions is a community initiative by Electric Cloud, which powers Continuous Delivery at businesses like SpaceX, Cisco, GE and E*TRADE by automating their build, test and deployment processes.

Below are a few insights from my contribution to the panel:

What is Process-as-Code

Let me use Jenkins and a software delivery pipeline as an example:

  • At the beginning, only the source code was version controlled. Jenkins contained all the information that was needed to build, test and deploy the application.
  • Then we moved the build, test, and deploy scripts into version control and Jenkins only contained the information about what scripts to execute in which order.
  • Now we put the whole pipeline under version control, and Jenkins only knows where to get the process configuration from to execute it.

So process as code is two things: a description of the process and a runtime environment that can execute that description.

Best Practices

  • Idempotent process steps that can run asynchronously and can be retried.
  • Having a descriptive language for your process and let an execution engine figures out how to execute the process description.
  • We use a lot of Amazon tooling: CloudFormation, Code Pipeline, and Lambda.

Read on






Michael Wittig

Michael Wittig

I’m the author of Amazon Web Services in Action. I work as a software engineer, and independent consultant focused on AWS and DevOps. Hire me!

Is anything missing in my article? I'm looking forward to your feedback! @hellomichibye or

Published on
Tagged with DevOps, c9d9,