CI/CD pipelines on Jenkins. • A lot of steps are common - build, test and deploy steps are usually same. • Such code is usually duplicated. • Making updates is difficult. You need to change shared code across all places.
Groovy, has access to all JVM features. • You can define shared scripts, callable as functions from individual pipelines • Enables code reuse and reduce time to market for dev teams. • A code change to our shared library goes live immediately and is consumed the next time a team triggers their project's pipeline.
Kubernetes infrastructure with separate staging and production clusters. • Deployment steps : They are similar across different projects, typically involving. ◦ Language specific build ◦ Docker build ◦ Helm upgrade • All of this can be neatly packaged as a Jenkins shared library so that pipeline consumers can simply:
of docker_build and deploy are stored in a central location as a Jenkins library which is backed by a git repository for the same. • Libraries can utilize third artifacts from Maven by using Groovy specific @Grab declarations giving you endless possibilities of extensibility such as importing Kube client for Java and making API calls from the pipeline code itself. • So let's say you wish to change your Kubernetes deployment tool from Helm to Tanka, you simply commit your changes to the git repo and it is available across all projects.