Monthly Archives: June 2019

Overriding Pipelines, Stages, And Steps And Implementing Loops In Jenkins X Pipelines

If you’d like to follow the examples, I will assume that you already have a cluster with serverless (Tekton-based) Jenkins X up-and-running.

Before we start exploring how to override different components in serverless Jenkins X pipelines, we’ll create a new quickstart project so that we have a sample application to play with.

jx create quickstart \
    --language go \
    --project-name jx-go-loops \
    --batch-mode

Hopefully, this is not the first time you created a quick start project, and you are already familiar with the out-of-the-box pipeline our new application inherited from a build pack. Also, I will assume that you do understand that buildPack: go instruction in jenkins-x.yml means that the pipeline inherits all the steps defined in the corresponding build pack.

Our pipeline is currently building a Linux binary of our application before adding it to a container image. But what if we’d like to distribute the application also as executables for different operating systems? We could provide that same binary, but that would work only for Linux users since that is the architecture it is currently built for. We might want to extend the reach to Windows and MacOS users as well, and that would mean that we’d need to build two additional binaries. How could we do that?

Continue reading

Advertisement

Ten Commandments Of GitOps Applied To Continuous Delivery

Applying GitOps Principles

Git is the de-facto code repository standard. Hardly anyone argues against that statement today. Where we might disagree is whether Git is the only source of truth, or even what we consider by that.

When I speak with teams and ask them whether Git is their only source of truth, almost everyone always answers yes. However, when I start digging, it usually turns out that’s not true. Can you recreate everything using only the code in Git? By everything, I mean the whole cluster and everything running in it. Is your entire production system described in a single repository? If the answer to that question is yes, you are doing a great job, but we’re not yet done with questioning. Can any change to your system be applied by making a pull request, without pressing any buttons in Jenkins or any other tool? If your answer is still yes, you are most likely already applying GitOps principles.

GitOps is a way to do Continuous Delivery. It assumes that Git is a single source of truth and that both infrastructure and applications are defined using the declarative syntax (e.g., YAML). Changes to infrastructure or applications are made by pushing changes to Git, not by clicking buttons in Jenkins.

Continue reading