
Blue Ocean: a new user experience for Jenkins - Artemis2
https://jenkins.io/blog/2016/05/26/introducing-blue-ocean/
======
i386
My team and I designed Blue Ocean. We are really excited to get your feedback
and suggestions. Ask me anything :)

~~~
badlogic
First, let me say this looks amazing. Thanks for your work!

My biggest issue with Jenkins so far has been configuring complex jobs. The
single configuration page just gets unwiedly fast, and important settings are
often hidden by default.

Is there any work being done to make this easier as well?

~~~
i386
Wow thanks for the complement - I'm chuffed!

There's a trend to move job configuration to a Jenkinsfile that's stored in a
Git repository using Jenkins Pipeline. What used to be several jobs is now one
Pipeline job config defined using this DSL
[https://jenkins.io/solutions/pipeline/](https://jenkins.io/solutions/pipeline/)

Today the pipeline visualization only works with this way of making jobs.

Now we realize this isn't for everyone and we are thinking about how to let
users create Jenkins Pipelines through the UI without having to know the DSL
(just like freestyle). We are also looking at making Pipeline easier for
beginners too.

~~~
agentgt
It probably doesn't need reiterating but not having Travis like config is my
biggest issue with Jenkins as well.

While Pipeline looks awesome for sophisticated entities that have complex
workflow it seems overly powerful for most I think that just have a lot of
projects and configuration drift.

Pipeline unlike Travis Yaml is also not a declarative language. One of the
advantages of using a declarative markup language that respects comments and
spaces ( _cough_ XML) would be for the Web UI editor to intelligently edit the
configuration files while respecting order, formatting and comments (right now
I believe Jenkins XStreams so its just naive serialization).

~~~
jacques_chester
GoCD has XML configuration, if that's your kind of thing.

However, it turns out that tree-structured documents struggle to describe
build graphs.

------
Roritharr
Yes! This! A million times this!

I wished for a better Jenkins UI for so long I had given up hope. GitLab CI
looked enticing, but after putting so much work into building a workflow that
doesn't pollute my repos with environment specific data i'm right back at
Jenkins.

Thanks for this, this will make it so much clearer to our POs where we stand
without spending forever trying to push that info into Jira.

~~~
Artemis2
Have you looked at Concourse? I've only heard good things about it.

[https://concourse.ci](https://concourse.ci)

~~~
fuzzyninja
Concourse is an amazing project, but sadly is very if you are trying to build
around a docker type of workflow.

This[1] is for us a showstopper atm, so we are sticking to go.cd, although
Jenkins seems to be improving a lot lately.

[1]
[https://github.com/concourse/concourse/issues/324](https://github.com/concourse/concourse/issues/324)

~~~
Roritharr
Thats interesting, GitLabs recent focus on the Docker workflow was one thing
that irked me, since we won't be using Docker for the foreseeable future and
I'm missing quite a few features to replace Jenkins completely. Has concourse
good options for manual deployment?

~~~
jobvandervoort
Note that with GitLab CI, you can having anything run your build. It's just
that we typically use Docker as an example and use it ourselves most
intensely.

GitLab Runner (the 'slave' that runs your code), is just a Go binary, so it
runs on anything you can run a Go binary on, which is pretty close to all
major platforms.

Read more on Runner here:
[http://docs.gitlab.com/ce/ci/runners/README.html](http://docs.gitlab.com/ce/ci/runners/README.html)

And congrats to the Jenkins team! This looks amazing. A majority of our
customers uses Jenkins. I'm sure they'll be excited to update.

~~~
gearlles
My problem with Gitlab CI is that it's not as smart as Jenkins for Java
projects. Jenkins beautifully handles maven multi-module projects and knows
how to install the dependencies. All other CI-systems are available in Gitlab
CE, but Jenkins integration is only available on Gitlab EE. That's the only
reason my team doesn't use Gitlab as code repo.

------
serbrech
I like the concept or pipeline, and I like that the definition can be checked
in with the code, but :

* I don't like to couple the builds to a product

* Can I run the build locally? if something goes, how to I know if it's a bug in the pipeline script, the build server environment, or my code. I want reproducible builds.

~~~
tomfennelly
The popular/recommended pattern for using Jenkins pipeline is to abstract the
course grained build "steps" out to shell scripts and to use Jenkins pipeline
to orchestrate the whole build process by running these steps at the right
time (in parallel blocks etc), capturing human approval, making it all
"durable" (tolerant of restarts) etc etc. If you find yourself putting lots of
complex build logic into a pipeline script, then you're probably doing
something wrong.

Doing it this way reduces the tie to the "product" and also means that you can
easily test the individual self-contained steps outside of the product.

~~~
jacques_chester
I can confirm that this is the pattern that folks on Concourse have moved
towards as well.

When the CI system has high-level primitives for showing and organising build
graphs, it makes sense to surface those instead of burying them inside a
relatively opaque build tool.

------
jupp0r
I just wish they would have used this change to get rid of the weather icons
...

~~~
i386
Interesting - why do you think they should be removed? I purposely kept them
because they felt a very positive part of the Jenkins personality.

~~~
jupp0r
Just a matter of personal taste, they don't deliver the fast visual clues to
me that simple red and green elements do in other CI systems like bamboo. From
a distance, they look quite similar and that fails to give me a quick
overview. From my experience, they are a very polarizing piece of UI design :)

~~~
JorgeGT
I agree with you, and it's very easy to test. Print 15 mixed weather icons on
one sheet of paper and 15 red/green/orange circles in another. Show them to
test subjects for 1-2 seconds, and ask them to assess the situation. Now
repeat the test, but showing the sheets from two meters away. Our brain is
really good at color cues, and especially red = danger is deeply wired into
us!

~~~
crummy
Red = danger doesn't seem to be so widespread outside the western world:

[http://www.informationisbeautiful.net/visualizations/colours...](http://www.informationisbeautiful.net/visualizations/colours-
in-cultures/)

~~~
oblio
Possible, on the other hand traffic lights around the world have pretty much
standardized on:

\- green/blue: safe/go

\- (optional) yellow: caution

\- red: danger/stop

I don't know of any country where this convention is not in use.

~~~
i386
As I learnt looking into the indicators the accessibility of traffic lights
had a lot more to do with their vertical position than their colors. Can't use
solid green, yellow and red if we want them to be understood by people with
various forms of color blindness.

~~~
tylermac1
But you could make colorblind-friendly color schemes available through plugins
instead of making a slightly more confusing option default.

~~~
i386
Do you mean the weather icons? They are not the alternative to properly
designed status indicators. Take a look at this
[https://jenkins.io/images/post-images/blueocean/pr-
view.png](https://jenkins.io/images/post-images/blueocean/pr-view.png)

There's more about why and when we use them in my other comments.

------
franblas
Very good news. I love Jenkins but the interface is not very friendly and even
with some themes templates like this one [https://github.com/jenkins-contrib-
themes/jenkins-material-t...](https://github.com/jenkins-contrib-
themes/jenkins-material-theme) it's still hard to navigate and get right
informations. Definitively yes for this integration!

~~~
i386
Thanks for the kind words :)

------
truebosko
I love Jenkins, and it's incredibly important for our teams. The redesign
offering much stronger focus on the pipeline is key in helping us (and perhaps
many) teams move past the "Continuous build tool" phase and into the
"Continuous integration/deployment" tool we would love!

~~~
i386
Only possible due to the team working on Jenkins Pipeline and the plugin
developers who've started adopting it in their plugins.

Happy to hear you love Jenkins too :)

------
karterk
I have worked with many open and proprietary CI tools, and find GoCD to be the
best in this space right now. It supports both Continuous Integration and
Continuous Delivery. They also made it open source last year:

[https://www.go.cd/](https://www.go.cd/)

~~~
dominotw
do you work for thoughtworks?. Every single post about Jenkins ends up with
bunch of people from thoughtworks blindly shilling for their ci software.

Do you guys mind not doing that please?

~~~
orpheansodality
This seemed like quite the assumption, so I did some light digging. This
person definitely does not work for ThoughtWorks.

~~~
dominotw
I observed this pattern from previous jenkins posts.

But I did some digging after your comment and there it is

[http://www.indix.com/blog/life-at-indix/employee-
spotlight-k...](http://www.indix.com/blog/life-at-indix/employee-spotlight-
kishore-nallan/)

    
    
      What did you do before Indix?
      I was working at ThoughtWorks as a software engineer.

~~~
karterk
Well done I guess :) I worked briefly at ThoughtWorks, but definitely don't
have any vested interests. ThoughtWorks produces not-so-great products too
(like Mingle), but Go CI is definitely a great piece of software. And, I say
that as someone who also has used Jenkins a lot.

Also, it's now completely open source. I'm not even trying to advocate an
enterprise product.

------
luka-birsa
We're running both GitlabCI and Jenkins (different teams) inhouse. Gitlab
really upped their Game with the integrated Docker repo (we've adopted Docker
heavily) but it is lacking the plugin ecosystem of Jenkins.

Jenkins on the other hand just feels dated. The new ui is very welcome.

Looks like we're going to keep the dual approach for a while until things
crystallize further.

~~~
i386
Anything you think we could do to shorten the gap between the two?

~~~
luka-birsa
Integrate into Gitlab, so we do not require a secondary Service. :)

------
smartbit
I wonder how fast cloud bees will upgrade their new exam [0] based on version
1.625.2 of the Jenkins core? The exams where only available since last month
and already quite outdated since version 2.0 was introduced [1]. What
alternatives to exams exist to asses someone's knowledge and experience in
using, managing & maintaining an application?

[0]
[https://www.cloudbees.com/sites/default/files/cje_study_guid...](https://www.cloudbees.com/sites/default/files/cje_study_guide.pdf)

[1]
[https://news.ycombinator.com/item?id=11362058](https://news.ycombinator.com/item?id=11362058)
&
[https://news.ycombinator.com/item?id=11574487](https://news.ycombinator.com/item?id=11574487)

~~~
issc29
actually the Pipeline plugin was listed in the study guide, which was probably
the biggest change of 2.0 anyways (where it is now by default installed as a
Recommended Plugin) :-)

------
benbristow
Looks much better!

I've never used Jenkins for my own projects but I've used it before when
Minecraft's 'bukkit' framework used to use it and it's a horrible piece of web
software to navigate.

~~~
phit_
It's still being used by the successor of bukkit ;)

[https://hub.spigotmc.org/jenkins/view/All/](https://hub.spigotmc.org/jenkins/view/All/)

------
rcarmo
This is excellent news. Jenkins is often the hardest thing for people to get
to grips with in a CI pipeline solely because of the UI/UX, and I, for one,
welcome our redesigned build butlers... :)

------
hjgilmore
Looks really great! Much more modern and visually clean.

~~~
i386
Thank you!

------
stuaxo
About time! This is great.

------
joneholland
I've yet to find a build system that is better than TeamCity.

~~~
ajmurmann
It's interesting how little attention it gets. I believe it's mainly because
it costs money which is a silly reason. I've worked with many clients who
spent hundreds of thousands of dollars on getting software built. Yet only one
client ever went fire Team City. No one else even considered it because it
costs a minute amount of money. To me the option of selecting a snippet of
code in the editor and running it on Ci is worth a lot.

------
jacques_chester
This is a fantastic upgrade to Jenkins, well done.

Sincerely,

A Concourse Fan.

~~~
i386
Thanks jacques! Keen to know if there are any gaps between concourse and
Jenkins that we could be doing a better job of filling.

Edit: oh right you work for Pivitol ;)

~~~
jacques_chester
I do, first in Labs and now in Cloud Foundry.

On the Labs side lots of our clients are still committed to Jenkins, so
improvements like these are very welcome.

------
zxcvcxz
CLASSIC HN (2 Months ago)

[https://news.ycombinator.com/item?id=11362058](https://news.ycombinator.com/item?id=11362058)

>Jenkins 2.0 Beta

Almost every top level comment is very negative.

I just think the discussion now vs the discussion then is worth noting. People
seem much more positive about jenkins just in the last few weeks.

Recently since it was integrated into Azure those negative comments have
started to get downvoted, in favor of positive ones.

[https://news.ycombinator.com/item?id=11737374](https://news.ycombinator.com/item?id=11737374)

Very interesting. I figure this is just the more "corporate culture" here on
HN.

