Key Takeaways from Continuous Discussions (#c9d9) Episode 48: Process-as-Code

Last week, we hosted another episode of our Continuous Discussion (#c9d9) video podcast, featuring expert panelists discussing process as code . Our expert panel included: David-Blank Edelman , technical evangelist for Apcera; Juni Mukherjee , Author of “Continuous Delivery Pipeline – Where Does It Choke? ”; J. Paul Reed , managing partner of Release Engineering Approaches; Mark Chassy , product director at Orson Software; Michael Wittig , Author of “Amazon Web Services in Action ”; and, our very own Anders Wallgren and Sam Fell. During the episode, panelists discussed their definitions of process-as-code as well as use cases and best practices for defining your automation processes as code, and ensuring your automation is versionable, testable, and repeatable.

What is Process as Code?

Process as Code: @hellomichibye says treat that pipeline like a product and optimize as you go | #c9d9 pic.twitter.com/FXa3wXoF1v

— CloudBees (@electriccloud) August 23, 2016

Process as Code allows there to be a democratization of process in the organization | @jpaulreed #c9d9 #IT pic.twitter.com/b6SRxS6K0t — CloudBees (@electriccloud) August 23, 2016

Process As Code is a great wiki-ization of knowledge sharing - it's powerful for the org @anders_wallgren #c9d9 pic.twitter.com/p5XwlShDlk

— CloudBees (@electriccloud) August 23, 2016

Wallgren “If you manage to do this and it encompasses your end-to-end pipeline and all of the stages in it, then I think it’s really powerful to have an external representation of that thing – whether it’s the policy aspect of it or the coding part of it. It’s a great way to avoid the wiki-ization of knowledge. Code is a great way to document, interact and communicate, so there’s a lot of powerful side effects you get out of doing automation as process as code.” Automation is key, says Chassy : “If you say, ‘Here is my ecosystem. I'm giving you the right to do what you want with these automated tools, go do what you want because I've already set the limits,’ maybe that can allow you get outside of the strict ‘You must do it like this.’ As much as anything about code is as soon as you put it on a wiki it's out of date, the same thing is true of any kind of business requirement. As we automate everything, the question is how we can actually automate the business requirements going into the software that we're working on in the first place.” Mukherjee , who is in charge of process at her company, explains their methods for using process as code: “The entire process, along with the KPI’s, the measurements, the success metrics, the tests, the configuration management, the deployment, the auditing – it’s all code. Initially there was nervousness about automated agents doing what otherwise a human would carefully do, but the automated agents have made it even more traceable and predictable, and compliance and risk were actually jazzed that there was a better chance at making mistakes. There is still room to make mistakes – to err is human – but everything is traceable and repeatable so in general everyone is happy.” It’s not just about pipelines and automation, there is a bigger picture to process as code, explains Reed : “What we are really trying to understand is what we do as individuals, how that coalesces into what we do as a group and how that then produces something of value - like a deployed artifact of software. We’re trying to capture the context of all of this in some way and model it in some way. You can’t have a discussion about doing the right thing or the wrong thing without having that context.” Fell elaborates on process as code as part of your pathway to production: “Your pathway to production can be transformed from a chore to a competitive advantage. If you have a great Sprint and you get a lot of great features in but you never ship it you really haven’t solved any problems. So getting it out and making it prescient is a part of that process.” People are just as important in process as code, according to Blank-Edelman : “Process is people to a certain extent, so when we say that developers are super good at running in the same direction together and always playing nice, my senses meter starts to move a little bit closer towards. I think that one of the things that process as code gives you – if you get lucky – is that you hit on a good representation for what you are trying to talk about that everybody can agree upon. Then you can write that representation down and everybody can agree on what are the symbols, the verbs, the actions, and the nouns in this world, and if you can agree on it and write it down, then you are a lot farther along than many other people.” Wittig describes his process using Jenkins: “A few years ago I had to use a Jenkins server. We used it to build our software and a lot of configuration was inside Jenkins - it was separated from the code. We thought that this is probably not a good idea and we put all this scripts we used to build our software into the code repository, and Jenkins only triggered those scripts. Now we're also pushing the whole pipeline configuration into our code, and Jenkins executes the pipeline as a whole.”

Best Practices for implementing Process-as-Code

"Break stuff and fail fast - make it okay to have failures" - advice on process as #code per @otterbook #c9d9 — CloudBees (@electriccloud) August 23, 2016

Sometimes scripts don't work, so every action should be "item open" | Process as Code @hellomichibye #c9d9 pic.twitter.com/TvWnE9myp2

— CloudBees (@electriccloud) August 23, 2016

Maybe process as code isn't about #automation as much as it is about capturing context | @jpaulreed #c9d9 pic.twitter.com/OKjet7crom — CloudBees (@electriccloud) August 23, 2016

You can codify the process of testing and gather the results of that instance @mark_chassy #c9d9 #softwaretesting pic.twitter.com/aqsAPxG5El

— CloudBees (@electriccloud) August 23, 2016

Your processes should mirror your environment - be aware of how your organizational communication works @otterbook #c9d9 #code — CloudBees (@electriccloud) August 23, 2016

Fell mentions the difficulty bimodal IT adds to the mix: “Culturally it’s tricky. Gartner talks about bimodal IT. So not only are you stuck between some automated and some manual, but you are also stuck between some super automated and some 18-month releases where not a lot is automated – there’s a lot of emails and spreadsheets. Trying to tie those together and have governance around those things becomes really complicated.” Don’t let your tests remain static, advises Chassy : “I could write a bunch of tests, and if I put them in a certain tool like Quality Center it's all sitting there. What good are my tests if they're sitting there static, as opposed to a piece of code which generates the test on the fly based on the parameters I need? And then there are tracking tools out there that will tell me what happened and then I can tear them all down and throw them all away because I still have the code which will generate them later, saving many logistical nightmares that way.” Mukherjee “When a company tries to do process as code, they usually send a pilot down the line first because you go there you learn and teach the rest of us. There’s the canary in the coal mine – even if the canary dies at least it’s just one canary instead of all of them. It’s important to have a pilot for each pipeline – mobile, database, Java, etc. – because each of them are different Wittig “I think I learned two things in the last year. The first thing is that scripts sometimes don't work, and if the process consists of actions and you can execute them multiple times, each time it should produce the same result. It should be able to run asynchronously. The other thing is that often it is very easy to have a descriptive language for our process and have the runtime environment that runs your process. So, don't script the process, use another language to describe the process and have some execution engine that executes the process, because it gets very tricky with dependencies - processes are often very complex.” Ask questions along the way, says Wallgren : “Treat this as a living thing. When you do your iterations and you do your retrospectives spend some time thinking about if the pipeline is in good stead is the process working, do you need to make any changes or tweaks? Evolve it as you evolve everything else in the product.” The context behind process as code is constantly changing so be prepared for that, advises Reed : “The one thing I see people struggling with when they are on this journey of codifying things as a code artifact is ‘How do you do that?’ How do you go about the practice of automating things? I have clients work through a check list for the purpose of creating requirements to do process as code or automation. Because process as code is so intertwined with that context – How do you account for the fact that context is always ongoing and moving? How do you continue to incorporate that when you’re just starting out?” Get on the same page of communication, advises Blank-Edelman : “We can't have a discussion without bringing up Conway's Law – your process is going to mirror your environment and your organization. I would say that one best practice is to be aware of how organizational communication is going on and how it actually works. If your processes are going against that rather than with that, if you are swimming upstream with your processes that's going to be a lot of wasted effort.”

Watch the full episode here:

Want more Continuous Discussions?

We hold our #c9d9’s every other Tuesday at 10 a.m. PST, which features expert panelists talking about DevOps, Continuous Delivery, Agile and more. Next time on Continuous Discussions: Deployment Patterns.