What is the “As-Code” Paradigm?
Over this holiday break I spent a lot of time watching my son crash in ever more creative ways as he tried to get the fastest lap time playing Forza on the XBox. Just like racing, releasing software is complex, and requires people and technology to work together to continuously reduce “lap times” without careening off the track. DevOps teams must work together, like pit crew and driver, to iteratively adjust and optimize release pipelines to deliver value faster to their customers. One of the most powerful ways to do this is to take an “as-code” approach to DevOps. Is “DevOps” something you can codify? Probably not. But the DevOps equivalent of your F1 race car (things like infrastructure and pipelines) can and should be codified to ensure consistent usage. The classic example is infrastructure-as-code , which allows modeling complex cloud and infrastructure environments using a single declarative code file rather than a mess of scripts and tools. Pipeline-as-code is another example - which takes the same principles of infrastructure-as-code and applies them to the CI/CD pipeline. The result is that DevOps teams can version, test, reuse, and incrementally improve infrastructure or pipeline configurations the same way they would application code. “Shaving another second off your lap time” matters! That’s what the code-based approach is all about and it’s why CloudBees Flow has been providing comprehensive support for a unified object model and pipeline-as-code for over two years. Let’s take a look at how CloudBees Flow’s full support for embracing the “as-code” paradigm allows teams to release faster, reduce risk, and scale DevOps without careening off the road!
Beyond Infrastructure and Pipeline-As-Code
CloudBees Flow’s approach goes beyond just infrastructure and pipelines and allows modeling all the key aspects of your software delivery process in code. DevOps is more than just pushing code to prod. It’s the whole process, including visibility and metrics, that drives iterative improvement. That’s why CloudBees Flow allows you to codify each critical piece of your software delivery process, including:
pipelines and releases
applications and environments
approvals and role-based access
dashboards and reports
self-service catalog items
deployment strategies, like rolling deploys, canary, blue-green, etc.
If you’re using other "as-code" tools like Terraform, CloudBees Flow can support those too. But CloudBees Flow captures your entire CI/CD and release orchestration process as part of your code repository, making everything fully versionable, testable, and repeatable just like all your application code. You won’t have to worry about any unexpected configuration surprises or the dreaded “it worked on my machine”.
Scale DevOps More Quickly Across Your Teams
One of the challenges of code-native based tools like Terraform, Ansible, or Chef is that, while dev-centric folks love them, the barrier between “coders” and “ui-ers” can actually create silos. Developers end up holding all the mind share because no one else knows what they’re writing. Isn’t DevOps about eliminating silos?! CloudBees Flow’s unified object model can be expressed in both code and UI and allows “one-click” toggle between the two. This approach gets coders and non-coders to work together better. Dev and non-dev folks can work on the same system, innovating and collaborating together regardless of whether they’re working in the UI or in code, without fear that someone will make a breaking change to the pipeline. This eliminates code-native silos, makes your whole team more effective, and allows you to scale out DevOps faster.
Declarative and Dynamicis Best for DevOps
CloudBees Flow’s Domain Specific Language (DSL) is based on Groovy, which is both declarative and dynamic. While infrastructure-as-code tools like Terraform may take a more strictly declarative approach, DSL languages like Groovy are more appropriate for Release Orchestration and Continuous Delivery because they support both clear, declarative statements about the configuration of the system (the pipeline, releases, environments, etc) as well as dynamic automation to support actions like roll back, blue-green and rolling deployments, and more flexible error and recovery. That's why Groovy is used by tools like Jenkins pipelines.
Full Control With a Powerful DevOps CLI
CloudBees Flow’s CLI engine - ectool - provides full control over every aspect of the CloudBees Flow release orchestration and continuous delivery engine. The CLI allows you to securely log in to any CloudBees Flow server, whether local, remote, or in the cloud, and apply Groovy DSL files to configure and orchestrate your releases, including creating releases, environments, dashboards, and launching CI/CD pipelines. While third party CI systems like Jenkins or Azure DevOps typically use the native CloudBees Flow integration plugins, they can also use the CLI to remotely to trigger CI/CD pipelines or perform other release related operations.
Start Faster with Code Based Templates
CloudBees Flow makes it easy to create and leverage templates for your software releases that can be reused across teams, allowing fast onboarding of new projects and leveraging best practices your teams develop over time. New teams can take existing code templates and CloudBees Flow will automatically create all the necessary pipelines, releases, environments, application models, and everything else required to support your software delivery process. Plus - CloudBees Flow’s DSL architecture is truly model based and loosely coupled, which means you can define pipeline and release templates that aren’t hard coded to the specific payloads you’re releasing or deploying. This allows versioning release pipeline code separately from environment configurations and application models. That template can be checked in and versioned to ensure it doesn’t change. Different product teams can then use different release payload DSL files for their releases - the template doesn’t change. Other tools claim to support release templates, but require hard coding a reference to the application you’re releasing in the release pipeline, which makes them templates in name only.
Ensure Better Compliance and Security
CloudBees Flow’s modular DSL files allow teams to define security, compliance, and role based access control in code files that are versioned separately from pipeline, release, infrastructure, or other files. For example - a security team could define in code the integrations with security tools that might be part of a release pipeline, while a compliance team could define the requirements for promoting a release from one stage to the next based on test results or other factors, and DevOps engineers or developers focus on other aspects of the pipeline. This way, teams can collaborate while focusing on their domain of expertise, ensuring that software releases are secure and compliant. In addition - defining and versioning your end-to-end release in code just makes auditing that much easier.
Adopt Cloud Native While Still Supporting Legacy
CloudBees Flow’s model based DSL files make it just as easy to model cloud or container based deployments as it is legacy and on-prem. That’s because CloudBees Flow’s unified plug-in architecture is also model based and abstracted - meant to be consumed natively as modules within DSL files. This allows abstracting the complexity of deployments, so referencing AWS EKS, Google GCE, or native Kubernetes doesn’t require writing scripts but rather making simple configuration declarations. Deployments to on-prem legacy environments is also abstracted and just as straight forward. This, along with the fact that pipelines, environments, and applications are all loosely coupled, means that you can easily change the release target of an application from an on-prem environment to a cloud or container environment just by using a different DSL files and without having to make a code change to your release pipeline file.
The Benefits of Going With Code Using CloudBees Flow
Pipeline-as-code, continuous-delivery-as-code, devops-as-code, or everything-as-code - whatever you want to call it, jumping on the “as-code” bandwagon has huge benefits for your teams.
Release faster by constantly tuning and improving your entire release process - whether you’re doing traditional releases or CI/CD or both.
Scale out DevOps with powerful reuse of code templates
Make teams more efficient by allowing dev and non-dev teams to work better together.
Improve auditability, compliance, and security of your whole end-to-end release and continuous delivery process.
To learn how you can tune your DevOps engine and adopt “as-code” approach to release orchestration and continuous delivery schedule a demo with one of our technical experts - and shave some serious time off your lap time!