I believe in simplicity. It means I think things should be simple to work with. It doesn’t mean that it always should be simple inside. It could be complex, sometimes very complex. At the same time, I distinguish two types of complexity:
- complexity caused by indirect and non-obvious relationships between components,
- complexity caused by mess within components itself and messy relationships between them
First one means product could be implemented in a very smart way, built on large number of implicit assumptions, often non-obvious.
Second one means product’s complexity is exaggerated by very confusing, illogical and messed up relationships between components. Unlike the first one, relationships exists, but they make no sense not because they are so over-smartly designed, but because they are spaghetti-like.
Often those two types could be met together in same product. Hope you’d never had a chance to deal with such.
The way to fix complexity type #1 is to remove implicit assumptions by adding smaller components with visible relationships.
However, to fix complexity type #2, you need to understand it deeply. What if thing is complicated b/c you can’t understand it yet at this moment? To be able to answer this question, I always start with research. And my research has some kind of diagram. I believe that visualization is the best way to tackle complexity. At least it always works well for me.
Simply put, visualization is one of the best ways to simplify hard and complex things. Even if this is a very basic diagram, it is still better than nothing. Sometimes, it requires a time to find a correct form of visualization within correct level of abstraction, but once you did it, you are half done.
And this post is about visualization; and how it can help to combine parts into a single simple picture. And more specifically, it is about how visualization can help simplifying continuous delivery.
Continuous delivery is a process of getting you product from source code and into production. It usually happens through a pipeline of jobs: first job is compiling source code and building artifacts, then goes integration testing , deploying to staging environment, and eventually to production. For example, in Jenkins job is usually created for each of these steps, where each job triggers next one once it’s finished successfully. Fore example, there would be jobs like ‘Build XYZ,’ ‘Test XYZ,’ ‘Deploy XYZ to Staging,’ ‘Deploy XYZ to 1-box’ and ‘Deploy XYZ to Production’.
Default Jenkins View would present those jobs as a list, with no visible relationships between those. But there are relationships between them. And actually all those jobs are here for the single most important goal: get new version into production for the customers! So relationships play important role, which is hidden from us as users.
You might not even feel it immediately, but this presentation of jobs list brings a complexity. There is a sense behind those jobs, but it is normally hidden from viewer, unless one ready to spend time to understand how things work.
But good thing is Jenkins already allows you to remove this complexity. And it’s via visualization of the pipeline of jobs you’ve created.
This support is brought by “Build Pipeline Plugin”. This plugin adds a new “View” type called “Build Pipeline View”.
In a next step you would need to pick your first job in the pipeline.
Then pipeline would be created based on jobs dependencies: this pipeline will contain jobs that would be triggered by first job, and also jobs which are triggered by that jobs and so on. And now once someone makes a change into XYZ source, a new job for “Build XYZ” would be triggered. Once this job is finished successfully, it will trigger “Text XYZ” and so on. As you see no functionality change happened here, but with pipelines it is possible to visualize both dependencies between those jobs and what is a current state of the CD process.
That makes things so simple to work with. You can understand build structure and current state with a single glance.
More to that, Jenkins 2.0 comes with built it support for pipelines.
I’d also like to mention the initiative called “Blue Ocean” which sets a goal to build a better visualization of pipelines in Jenkins. I’d be happy to see it in live one day.
There are bunch of other products that would help you to create build / deployment pipeline:
Originally published at blog.khmelyuk.com.