
Blue Ocean - bauerpl
https://jenkins.io/projects/blueocean/
======
tzaman
Seeing how much people recommend other solutions, I've actually moved from
Travis to Jenkins, and never looked back.

Yes, Jenkins has its issues (crappy UX, poor/awkward docs), but where it
shines is the fact it's self-hosted, so I can SSH onto the instance to debug a
failing build or replay it with a modified Jenkinsfile on the fly.

I'm quite proud of the current setup we have; We're hosting our app with
Google's Container Engine (Kubernetes), so what we're doing is on every build
Jenkins creates a slave agent within the same cluster (just different node
pool) as the production, so the environment in which test containers are ran
is identical to production, and what's more it actually talks to the same
Kubernetes master, which means I can, for example, test our Nginx Reverse
proxy with real backend endpoints and real certificates (that are mounted
through glusterfs).

~~~
knocte
IMO moving from Travis to Jenkins seems like a very disruptive change.

As for me, I had used Travis just a bit, and same for Jenkins, and didn't like
any of those options very much.

So when my team needed to setup a CI solution, we ended up using GitLab CI,
and it brings the best of both worlds:

\- Free service version if you use the GitLab.com deployment (granted,
gitlab.com is a bit slow because it's the new thing and everybody is using it
now), like travis.

\- Open source so that you can host it yourself in the future if you need to,
like Jenkins.

\- Easy to use and configure, like Travis.

\- Free service for private repos in GitLab.com (neither Travis nor any
Jenkins-service provider offer this, AFAIK).

I plan to never look back.

~~~
dom0
Honestly my experience is that SaaS / hosted CI is just generally annoying due
to constant stability and performance (both transient and in general, eg.
caching in Travis) issues.

Self-hosted CI on the other hand requires a lot of resources, especially when
you're not only testing Linux or BSD, but proprietary OSes (OSX, Windows,
although the latter at least has the Edge images that work everywhere).

Ultimately I feel like the use of CI in many open source projects isn't very
high due to constant annoyances and difficulty debugging the CI environment.

~~~
aeharding
Just a note - you can host your own CI node (runner) for project(s) on
gitlab.com. It's super simple to setup, too.

[https://docs.gitlab.com/runner/install/linux-
repository.html](https://docs.gitlab.com/runner/install/linux-repository.html)

~~~
drdaeman
This doesn't solve issues in runner-to-base comms. I had tried this kind of
setup relatively recently, and almost every 10-15th build had failed for me
because GitLab wasn't healthy (502 from Docker registry or problems
up/downloading artifacts between stages, etc.)

Fully self-hosted looks like the only sane way. Harder to set up, but at least
one can check the whole chain that way.

~~~
sytse
Sorry about GitLab.com having performance problems. Self hosted is indeed the
only way to work around it in the short term. I hope you can set it up
quickly. Please use the Omnibus packages that should install in a few minutes
[https://about.gitlab.com/installation/](https://about.gitlab.com/installation/)

------
i386
Hey there,

I am the community leader for Jenkins Blue Ocean and Product Manager for the
project at CloudBees. It's really great to see Jenkins users getting excited
about Blue Ocean!

Please let us know if there are any missing features that are blocking your
team from adopting Blue Ocean. We know there are some gaps between Jenkins
Classic and Blue Ocean and while we have some good ideas, we are relying on
your feedback to help us prioritise what to work on next.

If you've got any questions feel free to drop a comment here and Ill do my
best to answer them or join our Gitter community [1]

Thanks, James

[1] [https://gitter.im/jenkinsci/blueocean-
plugin](https://gitter.im/jenkinsci/blueocean-plugin)

~~~
scrollaway
Some pieces of feedback on Blue Ocean, which we've used on and off but haven't
been able to switch to:

\- The console interface needs work. The "click on text to link to it" thing
is making it very hard to select stuff. Line numbers on the left are useless
for a log, timestamps would be _much_ more useful. (Also please add ANSI color
support!)

\- Artifacts view is awkwardly empty. Instead of the artifact name being a
link, there's a separate download button.

\- I have a GH project linked to my various build-master jobs. Why is the
"commit" column empty?

\- Build -> Changes -> The commit column shows the commit; with Github
integration it could use a link to the actual commit on GH itself.

\- "Duration: A few seconds" is not helpful for builds <1 min long. If your
build takes 4 seconds average and one build takes 33 seconds, that should be
immediately visible.

\- I can't immediately see which builds were recently triggered and when from
the main view. Regression from the legacy main view.

\- Bug: "Display the log in a new window" -> the log is being sent as
text/html instead of text/plain

Thanks for your work.

~~~
i386
You're welcome and thanks so much for this feedback. There's a lot here for us
to cover - would you mind if we could have a short chat over email or even a
Google Hangout? My email is jdumay@cloudbees.com

~~~
scrollaway
Sure, sent you an email.

------
agibsonccc
Esoteric use case from someone in AI: Jenkins is the only CI we've been able
to use even as an open source project due to needing gpus. CI and things like
special hardware is a "semi-common" edge case and a big reason to have
something self hosted.

Referencing other comments here: We've also found periodic builds and
arbitrary jobs to be a must as well.

A lot of providers out there support most of the basic stuff out of the box,
and I understand why they won't go after an edge case like that. It's great to
see improvements in the UX on the horizon, that has been our biggest pain
point.

If anyone's curious, our CI setup involves a multi OS cluster:
Mac,windows,linux for power,linux x86 (with cross building for android) with 1
linux master running a gpu for gpu tests.

~~~
sytse
In GitLab CI you can use any machine for a build as long a you can install
GitLab Runner on it. We kept the design of that simple with few dependencies
and it is written in Go.

~~~
agibsonccc
We just don't use gitlab heavily enough yet :). We are mainly a JVM shop so
the bias jenkins has for things like maven and what not out of the box is
pretty appealing. I've been watching your integration play :). Maybe 1 day.

~~~
sytse
Thanks! I agree that great Maven support is key. We're working to integrate a
package repository in [https://gitlab.com/gitlab-org/gitlab-
ce/issues/19095](https://gitlab.com/gitlab-org/gitlab-ce/issues/19095)

------
kodfodrasz
They should rethink the deployment model instead.

You cannot provision jenkins unattended without 3rd party hacks and
undocumented features. Until this is fixed I recommend avoiding it, as you'll
get pet servers. This is totally retrograde to the devops mindset. Now why
should I not use that mindset if that proves to be productive at other parts
of work?

~~~
kohsuke
If I understand you correctly, you are talking about managing Jenkins
configuration as code. For that, see

* configure jobs as code ([https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin](https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin))

* system configuration as code ([https://issues.jenkins-ci.org/browse/JENKINS-31094](https://issues.jenkins-ci.org/browse/JENKINS-31094)) and its current prototype ([https://github.com/jenkinsci/system-config-dsl-plugin](https://github.com/jenkinsci/system-config-dsl-plugin))

* bypassing setup wizard ([https://issues.jenkins-ci.org/browse/JENKINS-34035](https://issues.jenkins-ci.org/browse/JENKINS-34035))

There are also puppet modules, Chef cookbooks, and etc that a lot of people
use. Some of those are maintained by people who are also in the Jenkins
community, so I don't consider them "3rd party hacks" if you are referring to
those.

~~~
mtalantikite
And this is one of the major shortfalls of the Jenkins mindset. Everything is
a plugin and an afterthought from the main design of the system. Something as
crucial as configuring the system should be a top design priority, not shoved
into a plugin 5 years after the launch of the project.

So, great, there is a plugin to deal with configuration. How do I bootstrap my
infrastructure? If it's a plugin, it sounds like I need to install that in an
already running Jenkins setup, no? Currently, both this and the bypassing
setup wizard seem like hacks to me.

Configuration of a critical piece of your infrastructure should never be a
hack.

~~~
oblio
Jenkins is more than 10 years old :)

Regarding plugins, you can just plop them in the plugins folder an start
Jenkins.

~~~
mtalantikite
Totally, I just was considering the fork point from Hudson back about 5 years
ago. As an independent project they've had 5 years to think about design and
it seems like no one really has cared.

I still think core functionality shouldn't be put into plugins in any software
system. You should have sane functionality and defaults right out of the gate.
Plugins or modifications are for extending the base use case. Configuring your
software to me is a base use case.

~~~
oblio
Jenkins is incredibly popular and has a huge community. Dropping backwards
compatibility would be very harmful.

What they did instead was to move most of the core functionality in plugins
maintained by the core contributors, so they're plugins all but in name. I.e.
they can be installed separately, uninstalled, etc., but about 100 plugins are
supposed to be used together and you see them frequently in examples, docs,
etc.

~~~
mtalantikite
Plenty of systems can and do evolve their community forward with it. The
sentiment of backwards compatibility at all costs is the same that leads you
down the road of having to support IE 7. No one is saying play fast and loose
with core functionality, but do it responsibly and with community input.

That "about 100 plugins are supposed to be used together" is indicative of bad
design to me.

They really should be taking a look at modern systems like Concourse CI to see
what they can do to improve.

------
djsumdog
Wow, this looks amazing. I really want to try this out.

On my current contract, we've been moving away from Jenkins and towards Gitlab
CI. I still work on an opensource project that uses Jenkins to build. The
screenshots show a really good pipeline layout. It seems like it's similar in
power to Gitlab CI, but also looks like it has way better visual
representations and UI.

I'm glad the Jenkins team is still moving forward and developing plugins/tools
like this.

~~~
nubela
Why Gitlab CI? What makes it better than Jenkins?

~~~
petepete
I think the consensus is that Jenkins offers more power and flexibility at the
cost being more complicated to set up. GitLab CI is easier to get up and
running with and superbly integrated with GitLab (as one would hope).

~~~
sytse
We also want to offer all the power and flexibility of Jenkins but we still
have some work ahead of us. The idea is to add those features to GitLab itself
and not to plugins. Plugins tend to cause brittleness
[https://news.ycombinator.com/item?id=13218391](https://news.ycombinator.com/item?id=13218391)
We want to make sure that you can upgrade GitLab without having to worry about
things breaking.

For the current GitLab release (8.15, December 22) we planned the following CI
improvements (not all will be ready, some will slip to Jan 22):

Pipelines for Merge Requests [https://gitlab.com/gitlab-org/gitlab-
ce/issues/23902](https://gitlab.com/gitlab-org/gitlab-ce/issues/23902)

Remove Builds tab from Merge Requests and Commits [https://gitlab.com/gitlab-
org/gitlab-ce/issues/23638](https://gitlab.com/gitlab-org/gitlab-
ce/issues/23638)

Make pipeline graph nodes bigger and responsive [https://gitlab.com/gitlab-
org/gitlab-ce/issues/22088](https://gitlab.com/gitlab-org/gitlab-
ce/issues/22088)

Direct link from pipeline list to builds [https://gitlab.com/gitlab-
org/gitlab-ce/issues/19703](https://gitlab.com/gitlab-org/gitlab-
ce/issues/19703)

Part of the issues in Improve reliability of CI/CD [https://gitlab.com/gitlab-
org/gitlab-ce/issues/24361](https://gitlab.com/gitlab-org/gitlab-
ce/issues/24361)

~~~
supergreg
Does these pipelines thing imply moving away from Sidekiq? At work that's our
biggest issue with Gitlab. Sidekiq dies all the time and Gitlab has to be
restarted for merge requests to work again.

~~~
sytse
These pipelines do not imply moving away from Sidekiq. Have you tried using
the Omnibus package? It contains logic to make sure restarting Sidekiq is
automatic. How much memory does GitLab have and how many users?

~~~
supergreg
Only 5 users. We are using Gitlab from Bitnami which I'm sure is using the
Omnibus package. Maybe they configure it differently. I'll check, thanks.

~~~
sytse
The Bitnami package indeed doesn't include any of this. I strongly recommend
switching to Omnibus.

From
[https://about.gitlab.com/installation/](https://about.gitlab.com/installation/)
"One-click installers are frequently out of date and might not contain our
Omnibus packages. An example of this are the Bitnami packages in the past
couldn't be updated and are now much harder to update than the Omnibus
packages. We advise to not use one-click installers but instead start an
vanilla Ubuntu instance and use the recommended Omnibus package installation.
This is almost as quick as a one-click install and you're sure of the latest
version and easy upgrades."

------
kuboris
I just want to mention that I loved the idea of BlueOcean at the begining. It
looks sleak an works well with pipeline. However, for us it's unusable in
production setting. I know that it's still in beta, but as one example it
doesn't support parameters. When user starts a job through BlueOcean it will
fail.(Officialy they don't plan to implement it any time soon as I found out)
That means It stays disabled in our jenkins. PS: For now its just a
presentation tool for management :)

~~~
deng
Well, that's Jenkins in a nutshell. You usually need to extend Jenkins with
lots of plugins because they provide functionality that should have been in
core in the first place. Then you realize that those plugins are not properly
sandboxed and often do not work well together (especially with multi-
configuration builds), not to speak of how updating Jenkins becomes a
nightmare with plugins breaking left and right because of some internal API
changes which are not yet properly handled by some plugin.

~~~
jacques_chester
In fairness, Jenkins did not have the benefit of hindsight. Plugins were the
this-is-how-you-support-extension architectural style of the period (see also
Wordpress, Eclipse).

I've been working on a Concourse tutorial video series. One of the points I've
made is that plugins are unsafe to compose. They need to know too much about
each other to prevent interference.

Concourse instead composes on resources, which all have an identical interface
(check, get, put). You can pretty much use any resource with any other
resource if they achieve your purpose.

We're still calling Concourse "CI/CD", but folk are now jokingly referring to
"Continuous Everything" at Pivotal. Because it really is becoming the first
tool for everything. We're running large automatic tooling with small teams,
because it's easy to extend and relatively easy to rearrange.

Disclosure: I work for Pivotal, which sponsors Concourse development.

~~~
dserodio
I'd love to see -- or even better, read :) -- about how you "compose on
resources".

------
debacle
I love to hate Jenkins. Such a nice (and remarkably simple, for what it
accomplishes) piece of software.

I've tried to replace it so many times, and so many times come to realize what
an asset it is.

------
TeeWEE
We used Jenkinsfiles and pipelines recently. And also introduce Blue Ocean on
our jenkins server.

It come with a few glitches: Some plugins are not compatible with Blue Ocean,
causing a white-page-of-death. However I found there where already issues
created for them, i just turned off the plugin.

But the biggest downer, is that blue ocean is just a small UI on viewing
pipelines. Its not a replacement for jenkins. And you still need the normal
jenkins UI. Which doesn't handle pipelines well.

I think its still very much a beta project.

~~~
i386
The blank screen issue is extremely important to us to fix and we hope to have
a change that fixes it shortly. It's a consequence of the new REST API
depending on all the plugins installed on your system and exposing its data
for JS plugins. If one plugin misbehaves then it 500s the REST response. We've
got an approach to isolating per plugin failures so that you can load the page
even if one plugin fails.

You can follow progress here [https://issues.jenkins-
ci.org/browse/JENKINS-39647](https://issues.jenkins-
ci.org/browse/JENKINS-39647)

------
petetnt
I have been using Blue Ocean as the radiator view for our Jenkins projects for
a long while now and it does look really nice and sleek. That said, currently
that's pretty much the extend it can be used for. I'd say it has about ~5%
feature parity with the "old" UI currently, which means that there's not much
to do than just look at the pretty progress bars. Can't wait for this to
progress though, the old UI of Jenkins is archaic at best.

~~~
i386
Thanks for the complement. It's hard building a new UX for a tool like
Jenkins. It can be difficult to pick the next thing to work on because one
feature could be the killer feature for one developer but not the other. Is
there anything in particular that blocks you from using it day to day?

~~~
petetnt
Thanks for replying! (First, our Blue Ocean plugin is at 12b currently, so
some of these might be already there).

I agree with the difficulty with picking the next UX piece to build and as
such I guess most of my "wants" are mostly for me. I spend most of the time in
Jenkins fiddling around in the settings, plugins and credentials and such I'd
love to see "/credentials", "/configure", "/configureSecurity",
"/pluginManager" and maybe "/log" and "/load-statistics" under the
Administration tab.

These would alone lower the need for the old UX for myself close to nil, as
the pipelines are mostly automatically managed by our (Jenkinsfile based)
integrations. I do see how the administration part will be really painful, as
all the conventions used by plugins would be have to be "ported" somehow first
I assume?

~~~
i386
Administration tasks are not really in our scope yet (at least not for 1.0 as
it's a huge job to boil the ocean, so to speak) and our focus is on making the
best developer experience for CD Pipelines.

There's a lot of job level configuration that's moving into the Jenkinsfile
with Declarative Pipeline [1], such as triggers, and you can expect that
process to continue.

You're right on the plugin conventions having to be entirely ported. There's a
whole new UI stack that those plugins have to adopt and we have to think
carefully about how we design those extension points rather than blindly
pulling them into the UI.

[1] [https://jenkins.io/blog/2016/12/19/declarative-pipeline-
beta...](https://jenkins.io/blog/2016/12/19/declarative-pipeline-beta/)

------
alexellisuk
This news is from September, I gave my first impressions on Hacker News then,
here's my blog post including an interview from the team behind Blue Ocean.

[http://blog.alexellis.io/tag/jenkins/](http://blog.alexellis.io/tag/jenkins/)

They are doing a great job at reinventing JenkinsCI (but remember it's still
Java)

~~~
pm90
What's wrong with Java?

~~~
alexellisuk
Restrictive licensing and then there's the fact it is a huge memory hog. I
have Blue Ocean running on a home lab with 16GB RAM and Jenkins + SSH slave
drains almost all the resources.

Also - GitLab Travis / CircleCI etc being quite trendy/new remember that if
you need to extend Jenkins you're dealing with a legacy product.

~~~
oblio
Jenkins is both being actively developed and in a different niche than the
others.

Something isn't legacy just because there's something newer out there. Or
everything is legacy :)

------
ergo14
I like blue ocean - but wouldn't moving to something like Concourse CI or GOCD
be a better idea in the end?

~~~
gldalmaso
We currently have a Jenkins setup and recently looked into both Concourse CI
and GoCD as candidates for a change.

We decided not go with Concourse, because it has a complex setup with bosh.
Not much other use cases are really covered in the docs other than a simple
one machine setup so you are left to figure things out on your own (don't
really have the time to go into all that, jenkins + ec2 plugin is very simple
and just works). Also the minimal GUI, very CLI-centric. this is more of a
particular thing, since I don't think that our current team will be
comfortable with that UX and we have to weight this in.

We did like the docker-centric approach and specially the postgres backend
that makes for a much more flexible maintenance story.

We decided not to go with GoCD simply because it feels very similar to jenkins
in several aspects, but all concepts and workflow are different so we would
have to relearn all that we do in jenkins in the GoCD way. Also redo all ops
involved in backup, update etc. I just didn't find the killer feature to
justify going through it. The postgres backend would maybe have caught my
attention if it wasn't offered as an add-on for the expensive paid version.

In the end just decided to leverage more of Jenkins 2.x pipelines with shared
libs instead of having independently configured jobs that are bothersome to
maintain. Will probably make some changes to our agents to leverage more of
docker instead of messing with AMIs.

Another major factor is the size of community, which alleviates a lot of
worries.

As for Blue Ocean, I hope it evolves in the right direction, but right now it
simply does not solve any problems for us. As said somewhere else, you can't
build a pipeline with parameters. This is really a show stopper, parameterized
builds are central to a lot jenkins use cases. Another problem is a single
view for all jobs but no filter? The favorite jobs feature does not substitute
either search or the view and folder way.

~~~
Wilya
A note on concourse deployment: their docs recommend bosh deployments, but
they also provide standalone binaries [0] and the deployment workflow in this
case is extremely simple. Run "concourse web" for the UI, "concourse worker"
for a worker, and all the basic connectivity stuff is handled via command line
parameters.

That being said, depending on your company habits, the fact that concourse is
very opinionated on how to run the jobs (every is built around docker) and how
configuration is done (yaml files, no UI) can be either a blessing or a
showstopper.

[0] [https://concourse.ci/binaries.html](https://concourse.ci/binaries.html)

~~~
twic
> the deployment workflow in this case is extremely simple. Run "concourse
> web" for the UI, "concourse worker" for a worker

By which you mean, of course, "write systemd units or whatever for the web and
worker jobs", because you don't want to be starting your CI system by hand.
That's not rocket science, but it's not quite out of the box.

That said, the emphasis on BOSH must really be hurting Concourse adoption.
Nobody outside the Cloud Foundry bubble (which includes Pivotal) has any
interest in using BOSH at all, and honestly, quite rightly so. It's cool
there's a BOSH option for fans, but the primary deployment option has to be
something accessible by the general public.

~~~
jacques_chester
> _That said, the emphasis on BOSH must really be hurting Concourse adoption._

It did, I think. My gut feel from watching the Slack chat is that lots of
people are deploying using the prebuilt docker containers. There are even
projects that set up k8s clusters for you.

------
samuell
See also thread from May this year:
[https://news.ycombinator.com/item?id=11790900](https://news.ycombinator.com/item?id=11790900)

------
bryanrasmussen
I think in the what is AI argument what has actually happened is that there
have been two conversations about AI over the years - what AI is and what AI
can do by virtue of being AI.

In that conversation the assumption has been that AI would be in some ways
self-aware and intelligent like 'Data in Star Trek' and by virtue of being
self aware and intelligent it would be able to learn things from its users, it
would be able to make aesthetic judgements about music and art, it would be
able to create interesting art of its own and so forth.

As it turns many of the things that AI will be able to do for us has been done
by programs that are 'just math', the question is if in the future more or
even all of AI's perceived benefits for humanity can be accomplished by just
more and more complex 'math'.

In the end perhaps the essence of what AI is will only be beneficial to AI
itself.

~~~
ryjm
Replace 'AI' with 'Jenkins' and this becomes some great satire.

~~~
bryanrasmussen
also if you replace my name with Mark Zuckerberg.

------
was_boring
This is nice! I've been looking for a way to schedule deployments of multiple
code bases at the same time, with automatic rollback support. Does this
support that?

------
thrillgore
This looks great. Not because of the aesthetics, but because it finally
acknowledges that Groovy is absolutely useless for Pipeline. I want to try out
this new workflow.

------
hunvreus
We've actually built Pipelines [1] for that very reason; Jenkins has always
felt over-engineered and unfriendly.

I'd be very interested in hearing from folks who are familiar with it what
they think of our alternative.

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

~~~
jacques_chester
I'm a bit confused -- is this a UI for Jenkins, or a different system
altogether?

~~~
hunvreus
It's a different Python thing. You can install it with just `pip install
pipelines`.

------
stevehiehn
Looks awesome really. The pipeline U.I. is similar to PIVOTAL's Concourse C.I.
I wonder if each job is in a separate container?

~~~
jacques_chester
Pivotal is the sponsor of Concourse. It's an open source project in its own
right.

Blue Ocean is a definite improvement for Jenkins shops, for some such places
it may be a more sensible alternative to switching.

Disclosure: I work for Pivotal.

~~~
stevehiehn
I also work for Pivotal T.O & used Concourse on a recent project. Thats why
this thread caught my attention :)

------
tobiaswk
Can't wait to try this out. It looks very good. It also looks very simplified
which I like.

------
webo
This look nice, is there a hosted version of BlueOcean?

I've been looking into (preferably hosted) pipeline-based CD options because
simple CIs like Travis and CircleCi are not really meant true CD. What does
everybody recommend?

~~~
scaryclam
Jenkins isn't really CD either. I'd suggest looking at GoCD or spinnaker,
though you'd have to host both yourself.

You can get away with using any of the CI tools to just run through pipelines
(heck, you can do this with fancy bash scripts if you're a real masochist ;),
so I guess you could use any of jenkins, CircleCI or Travis to run a pipeline.
I guess it'll depend on how much you really don't want to manage a CD server
yourself.

------
sidcool
The new release of GoCD, 16.12, is also filled with amazing UI improvements.
It's great to see Jenkins making Pipelines as first class citizens.

~~~
jacques_chester
I'm a Concourse nut, which was partly inspired by GoCD.

I'm not sure Jenkins is really making pipelines first class in the same way
GoCD or Concourse do. In particular, there will be a painful period where some
plugins work well and some don't, because plugins are difficult to cleanly
compose.

Disclosure: I work for Pivotal, which sponsors Concourse development.

~~~
sidcool
I tried the new Jenkins update, it's quite buggy at the moment. I am going to
stick to GoCD for now.

------
meddlepal
I've given up on Jenkins and switched to Travis. The overhead of managing a
good Jenkins setup for a small team is not worth the effort.

------
jklondon
What's the most amazing thing you have done with this technology?

------
neoyogi9
This looks very much similar to HP CDA (Continuous Delivery Automation), the
project was later scrapped. Wish they had open sourced it.

------
anjc
You'd have to imagine that the term Blue Ocean would be trademarked for
contexts like this

~~~
phaed
Given the competition in the space, would it not be more aptly named Red
Ocean?

------
msane
This looks great. After this the next step for Jenkins should be to change the
name.

~~~
dserodio
It kind of did already. It used to live at [https://jenkins-
ci.org](https://jenkins-ci.org), and was moved to
[http://jenkins.io](http://jenkins.io) to communicate that it's not "only CI",
but also CD.

~~~
mns06
It was also renamed once, from Hudson.
[https://en.wikipedia.org/wiki/Hudson_(software)#Hudson.E2.80...](https://en.wikipedia.org/wiki/Hudson_\(software\)#Hudson.E2.80.93Jenkins_split)

