
New UX for Jenkins: Blue Ocean 1.0 - i386
https://jenkins.io/blog/2017/04/05/say-hello-blueocean-1-0/#say-hello-to-blue-ocean-1-0
======
i386
I am the leader of the Blue Ocean project - feel free to ask me anything :)

This is just the first release of what we hope to be many more in the coming
weeks and months. The surface area of Jenkins is _huge_ and we may not have
all your use-cases covered - please send us your feedback and feature requests
by signing up to [https://issues.jenkins-ci.org](https://issues.jenkins-
ci.org) and submit a new issue under the 'blueocean-plugin' component.

A few things that are coming up soon:

\- Support for Github Enterprise

\- Full read/write from the Visual Pipeline Editor for any Git repository
(Github is supported today!)

\- Visual Pipeline Editor feature parity with Declarative Pipeline

~~~
crymer11
How can we have multiple Jenkinsfiles in a single branch?

We want to run one job to build things, then after we deploy, we want to
trigger another job that runs a bunch of integration, performance, etc. tests
against the new code.

~~~
jsmeaton
I was dealing with this just yesterday funny enough. We didn't really like the
idea of using `load()` to bring in a new file. I'll prefix the rest by saying
we haven't actually implemented this yet, so YMMV. Our goal was to have a
separate deploy pipeline that wasn't dependent on the test step (for various
reasons I won't go into).

We decided on creating a new job of type pipeline, and pointing it at a script
named `Jenkinsfile.deploy`. It has a few parameters, namely `BRANCH`, that can
be manually set, or passed in from another job. We can then move our
deployment steps from the main Jenkinsfile into this new one, and still
version control the lot.

Major caveat is that the deploy step is not compatible with organisation scans
(multibranch/pr), but that's fine for our use case. We usually want to trigger
our builds manually based on the branch.

~~~
Chico75
Sounds like you would be better off putting the logic in separate function of
a global library that you can then call in different stages for different
conditions: [https://jenkins.io/doc/book/pipeline/shared-
libraries/](https://jenkins.io/doc/book/pipeline/shared-libraries/)

~~~
jsmeaton
For some things, yes, and we are planning to do this. Deployment is different
between our projects though, so we'd prefer our deployment method to live
within the repo beside other build steps.

------
hunvreus
Funny to see that Jenkins is starting to address a lot of the issues that led
us to creating Pipelines [1].

I still think Jenkins is a pretty huge beast to run and configure. We're
trying to keep things light (install in a couple minutes with `pip install`)
and intuitive (simple YAML files to describe pipelines).

We're writing a post about our take on automation/continuous delivery and how
this impacted some of our design decisions for Pipelines. I'll probably dive a
bit more in this version of Blue Ocean before so.

[1]:
[https://github.com/Wiredcraft/pipelines](https://github.com/Wiredcraft/pipelines)

------
nathan_f77
This looks amazing. I haven't used Jenkins for a long time, mainly because I
remember the UI being ugly and clunky. So this is really nice.

I haven't set up an in-house CI server for a long time, and if ever needed one
again, I was planning to evaluate GitLab CI. Otherwise I just use CircleCI,
and TravisCI for open source.

But with this new UX, I might give Jenkins another shot.

------
flukus
It looks nice, but it looks like jenkins is doing way to much and locking you
into using it.

IMO a build server should only be managing it's triggers (time, checkin) and
then calling the build script (make or whatever) with the correct parameters
for that build configuration. Instead it seems to be trying to take the role
of both.

~~~
kosinus
I don't know. We tried looking for alternatives when we were a bit down in the
gutter with our Jenkins setup, but were even more disappointed with the other
options.

Instead, we now use Jenkinsfiles everywhere, or pipeline scripts where we have
scheduled stuff. That's working well enough so far for our small team.

The things Jenkins provides can be difficult to find elsewhere. For example,
we spin up an EC2 slave for most builds, but sometimes need to then take the
result and deploy it from another (static) node because of network
restrictions. Stuff like git access, the credential store, moving stuff
between nodes just works everywhere.

~~~
flukus
Do you have a build script (makefile or something else)? IE, can you perform a
build from you're machine?

~~~
kosinus
Most of our builds are 'basically' Node.js / npm or PHP / composer, so
reasonably contained build processes. It looks simple on the surface, but once
you start running CI for a while you notice all the dependencies on the
environment. Versions installed of PHP, Composer, Node.js, MySQL / MariaDB,
Java, Ant all tripped us at some point. (Not to mention we develop on Mac,
deploy on Linux.)

Instead, we now have a very basic Ubuntu-based AMI with Docker installed, and
otherwise stopped depending on the host environment as much as possible.
Jenkins spins up an EC2 instance when needed, and shuts it down again after
some period of inactivity. 95% of our pipeline scripts do work inside a
container.

------
jzila
It's great and beautiful. However, it isn't yet as powerful as Jenkins
Classic. So if you've been using Jenkins for a while, there's a good chance
that Blue Ocean doesn't have the power/granularity you'll need.

It also switches your default GitHub links to Blue Ocean. If you only want to
try it out, you'll have to tell your users to switch their Notification URL
back to Jenkins Classic in their user configuration page. (If there's a way to
do this for everyone, I'd love to hear it.)

~~~
moondev
Can you elaborate? It's just a plugin at that lives at /blue. In my experience
it doesn't remove functionality at all. You can still use "normal" Jenkins
just the same.

~~~
gtirloni
Exactly what I was thinking. When I access Jenkins, after having installed
Blue Ocean, I'm still greeted with the traditional UI and the "Open Blue
Ocean" button.

I do see the option in my user settings page but I don't understand what it's
for. What is this "notifications URL"?

~~~
i386
Jenkins issues all kinds of links to itself via email, Slack, HipChat and
Github to refer to runs of pipelines or the homepage of jobs. When we do this,
we send you to a well known URL that will redirect you to your preferred UI -
Blue Ocean or "Classic" Jenkins. Thats what this preference controls. I hope
this helps!

~~~
gtirloni
That makes sense, thank you!

------
trumbitta2
As a long-time Jenkins user (since the Hudson days), I'd like to comment in my
first language - sardinian:

Minca, gi' fiada ora.

Then, in english: Wow! About time! Kudos to the whole team!

------
petetnt
As someone who has to deal with Jenkins a lot and extensively uses Pipelines
with Jenkins and has used BO since early betas, I really really like Blue
Ocean.

The UX and UI is by far my least favorite thing in Jenkins, so for basic usage
Blue Ocean is miles ahead, even though it doesn't nearly have the feature
parity of the old UI. That said, I cannot wait for Blue Ocean to grow and get
better.

~~~
arghwhat
We have been using Blue Ocean for a few months - We have to use the Classic UI
as Blue Ocean is a buggy mess... It doesn't handle branches with slashes in
them (reload or try a direct link), it handles console output very poorly with
some attempt at detecting when users don't want autoscroll, UI fails often and
require browser refresh for it to update data or for UI elements to start
working again, ...

Uuuuuugh. It _looks_ nice, but all my colleagues whine about how poorly it
works. Then comes all the problems caused by regular Jenkins multibranch
pipeline limitations...

------
sunjain
Congrats! We recently migrated from Anthill to Jenkins, and went with
Pipelines instead of freestyle jobs, and what a difference it has made in
terms of being able to see/manage your build/deployment as code. We have been
using Blue Ocean in Beta mode (we use Cloudbees version). Is it out of beta
for Cloudbees version also?

~~~
i386
It will be available from our update center soon and the next month or so via
our verified program. The CloudBees Jenkins Enterprise team are hard at work
on this as we speak :)

------
bryanlarsen
Blue Ocean is cool, but I think declarative pipeline is even cooler, and it
also recently hit 1.0: [https://jenkins.io/blog/2017/02/03/declarative-
pipeline-ga/](https://jenkins.io/blog/2017/02/03/declarative-pipeline-ga/)

~~~
i386
Glad to hear! Declarative and Blue Ocean have been designed to be used hand-
in-hand.

------
chinchang
Good progress. But still lot of bugs to be used in production. Its way too
slow and dashboard doesn't opens at a lot of time due to bulky/truncated
response.

------
debacle
As a TFS user, I miss Jenkins so much. There's so much you can do in the
Jenkins pipeline with 2-3 plugins that is nearly impossible, or needlessly
difficult, in TFS.

~~~
i386
come back :)

~~~
debacle
Pushing very hard for it internally.

~~~
hrmpw
Are there any features that could push it over the top?

~~~
debacle
If you stuck a Microsoft logo on it...

:-/

------
andrewingram
Visually looks _much_ better than the earlier versions of Blue Ocean that I
saw (which left me a little underwhelmed), nice work!

~~~
i386
Ahh that would be the great work of our designer Brody Maclean
([https://twitter.com/brodymaclean](https://twitter.com/brodymaclean))! Ill
pass on the complement and thank you!

------
sudeepj
We are using the pipeline-as-code (i.e. Jenkinsfile). However, the new
pipeline plugin does not allow diamond shaped dependencies (e.g
[https://i.stack.imgur.com/iQFWT.png](https://i.stack.imgur.com/iQFWT.png))

Jenkins does allow 'parallel' jobs but that is the same thing we want.

~~~
mattbroekhuis
Aren't environment specific builds generally discouraged? I'd rather have the
same binary through each layer. Control behavior via environment variables or
prop files

------
stuff4ben
Is this compatible with all 2.x versions of Jenkins? Or should we be on a
specific version or higher?

~~~
i386
We support Jenkins 2.7.1 (the first 2.x LTS) and above. However, there have
been quite a few security advisories for plugins/Jenkins in the meantime and
I'd recommend you upgrade often (its pretty painless these days!)

------
kevinburke
Congrats to the Jenkins team!

~~~
i386
Thanks for your support Kevin!

------
euyyn
This is both gorgeous and well needed!

~~~
i386
Wow... thanks for the kind complement :)

------
aplex
New UI is a step forward, but many people don't look at it that often. They
use CatLight or similar tools that show them build status right on the
desktop.

~~~
taspeotis
Are you affiliated with CatLight?
[https://news.ycombinator.com/submitted?id=aplex](https://news.ycombinator.com/submitted?id=aplex)

