This chapter will cover all aspects of Blue Ocean, from the Dashboard, to viewing branches and results from individual Pipeline runs, to using the Visual Editor to modify Pipelines as code.
This chapter is intended for Jenkins users of all skill levels, but beginners may need to refer to some sections of "Using Jenkins" to understand some topics covered in this chapter.
If you are not yet familiar with Jenkins terminology and features, start with Getting Started with Jenkins.
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.
Sophisticated visualizations of continuous delivery (CD) Pipelines, allowing for fast and intuitive comprehension of pipeline’s status.
Pipeline editor makes 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.
There 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!
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’s 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’s 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 are becoming 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 that Jenkins needs to rise to meet.
Creating and visualising continuous delivery pipelines is something valuable for many Jenkins users and this is demonstrated in the 5+ plugins that the community has created to meet their needs. To us 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’s not just continuous delivery concepts but the tools that developers use every day – Github, Bitbucket, Slack, HipChat, Puppet or Docker. It’s about more than Jenkins – it’s the developer workflow that surrounds Jenkins that spans multiple tools.
New teams have little time for learning 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 will change and the mission of Blue Ocean will enable 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 that you have configured in your system. However, they won’t be able to benefit from any of the features built for Pipelines – for example, Pipeline visualization.
As Blue Ocean is designed to be extensible it will be possible for the community to extend it for other job types in the future.
The intention is that as Blue Ocean matures there will be less and less reasons for users to go back to the existing UI.
For example, in the first version we will mainly be targeting 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 new UI for some time. This means users will have to jump back to the classic UI for configuration of non-pipeline jobs.
There are likely going to be more examples of this and that’s why the classic UI will still be important in the long term.
Extensibility is a pretty core concept to Jenkins, so being able to extend the
Blue Ocean UI is important. Based on some research, we worked out a way to
<ExtensionPoint name=..> to be used in the markup of Blue Ocean,
leaving places for plugins to contribute to the UI (plugins can have their own
Blue Ocean extension points, just like they do today in Jenkins). Blue Ocean
itself (as it is so far) is implemented using these extension points.
Extensions are delivered by plugins, as normal, only if they wish to contribute