Jenkins: Running a declarative pipeline from your Shared Library

As shown in the previous blog post, Jenkins enables you to write your own pipeline code, which can be shared among all pipelines in your Jenkins instance.

This post is part of a Series in which I elaborate on my best practices for running Jenkins at scale which might benefit Agile teams and CI/CD efforts.

Where we’ve focussed on custom steps previously, I’ll now demonstrate how to create and use full declarative pipelines from your Shared Library.
This way you can minimize the amount of duplicated code in your projects by getting nearly all pipeline configuration from a central location.

Read More »

Advertisements

Jenkins: Creating a custom pipeline step in your library

Pipelines in Jenkins, especially the declarative kind, can be very powerful and expressive at the same time.
As a caveat, it is also very easy to get overly verbose by (mis)using the script-tag to write all business logic not provided by Jenkins by default or by a plugin.

This post is part of a Series in which I elaborate on my best practices for running Jenkins at scale which might benefit Agile teams and CI/CD efforts.

The Jenkins Shared Library has a solution for this, by enabling you to write your own custom pipeline steps, without creating a plugin.

Read More »

Jenkins: Using Gradle to build your Shared Library

Being able to test your Jenkins pipeline Shared Library code, and therefore minimising the risk of pushing new pipelines or functionality to your Production instance, is vital for organisations using Jenkins at scale. Having your teams impeded by a ‘simple’ change in your Jenkins Shared Library is simply unacceptable in many cases, and even more so if it can be avoided altogether.

There is always a certain risk attached to pushing code to Production, but any effort to minimize this risk is welcomed as it will save the organisation real money in the long run.

This post is part of a Series in which I elaborate on my best practices for running Jenkins at scale which might benefit Agile teams and CI/CD efforts.

The first part of being able to run tests on your Shared Library is being able to ‘run’ the code, and with the Library being Groovy, code Gradle is the logical choice.

Read More »

Jenkins: Setting up a Shared Library for your pipelines

When you’re using a system with multiple teams/users, there is always a trade-off between having a shared codebase and the ability to override certain parts for a specific need.
Using Jenkins and the modern scripted or declarative pipelines with multiple users or teams is no exception to this, as there will always be an edge case which differs subtly from the norm. It might differ for any reason, even if it is just the stubbornness of a certain individual or a team.

Please note this does not apply to the more traditional Freestyle jobs, as they do not rely on code to run, but are defined in XML files on the Jenkins Master.

This post is part of a Series in which I elaborate on my best practices for running Jenkins at scale which might benefit Agile teams and CI/CD efforts.

So, we have at least two criteria for our Jenkins set up:

  • Having a shared code base for your declarative or scripted pipelines
  • Being able to override behaviour as needed

Read More »