The Rise of the Jenkins CI Butler - by Jonathan McAllister

Author of Mastering Jenkins [Packt Publishing] []

Kohsuke Kowaguchi designed and developed the Hudson automation system from the ground up while he was working at Oracle in 2006.  Primitive inceptions of the Jenkins platform (then known as Hudson) simply aimed to support continuous integration practices and offer a viable replacement for CruiseControl, which was the popular CI solution at the time. The Hudson platform was initially very Java centric with tight coupling to Maven and Java development paradigms. Little did Kohsuke know that his internal Hudson tool would catapult in notoriety, change names (into Jenkins), spin off to become CloudBees and eventually become the most popular modern Continuous Integration and automation orchestration platform in use in modern history.

The current Jenkins platform provides an easily consumable unified user interface coupled with a highly scalable distributed automation solution that can build, test, and automate across diverse technologies. Its vast plugin ecosystem allows it to be extended to integrate tightly with other technologies and dynamically expand based on user needs and developer creativity. But this was not always the case. During it's early years the Hudson user interface was not the cleanest and the tool was heavily Java focused. Aside from the Java features the original iterations of Hudson were sub par in comparison to CruiseControl. The major positive feature it did have was a unique extension paradigm.

The Hudson extension and plugin paradigm provided a path for Java developers to override classes and methods within the Jenkins subsystems and extend its capabilities to integrate into organisations varying development patterns and technology stacks. This paved the way for numerous extensions and core improvements. Most of the popular Jenkins core features we see today were initially plugins that solved a specific development need or engineering pattern. This includes popular Jenkins plugins such as the SVN module, GIT, Master and Slave Nodes, Dashboards and Views and many more.

The open-source community slowly but surly began adopting Hudson (now named Jenkins) and began extending the features and capabilities of the platform. What started as a small trickle of developers and Hudson enthusiasts working together to create plugins and extend the Jenkins core subsystems eventually grew into a wide scaled international development effort. Today there are numerous development initiatives and countless highly scalable plugins that provide support for big names in automation such as jFrog, Jira, Amazon and others.

This wide scale open-source engineering effort into the Jenkins platform and plugins continues to fuel Jenkins innovations and helps further its popularity.  Within the Jenkins development community there are hundreds of software professionals and enthusiasts all drawing on different skill sets and diverse technology backgrounds. These individuals are operating as a community and cooperating to extend and engineer a software solution that makes their lives easier. While there have been a number of competitor products that have evolved over the years (mostly as a clone of Jenkins) none have the diverse innovative support of a vast and competent open-source community. For this reason they will always end-up behind the eight ball of innovation.


Popular posts from this blog

Colour formatting - Jenkins Console

Manage Docker images on local disk

How to migrate Parent pom from maven to gradle