Monthly Archives: April 2019

Implementing ChatOps With Jenkins X

Jenkins X main logic is based on applying GitOps principles. Every change must be recorded in Git, and only Git is allowed to initiate events that result in changes in our clusters. That logic is the cornerstone of Jenkins X, and it served us well so far. However, there are actions we might need to perform that do not result in changes to the source code or configurations. Hence the emergence of ChatOps.
Continue reading

Going Serverless With Jenkins X: Exploring Prow, Jenkins X Pipeline Operator, And Tekton

The serverless flavor of Jenkins X or, as some call it, Jenkins X Next Generation, is an attempt to redefine how we do continuous delivery and GitOps inside Kubernetes clusters. It does that by combining quite a few tools into a single easy-to-use bundle. As a result, most people will not have a need to understand intricacies of how the pieces work independently, nor how they are all integrated. Instead, many will merely push a change to Git and let the system do the rest. But, there are always those who would like to know what's happening behind the hood. To satisfy those craving for insight, we'll explore the processes and the components involved in the serverless Jenkins X platform. Understanding the flow of an event initiated by a Git webhook will give us insight into how the solution works and help us later on when we go deeper into each of the new components.
Continue reading

Versioning Releases

Versioning is one of those things that can be done in many different ways. Almost every team I worked with came up with their own versioning schema. When starting a new project, quite often we would spend time debating how we are going to version our releases. And yet, coming up with our own versioning schema is usually a waste of time. The goals of versioning are simple. We need a unique identifier of a release as well as an indication of whether a change breaks backward compatibility. Given that others already agreed on the format that fulfills those objectives, the best we can do, just as with many other things related to software development, is to use the convention. Otherwise, we are probably wasting our time reinventing the wheel without understanding that a few things are likely going to go wrong down the line.
Continue reading