The Difference Between CI Pipelines and DevOps Assembly Lines
Learn how continuous integration pipelines versus DevOps assembly lines are different, and how they get you closer to continuous delivery.
Join the DZone community and get the full member experience.Join For Free
what's in a name? wrote the greatest bard that ever lived.
he was wrong. if someone ever asked me a hypothetical question about which dead person i'd want to have a conversation with, it'll definitely be shakespeare. let me explain why.
when we launched shippable pipelines last year, we wanted to highlight the difference between plain vanilla ci and the capability to put together a deployment "pipeline" that spans orchestration across multiple environments and supports all tasks involved in software delivery like ci, infrastructure provisioning, test automation, deployments, security patching, release management, config mgmt, service discovery, etc.
however, shortly after we launched, other ci providers launched their own interpretations of "pipelines!" for example,
how did everyone come to the same exact place so rapidly? as we found out, they didn't. " pipelines" was being used as a fancy name for ci, with features that shippable had supported for over two years, like matrix builds for splitting tests or testing against multiple environments for example.
we needed a way to explain why shippable is different. this blog explains why we landed on devops assembly lines as the perfect way to describe our approach to devops and ci/cd.
what are ci pipelines?
continuous integration has evolved tremendously over the last few years. what started as a simple process of automating build and unit tests for each code change has evolved into a pretty complex workflow.
as an example, look at the different ci workflows shown below:
in classic ci , all build and test instructions were included in a single blob and instructions were executed serially. if all instructions executed successfully, ci was succesful, and if anything failed, then it was marked failed. almost all ci providers, until recently, offered just classic ci.
however, as ci became mainstream, developers wanted to define more complex workflows with decision trees and parallelism. ci pipelines support this complexity, such as:
- defining the ci workflow in stages, so you can get results from a stage faster without having to wait for the entire workflow to finish.
- running stages in parallel, so you can split tests or test your code against different environments or language versions, and get faster feedback.
- forking your ci logic based on the results of a stage.
while ci pipelines are a huge improvement over classic ci, they are still limited to developer-focused workflows.
what are devops assembly lines?
devops assembly lines are focused on automating and connecting activities performed by several teams, such as ci for devs, infrastructure provisioning and config mgmt for ops, test automation for test, security patching for secops, semantic versioning and approval gates for release managers, deployments for multiple environments, and so on.
today, most organizations use various tools for automating specific devops activities. however, the devops toolchain is fragmented and glueing it together to achieve continuous delivery is a challenging task.
most teams adopt one of the following approaches:
- using cultural collaboration as the glue between silos. as an example, when a new application version is available, the test team creates a jira ticket and assigns to ops. ops then copies the application version information into their deployment scripts and run them.
- writing ad-hoc scripts to trigger one activity from another, including passing state information through intermediate storage like s3. in this case, the devops engineer would likely write a jenkins job which runs automated tests, and then pushes application version information to s3. another jenkins job polls the s3 bucket, and when a change is detected, runs the deployment scripts.
the first approach introduces inefficiency and unnecessary human-dependent steps. the second approach is better, but only works well for small teams working on a single application. it creates a frankenstein of spaghetti automation when you have many applications or even a single application with microservices.
devops assembly lines address this problem by focusing on gluing together these various devops activities into streamlined, event-driven workflows with the ability to easily share state and other information across activities.
the following image shows a typical assembly line for a single application or service:
see the difference?the ci pipeline is just one activity in the assembly line. each of the boxes in the picture above is a pipeline, just for different activities! each has specific needs with respect to tools integration, runtime, configuration, notifications, etc. in addition, each pipeline is owned by a different team, yet needs to interact with other pipelines and exchange information. for example, if the ops team changes provisioning scripts for staging environment, the test team need to redeploy the application and run performance tests.
a devops assembly line is, therefore, a "pipeline of pipelines"
devops assembly lines, therefore, need to support the following:
- ability to easily define workflows across multiple pipelines.
- versioned and reusable workflows, enabling rapid changes and scaling for multiple applications and/or microservices
- integrations with all popular source control systems, clouds, artifact repositories, devops tools, languages, services, etc
- runtime to execute every pipeline, including pre-installed tools and clis, and the ability to use the right runtime, depending on pipeline type
- accelerators/playbooks for common pipelines and tools
- ability to pass state and other information while triggering dependent pipelines
- automatic triggers or manual approval gates between each pipeline
- configurable notifications for each stage of every pipeline
- release automation features like semantic versioning of packages
- audit trails for each pipeline, with the ability to go back or forward to a specific state
- abstraction of all sensitive information like passwords, tokens, keys, etc for security reasons
- roles and permissions restricting assembly line and pipeline actions
- manage devops infrastructure, including spinning vms and containers up and down as required
- visibility into each pipeline and stage, including logs, status, and versioned data
- metrics and analytics across pipelines to help identify bottlenecks
devops assembly lines help automate end-to-end workflows across all teams and tools, enabling continuous delivery.
for a deeper look at assembly lines, download our whitepaper .
Published at DZone with permission of Manisha Sahasrabudhe, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.