Pipeline as Code

In the past years many tools have evolved and especially Gitlab CI, GitHub Actions and AWS CodeDeploy matured or became available and widely used across many teams.

Continuous Integration and Delivery is an important part in every project. Pipelines which are maintained as code, can now be handled like most other parts of your software. The pipeline configuration can run through lint checks, or a test suite before the configuration is shared across teams in your organisation.

Using container based builds is now also the de facto standard. Combining these two techniques enables running isolated builds in an easily reproducible environment so teams can get quick feedback on every change.

We moved this pattern to adopt, because it is used by nearly every team and project now and is an important part of our automation.

For Jenkins, we often use a mix of Job DSL and Jenkins Pipelines and recently also used GitLab Pipelines.

Continuous Integration and Delivery is a critical part of our development and deployment process at DCX. Using Jenkins for many years the "instructions" how to build, test and deploy applications were scattered between many custom scripts and the pipeline was often maintained by manual maintenance of Jenkins jobs. Soon, we realized that we need a more native way to express the full CI/CD pipeline process in code and manage it in version control.

Being an important part of each project, the pipeline configuration should be managed as code and rolled out automatically - this also allows us to manage the pipeline itself applying the same standards that apply to application code.

While some teams started using Jenkins' JobDSL plugin, others explored the new Jenkins Pipeline - in both ways, the build artifacts should be published to an artifact repository such as Artifactory.