The 2016 edition of Jenkins World just took place at the Santa Clara Convention Center in California. This wasn’t a mere 2016 edition of an old recipe. Instead, the concept evolved from a couple of parallel tracks over two days in 2015 to planning a full week of workshops and training, onsite certifications, three keynotes, five parallel tracks (including two dedicated to CloudBees), an extended community booth and mini-theater, a CloudBees Select Program for major customers and a CloudBees International Program for those traveling from outside of the United States, a community appreciation event, a multi-day offsite community hackathon, a customer briefing center and more.
Any significant evolution represents an execution risk, yet, the result was above expectations:
- While the conference was spread over two days, the full set of proposed activities was spread over a full week!
- About 1,500 persons attended Jenkins World, coming from 32 different countries!
- 36 companies sponsored the event, including the likes of Red Hat, Microsoft and Computer Associates as well as some customers!
- More than 50 high-quality presentations took place in five parallel tracks. The sessions and keynote recording should be made available soon, so stay tuned! The slides are already available from within the Jenkins World agenda page.
- Keynotes were introduced by two nice movies, one for the Jenkins community, the other one to introduce CloudBees and our work in the community.
- Several hundred people registered for our various workshops and training. On Tuesday, the day before the conference even started, 400 persons were already buzzing around, getting trained and certified! During the week, 213 candidates decided to get certified, 133 passed (62%).
- The community booth was a resounding success, with super-packed demos and community members actively discussing new ideas.
- We invited the team at Commit Strip to create a mural for the event, a mural that had to be painted by the attendees! This generated lots of interest, try to see if you can find themes related to Jenkins in it. The mural will be shipped and exposed in our new office in Raleigh, NC!
- We demoed a Jenkins cluster of 2,000 masters and 8,000 executors, on about 300 VMs, running on the CloudBees Jenkins Platform - Private SaaS Edition, demonstrating the ease-of-use, elasticity, fast on-boarding of new teams, super low maintenance costs and resources, resiliency through automatic recovery of instances, as well as the high density of such an approach. As of today, anybody tells you that Jenkins doesn’t scale, simply send them this:
- Furthermore, that same week, we rolled out our new branding, most visibly represented by our new logo:
The result of all of this was amazing. Here is a picture of the keynote room just before we opened the floor on Wednesday:
There is one thing that can’t be easily expressed by numbers, though: people’s energy. You could really feel this energy, this desire to learn and share and to meet with people from the community. Having been involved in open source for 17 years now, I can ensure you the Jenkins community is unique in so many ways, and this is thanks to Kohsuke Kawaguchi’s care and talent.
The community, through Kohsuke, gave a number of demos and made some announcements that I think will strongly influence Jenkins for years to come. Let me cover two of them…
When it comes to Jenkins, the UI is a hot topic! Jenkins was born more than a decade ago and has more than 1,200 plugins. This makes UI evolution very hard, as any UI change can break compatibility with those plugins. Work had been done as part of the Jenkins 2.0 release to improve some aspects of the current UI, without radically changing the underlying API contract, hence keeping plugins compatible. However, it was obvious that a next generation UX was required in order to appeal to a new generation of continuous delivery users.
To that end, a few months ago, CloudBees initiated a project aiming at re-thinking what this next generation UX could be, without worrying about any plugin compatibility. Clean slate. This meant focusing less on a “generic” table-view for all things, but rather thinking about use-cases and how people want to use Jenkins as part of their flow. This lead to a radical shift, Blue Ocean:
Blue Ocean works on any Jenkins 2.0 installation through the simple addition of the Blue Ocean plugin. You can then move back and forth between the existing and new UX. The feature set of the new UX will rapidly increase up to a point where people will never need to go back to the old UX. This provides a smooth evolutionary path with time for the plugin providers to adapt.
Blue Ocean is currently stable and can be used, but it is tagged as beta as the teams first wanted to make sure some features were in it. You should try it!
The UX of the CloudBees Jenkins Platform will follow the same path and be released sometimes in H1-2017.
Continuous Delivery Pipelines: Simpler Language and Editor!
The other very important project that was unveiled during the keynote is another project initiated by a CloudBees team (codename “Kyoto”) aimed at simplifying the creation of continuous delivery pipelines. The initial pipeline language had a relatively steep learning curve, as one of its prerequisites was to either learn or know Groovy. This new approach doesn’t have such a constraint and offers a way to declaratively build a pipeline, very simply:
This new language fully sits on top of the existing Jenkins Pipeline infrastructure/API, so fully leverages its feature set. It does not introduce a new world that would be incompatible with the existing pipeline language.
Furthermore, this declarative approach provides a two-way street to a graphical editor that’s already a work in progress, so stay tuned! Early documentation can be found here.
What About CloudBees?
From a CloudBees standpoint, we made several important announcements.
CloudBees Jenkins Enterprise and CloudBees Jenkins Platform 2.0
Successful open source platforms, pretty much all go through the same evolution: communities and companies start creating extensions on top of the core platform, providing more value and, in turn, making the platform more valuable. Hence more communities and companies decide to join the fray and provide extensions of their own, which makes the platform even more appealing: this is a virtuous cycle that makes these open source projects the de facto leaders in their space.
In the Jenkins community, these extensions are called plugins and you can currently find more than 1,200 of them!
Yet, this success also comes with unfortunate side effects. This is not just a Jenkins issue, all open source projects face it in their own way. We sometimes call this “death by a thousand plugins.”
- Not all extensions have the same level of maturity and some should simply not even be considered for use by enterprises.
- Additionally, while most plugins might be stable when used on their own, no real testing is performed to validate the stability of these plugins in combination with each other, as part of specific use cases. Plugin providers tend to be focused on their own features, not on how they will interact with other plugins. This means that at any point in time, you can never be sure that any two plugins will work properly together.
- Last but not least, once a company has been able to create a stable environment that embeds all of the plugins they need, there comes a time when they need to upgrade to the next version of that environment to benefit from bug fixes and new features. When this time comes, not only must a new environment be rebuilt and tested from scratch, but the migration from the old to the new environment needs to be worked: configuration files might have changed, data models and so forth.
This makes the adoption at SCALE of any extensible open source project difficult for most enterprises, as it carries a cost and a risk that they frequently can’t really manage with the resources they have internally.
The good news is that this problem is not specific to Jenkins and not new! This problem has been solved by other communities and companies. The most famous example in open source is Red Hat with Linux and its RHEL/Fedora, a model that has made Red Hat hugely successful since that transition in 2001.
The solution lies in the creation of an ENTERPRISE DISTRIBUTION. At Jenkins World, we announced our own enterprise distribution of Jenkins: CloudBees Jenkins Enterprise!
So, what is CloudBees Jenkins Enterprise? First CloudBees is curating the FOSS distribution to only select the most mature and enterprise-ready plugins. If there are things you shouldn’t touch, CloudBees is not going to propose it to you.
Then, that subset of plugins will go through extensive testing. Not just plugin testing, but overall use case testing, making sure that end-to-end scenarios and cross-plugin behaviors are working properly.
The fully-tested Jenkins core and certified plugins will be “bundled.” This leads to a package of Jenkins that’s fully tested and supported, providing peace of mind to the enterprise. This package can be used to certify third-party solutions, as well as your own Jenkins plugins. More importantly, CloudBees will ensure that the migration from one version to the next will be extremely stable and easy. When it comes to deploying Jenkins, we see huge value in BORING.
CloudBees is providing two different release trains depending on the expectations of your IT organization. It is important to note that any issue we find will be fixed first in open source - that is, all fixes will be provided to the FOSS community which, over time, will make Jenkins more stable for everybody.
The CloudBees Jenkins Enterprise distribution is available as of today, as part of the CloudBees Jenkins Platform 2.0 and our subscription, i.e. CloudBees Jenkins Platform 2 embeds CloudBees Jenkins Enterprise and adds our enterprise value with functionality such as the CloudBees Jenkins Operation Center, CloudBees Analytics, Role-based Access Control, High Availability and more. Any existing customer will automatically benefit from CloudBees Jenkins Enterprise as they upgrade to CloudBees Jenkins Platform 2.0, as part of their existing subscription.
Now, imagine the power of operating a Jenkins cluster at scale thanks to CloudBees Jenkins Platform - Private SaaS Edition (on top of AWS, for example), all while embedding the super stable and easy to upgrade CloudBees Jenkins Enterprise distribution! Be done with headaches, this is “peace of mind at scale”!
We might be providing CloudBees Jenkins Enterprise as a standalone distribution, outside of the CloudBees Jenkins Platform, in the near future, so stay tuned…
DevOps Express - Industry Alliance
Along with Sonatype, Atlassian, BlazeMeter, CA Technologies, Chef, DevOps Institute, GitHub, Infostretch, JFrog, Puppet, Sauce Labs, SOASTA and SonarSource, we formed an industry alliance called DevOps Express.
The goal of this initiative is to ease and accelerate the adoption of DevOps within organizations by providing improved product integration and cross-support among these products, as well as reference architectures, articles and knowledge base articles not specific to a single solution but, instead, covering the mixed usage of multiple of these products to achieve the best results.
The DevOps Essential vendors represent the typical tools you’ll see in 80% of DevOps reference architectures already out there: start with these solutions and you can’t go wrong. DevOps Ready partners are tightly integrated with multiple DevOps Essential products, while DevOps Enabled partners have expertise in DevOps Essential products and can act as change agents in your organization. I was impressed by the maturity all of these vendors have shown in agreeing to join forces for a common cause, even though several of them have competing products.
DevOps Express will be constantly evolving, so watch that space. In particular, we are likely to add a number of DevOps Ready and DevOps Enabled partners in the next few months.
With that being said, see you next year at Jenkins World 2017! :)
Sacha Labourey is the founder and CEO of CloudBees.