Sailing the Jenkins Blue Ocean
Around July last year, with the introduction of some new components in the systems we build at mPort, we also introduced some new CI/CD tooling. I’m experienced with the tools built by previous companies I’ve worked for (particularly ThoughtWorks and Atlassian), so GoCD and Bamboo were good candidates. Jenkins was not (at the time). This article does not dwell on the specific pros and cons of those products in the specific mPort context. Suffice it to say, they are all fine products and the evaluation criteria for mPort are not the same for other teams.
For the past year or so, the team at mPort have been focussed on constantly improving the rate of delivering value with high confidence. This has meant quite a few changes and experimentation with how we work. The first step was taken with a GoCD server and, once the security-oriented configuration for the infrastructure-as-code was worked out (with some gaffer tape and string), it was working well enough.
A few months later, though, when the product manager for Blue Ocean asked me what I thought about their early beta, I took it as an opportunity to test it out for more than just a hobby project (as I had been since May) and see how it helped a team get better at DevOps, Continuous Delivery, and improving visibility of their activity throughout the organization. I expected this to be a fruitful experiment as I trusted the Blue Ocean core team from CloudBees based on having worked with one of them before (at Canva and Atlassian), and many sensible technical conversations over many years with the others.
Within two days, the relevant builds were migrated from GoCD and we ran both pipelines simultaneously for a few days (apart from the deploy steps) to verify. We then swapped to Blue Ocean for a deploy through each environment. At that point, we disabled the old pipeline and a few weeks later it was removed.
The first appealing thing about the Blue Ocean project is the thing you notice first — the UI. Jenkins is long in the tooth and its UI is, to put it mildly, ugly and awkward to work with. But Blue Ocean goes beyond just the fonts, colors, and layout. This is not a pig with lipstick. The entire UX is transformed and the solid, fully-featured, ecosystem-rich platform that is Jenkins CI is now becoming a pleasure to work with.
Blue Ocean has been built with a high level of user empathy. They know how convoluted, confusing, time consuming, and unappealing it can be to work with build tools. Even things like the console log being split into regions for steps and focussing on the failed steps is an eye-rollingly obvious and yet desperately welcome addition.
More importantly, Blue Ocean alleviates the need for the often more experienced developers and CI experts to be the only ones to configure projects, stages, steps, etc. Having all of the members of the development team understand the CI/CD pipeline is important in a high-performance team, and Blue Ocean has allowed anyone in my team to build and maintain those pipelines.
Furthermore, in a transparent, collaborative organization, it means anyone can visualize what is happening in that pipeline at any time. It is a pretty special thing to see the head of marketing and the product owner looking at an office dashboard, following a particular feature from git push to first user analytics.
Because I prefer trunk-based development and feel it is a necessary approach to successful Continuous Delivery, I eschew long-lived branches, be they “feature” or otherwise. However, in a distributed team especially, short-lived shared branches are often unavoidable and can make for a useful means of temporarily working with discrete changes to the software in isolation (and that isolation is the two-edged sword).
Blue Ocean and Jenkins are developed by a globally distributed team. They know first-hand what it’s like to have a high throughput of small-batch feature branches and pull requests vying for attention. Other CI servers have this capability too, yet Blue Ocean makes it stunningly simple for people who don’t intuitively understanding branching to see the results of candidate builds. It even takes the cognitive load away from those of us who do understand such things by making it blazingly obvious where merges need attention, without taking away the detail required to resolve the issue.
I mentioned infrastructure-as-code earlier. Given the CI/CD pipeline is a critical piece of infrastructure, it is vital that the meta-pipelines (the ones that build and configure the various layers of infrastructure for delivering the customer-facing production software) are also readily understood.
I’m not a mouse person. I prefer to define my software, integration, infrastructure, and tooling in terms of declarative textual specifications. (An excellent satirical insight from one of my former coworkers using Tibco at a client was that all he needed to integrate millions of dollars of enterprise software was two mouses — one to drag, and one to drop.)
For example, why clicky-click in the AWS console when you can Terraform your cloud? Why clicky-click in the a build server management console when you can have declarative source code define configuration, projects, stages, etc? Such source-code based mechanisms are intentional, testable, versionable, comparable, and more easily transposed to other tools. Nonetheless, this meta-infrastructure can be non-intuitive and people find it hard to know which turtle they are on (or which level of “Inception” they are in).
In a humble and adept “you’re welcome” to the devops community, Blue Ocean has made it vastly simpler for anyone in the team to build and visualize not just the software pipeline, but the pipeline that builds that pipeline. This is also made a lot simpler with advancements like Habitat and Docker, but it’s really important in a team with collective ownership to have those tools in the right context in the meta-pipeline.
Our Blue Ocean server includes a project to provision, deploy, and configure itself. It treats itself as another head of cattle, not a pet, or a snowflake. As the person who often is the custodian of meta-infrastructure, it is huge relief to have this elevated to the status of first-class software — just as important and vital as the user-facing software it is building.
With Blue Ocean, software delivery team members of all skill levels can participate in Continuous Delivery because we get a great visualization of our software pipelines throughout the entire process. We are now able to include the software delivery pipeline itself as infrastructure-as-code without compromising usability; that has vastly improved the confidence in and timeliness of our software deployments. Furthermore, Blue Ocean offers a superb user interface — well ahead of anything else available.
I am looking forward to expanding our use of Blue Ocean and the richer features that will be added to it, particularly as it takes on capabilities from tooling we have had to use in the past and we migrate those builds across.
This was an important experiment for mPort’s engineering team and our whole-company collaboration stance, and it has been a resounding success.
