This chapter covers all aspects of Blue Ocean’s functionality, including how to:
get started with Blue Ocean - covers how to set up Blue Ocean in Jenkins and access the Blue Ocean interface,
create a new Pipeline project,
use Blue Ocean’s Dashboard,
use the Activity view - where you can access lists of your current and previously completed Pipeline/item runs, as well as your Pipeline project’s branches and any opened Pull Requests,
use the Pipeline run details view - where you can access details (i.e. the console output) for a particular Pipeline/item run, and
use the Pipeline Editor to modify Pipelines as code, which are committed to source control.
This chapter is intended for Jenkins users of all skill levels, but beginners may need to refer to some sections of the Pipeline chapter to understand some topics covered in this Blue Ocean chapter.
For an overview of content in the Jenkins User Handbook, see User Handbook overview.
Blue Ocean rethinks the user experience of Jenkins. Designed from the ground up for Jenkins Pipeline, but still compatible with freestyle jobs, Blue Ocean reduces clutter and increases clarity for every member of the team. Blue Ocean’s main features include:
Sophisticated visualizations of continuous delivery (CD) Pipelines, allowing for fast and intuitive comprehension of your Pipeline’s status.
Pipeline editor - makes the creation of Pipelines approachable by guiding the user through an intuitive and 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 and/or issues arise. Blue Ocean shows where in the pipeline attention is needed, facilitating exception handling and increasing productivity.
Native integration for branch and pull requests, enables maximum developer productivity when collaborating on code with others in GitHub and Bitbucket.
To start using Blue Ocean, see Getting started with Blue Ocean.
The world has moved on from developer tools that are purely functional to developer tools being part of a "developer experience". That is to say, 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 workflow that is beneficial for the developer - this is "developer experience".
Developer tools companies like Heroku, Atlassian, and Github have raised the bar for what is considered good developer experience, and developers are increasingly expecting exceptional design. In recent years, developers have become more rapidly attracted to tools that are not only functional but are designed to fit into their workflow seamlessly and are a joy to use. This shift represents a higher standard of design and user experience. Jenkins needs to rise to meet this higher standard.
Creating and visualising CD pipelines is something valuable for many Jenkins users and this is demonstrated in the 5+ plugins that the Jenkins community has created to meet their needs. This 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 CD concepts but the tools that developers use every day – Github, Bitbucket, Slack, HipChat, Puppet, or Docker. It is about more than Jenkins – it is the developer workflow surrounding Jenkins that spans multiple tools.
New teams have little time to learn how to assemble their own Jenkins experience – they want to improve their time to market by shipping better software faster. Assembling that ideal Jenkins experience is something we can work together as a community of Jenkins users and contributors to define. As time progresses, developers' expectations of good user experience changes and the mission of Blue Ocean enables the Jenkins project to respond.
The Jenkins community has poured its sweat and tears into building the most technically capable and extensible software automation tool in existence. Not doing anything to revolutionize the Jenkins developer experience today is just inviting someone else – in closed source – to do it.
The name Blue Ocean comes from the book Blue Ocean Strategy where instead of looking at strategic problems within a contested space, you look at problems in the larger uncontested 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".
Blue Ocean aims to deliver a great experience around Pipeline and be compatible with any freestyle jobs you already have configured on your Jenkins instance. However, you will not benefit from any of the features built for Pipelines – for example, Pipeline visualization.
As Blue Ocean is designed to be extensible, it is possible for the Jenkins community to extend Blue Ocean to support other job types in the future.
The intention is that as Blue Ocean matures, there will be fewer reasons for users to go back to the existing "classic UI". Read more about the classic UI in Getting started with Pipeline.
For example, early versions of Blue Ocean are mainly targeted at Pipeline jobs. You might be able to see your existing non-pipeline jobs in Blue Ocean but it might not be possible to configure them from the Blue Ocean UI for some time. This means users will have to jump back to the classic UI to configure items/projects/jobs other than Pipeline ones.
There are likely going to be more examples of this, which is why the classic UI will remain important in the long term.
Extensibility is a core feature of Jenkins. Therefore, being able to extend the
Blue Ocean UI is important. The
<ExtensionPoint name=..>
can be used in the markup of Blue Ocean, leaving
places for plugins to contribute to the Blue Ocean UI - i.e. plugins can have
their own Blue Ocean extension points, just like they can in the Jenkins classic
UI. So far, Blue Ocean itself is implemented using these extension points.
Extensions are delivered by plugins as usual. However, plugin developers will need to include some additional JavaScript to hook into Blue Ocean’s extension points and contribute to the Blue Ocean user experience.
Blue Ocean is built as a collection of Jenkins plugins itself. There is one key
difference - Blue Ocean provides both its own endpoint for HTTP requests and
delivers up HTML/JavaScript via a different path, without the existing Jenkins
UI markup/scripts. React.js and ES6 are used to deliver the JavaScript
components of Blue Ocean. Inspired by this excellent open-source project
(read more about this in the
Building Plugins for React Apps blog
post), an <ExtensionPoint>
pattern was established that allows extensions to
come from any Jenkins plugin (only with JavaScript) and should they fail to
load, have their failures isolated.
There are a few ways you can join the community:
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!
Please submit your feedback about this page through this quick form.
Alternatively, if you don't wish to complete the quick form, you can simply indicate if you found this page helpful?
See existing feedback here.