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.

CI Pipeline

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:

1. Pre-build stage: tasks to run before building the container image (e.g. linting, unit tests)
2. Build stage: creating the container image
3. 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.

CD Pipeline

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:

1. Pre-deployment stage: useful to carry out DB/schema migrations or config setup before the application deployment
2. Deployment stage: step to deploy utilizing one of four strategies (recreate, canary, blue-green, and rolling upgrades) that can be configured per use case
3. Post-deployment stage: runs after the deployment to either update Jira ticket, send notifications, or run clean up tasks
4. 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.

Configure the pre-deployment stage to run automatically or manually with a config like the following. The following example shows using Flyway to manage database migrations.

Post-deployment stage works similarly as the pre-deployment stage:

You can run smoke tests or end-to-end tests on lower environments after deploying. As shown above, you can use a node or cypress docker image to run tests:

$ docker run -it -v $PWD:/e2e -w /e2e --entrypoint=cypress cypress/base
Finally, these pipelines can be linked to create sequential pipelines if multiple deployments or special jobs must trigger in order. To create a sequential pipeline, click on the + sign on the right side of the existing pipeline components to add new jobs:

These pipelines can be linked to sequentially deploy to multiple environments (e.g. dev → QA → UAT → prod).

Conclusion

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.

Resources

• Full end-to-end demo of deploying a sample application using the CI/CD pipeline
• Installing Devtron and deploying a sample Helm chart