How to allow developers to implement an effective CI/CD pipeline without dealing with YAML
When organizations think of fostering a DevOps culture, building out an effective continuous integration (CI) and continuous deployment (CD) pipeline is usually brought up as the first step to success. Nowadays, infrastructure teams have a plethora of both open-source and licensed tools such as Jenkins, CircleCI, Github Actions, and ArgoCD to implement various CI/CD pipelines and deployment strategies. However, most of these tools rely on complex YAML templating to trigger the pipelines, which may discourage developers who simply want an easy way to build and deploy their application to cloud-native environments.
Devtron is an open-source software delivery workflow orchestrator for Kubernetes with a built-in CI/CD builder to address this issue. In this article, we’ll review how to configure some common CI/CD steps via Devtron.
In Devtron, CI pipelines can be created via a CI Workflow Editor (trigger from a code repository), linked to an existing pipeline (e.g. templates), or be integrated with an external provider via an incoming webhook.
To create a new CI pipeline, choose the “Continuous integrations” option to open up the Workflow Editor:
Instead of specifying various branch types and triggers via a YAML file, developers can simply choose the source type (e.g. branch, PR, tag) or branch name to trigger the pipeline. Devtron provides three simple stages in the CI steps:
- Pre-build stage: tasks to run before building the container image (e.g. linting, unit tests)
- Build stage: creating the container image
- Post-build stage: tasks to run after image creation (e.g. scanning for vulnerabilities)
The build wizard guides through setting up each of these configuration parameters. If the team already has an existing CI template, developers can opt to link that pipeline or integrate with external tools if the team is migrating from legacy providers (e.g. Jenkins).
If the pipeline is set to trigger automatically, either commit to the branch or submit a PR to trigger the action. Alternatively, users can click on “Select Material” to trigger the builds.
Under the Build History tab, developers can also see vulnerabilities if that feature was enabled under the advanced options. This built-in integration is a nice way to avoid having to add in open-source scanners (e.g. Anchore, Clair, Trivy) or paid-tools (e.g. Jfrog Xray) manually.
Once the CI pipeline is set, we can extend the pipeline to include the CD portion. Simply click on the (+) sign of the pipeline via the Workflow Editor and select the deployment environment (i.e. target namespace/cluster) and deployment strategy.
As with the CI portion, CD comes with three different stages:
- Pre-deployment stage: useful to carry out DB/schema migrations or config setup before the application deployment
- Deployment stage: step to deploy utilizing one of four strategies (recreate, canary, blue-green, and rolling upgrades)
- Post-deployment stage: runs after the deployment to either update Jira ticket, send notifications, or run clean up tasks
All of these stages can be configured using the Workflow Editor. Since CD step is more open-ended, more complex workflows will require writing up some YAML but the config for each stage is relatively minimal:
Also, these pipelines can be linked to create sequential pipelines if multiple deployments or special jobs must trigger in order:
With so many choices in the market today, most teams struggle to create a cohesive CI/CD experience without cobbling together a multitude of tools. While the flexibility of each of these tools provides tremendous value, for some teams, just setting up a simple pipeline is all that is needed. This is where Devtron can provide value in guiding developers through an intuitive widget to set up a pipeline that is ready for cloud-native applications.