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.
Published on
