Blue Ocean

This chapter covers all aspects of Blue Ocean’s functionality, including how to:

get started with Blue Ocean, which covers how to set up Blue Ocean in Jenkins and access the Blue Ocean interface.
create a new Pipeline project in Blue Ocean.
use Blue Ocean’s dashboard.
use the Activity view, where you can access your current and historic run data, your Pipeline’s branches, and any open pull requests.
use the Pipeline run details view to access details such as console output, for a particular Pipeline or item run.
use the Pipeline editor to modify Pipelines as code, which you can then commit to source control.

This chapter is intended for Jenkins users of all skill levels, but beginners may need to refer to the Pipeline chapter to understand some topics covered here.

For an overview of content in the Jenkins User Handbook, refer to user handbook overview.

Unresolved include directive in modules/blueocean/pages/index.adoc - include::doc/book/blueocean/_blue-ocean-status.adoc[]

What is Blue Ocean?

Blue Ocean rethinks the user experience of Jenkins. Designed from the ground up for Jenkins Pipeline, Blue Ocean reduces clutter and increases clarity for all users. Blue Ocean’s main features include:

Sophisticated visualization of continuous delivery (CD) Pipelines, allowing for fast and intuitive comprehension of your Pipeline’s status.
Pipeline editor makes the creation of Pipelines more approachable, by guiding the user through a visual process to create a Pipeline.
Personalization to suit the role-based needs of each member of the team.
Pinpoint precision when intervention is needed or issues arise. Blue Ocean shows where attention is needed, facilitating exception handling and increasing productivity.
Native integration for branches and pull requests, which enables maximum developer productivity when collaborating on code in GitHub and Bitbucket.

To start using Blue Ocean, refer to getting started with Blue Ocean.

Frequently asked questions

Why does Blue Ocean exist?

The DevOps world has transitioned from developer tools that are purely functional, to developer tools being part of a "developer experience." It is no longer about a single tool, but the many tools developers use throughout the day, and how they work together to achieve a better workflow for the developer.

Developer tool companies like Heroku, Atlassian, and Github have raised the bar for what is considered a good developer experience. In recent years, developers have become more attracted to tools that are not only functional, but designed to fit into their existing workflow seamlessly. This shift represents a higher standard for design and function, where developers are expecting an exceptional user experience. Jenkins needs to rise to meet this higher standard.

Creating and visualising continuous delivery Pipelines is something valuable for many Jenkins users. This is demonstrated in the plugins that the Jenkins community has created to meet their needs. This also indicates a need to revisit how Jenkins currently expresses these concepts, and consider delivery pipelines as a central theme to the Jenkins user experience.

It is not just continuous delivery concepts, but the tools that developers use every day such as Github, Bitbucket, Slack, Puppet, or Docker. It is about more than Jenkins, as it includes the developer workflow surrounding Jenkins, which is comprised of multiple tools.

New teams can encounter challenges when learning how to assemble their own Jenkins experience. However, the goal to improve their time to market by shipping better software more consistently is the same. Assembling the ideal Jenkins experience is something we, as a community of Jenkins users and contributors, can work together to define. As time progresses, developers' expectations of a good user experience change, and the Jenkins project needs to be receptive to these expectations.

The Jenkins community has worked constantly to build the most technically capable and extensible software automation tool in existence. Not revolutionizing the Jenkins developer experience today could mean that a closed source option attempts to capitalize on this in the future.

Where is the name from?

The name Blue Ocean comes from the book Blue Ocean Strategy. This strategy involves looking at problems in the larger uncontested space, instead of strategic problems within a contested space. To put this more simply, consider this quote from ice hockey legend Wayne Gretzky: "Skate to where the puck is going to be, not where it has been."

Does Blue Ocean support freestyle jobs?

Blue Ocean aims to deliver a great experience around Pipeline and compatibility with any freestyle jobs you already have configured in your Jenkins instance. However, you will not benefit from the features built for Pipelines, for example Pipeline visualization.

Blue Ocean was designed to be extensible, so that the Jenkins community could extend Blue Ocean functionality. While there will not be any further functionalities added to Blue Ocean, it still provides Pipeline visualization and other features that users find valuable.

What does this mean for the Jenkins classic UI?

The intention was originally as Blue Ocean matured, there would be fewer reasons for users to go back to the existing classic UI. Refer to the getting started with Pipeline page for more information about the classic UI. Blue Ocean focuses its improvements on Pipeline jobs.

You might see your existing non-pipeline jobs in Blue Ocean, but configuration may not be possible from the Blue Ocean UI. This means users will have to jump back to the classic UI to configure items or jobs other than Pipeline ones.

The classic UI will remain important in the long term, as Blue Ocean is not a replacement for Jenkins classic UI, but a tool to use with Jenkins.

What does this mean for my plugins?

Extensibility is a core feature of Jenkins and being able to extend the Blue Ocean UI is equally important. The <ExtensionPoint name=..> can be used in the markup of Blue Ocean, leaving places for plugins to contribute to the UI. This means plugins can have their own Blue Ocean extension points, just like they can in the Jenkins classic UI. Blue Ocean itself is implemented using these extension points.

Extensions are delivered by plugins as usual. Plugins must include some additional JavaScript to connect to Blue Ocean’s extension points. Developers that have contributed to the Blue Ocean user experience will have added this JavaScript accordingly.

What technologies are currently in use?

Blue Ocean is built as a collection of Jenkins plugins. The key difference is that Blue Ocean provides both its own endpoint for HTTP requests, and it delivers HTML/JavaScript via a different path, without using the existing Jenkins UI markup or scripts. React.js and ES6 are used to deliver the JavaScript components of Blue Ocean. Inspired by this excellent open-source project, which you can refer to in the building plugins for React apps blog post, an <ExtensionPoint> pattern was established that allows extensions to come from any Jenkins plugin with JavaScript. If the extensions fail to load, their failures are isolated.

Where can I find the source code?

The source code can be found on Github:

Join the Blue Ocean community

There are a few ways you can join the community:

Chat with the community and development team on Gitter
Request features or report bugs against the blueocean-plugin component in JIRA.
Subscribe and ask questions on the Jenkins Users mailing list.
Developer? We’ve labeled a few issues that are great for anyone wanting to get started developing Blue Ocean. Don’t forget to drop by the Gitter chat and introduce yourself!