What resources is Cloudbees allocating to Blue Ocean maintenance/development?

519 views
Skip to first unread message

Craig Rodrigues

unread,
Dec 12, 2018, 3:30:10 PM12/12/18
to Jenkins Developers
Hi,

When BlueOcean was originally being developed, James Dumay,
who was a Director, Product Management at Cloudbees
was very active in leading Blue Ocean, and communicating status and
milestones with the Jenkins community.

Since James has left Cloudbees, what I have observed is:

1.  No one at the manager/director level is visible on the https://gitter.im/jenkinsci/blueocean-plugin Gitter channel to communicate with users or get feedback
2.  Many bugs filed against Blue Ocean in JIRA are unassigned
3.  Cloudbees employees who log into https://gitter.im/jenkinsci/blueocean-plugin seem to be doing so as a best-effort/volunteer level.  For example, on Nov. 16, Keith Zantow reported:

Keith Zantow @kzantow Nov 16 06:36 @rodrigc hard to say exactly what's in the road map at this moment, but certainly open to patches

Can someone in Cloudbees management comment on the company's commitment to Blue Ocean?

I try to do what I can.  I've submitted one bugfix:

And submitted a few bug reports:

Blue Ocean is very good, but needs some bugfixes and usability
fixes to meet parity with the Jenkins Classic UI.
Blue Ocean is some complicated "modern JavaScript", and I don't
have enough time to dig into it to fix the problems myself.

I am trying to push Blue Ocean and Pipeline very heavily at the companies
I work for, and for the most part everyone I talk to really likes Blue Ocean,
but the bugs/gaps are a problem for wider adoption/success in the projects
I work on.

Thanks for any feedback.

--
Craig


Kohsuke Kawaguchi

unread,
Dec 20, 2018, 5:41:29 PM12/20/18
to Jenkins Developers
Hi, Craig,

First of all, thanks for raising this question, and my apologies for taking this long to come back to it. You asked an important question about CloudBees’ position and thoughts, so we needed to talk among ourselves for me to get to this answer. And this isn’t as easy as we want for a big distributed company like us. I will start by saying that CloudBees is 100% behind Jenkins. And we don’t just talk the talk, we walk the walk. In 2018, our people worked on a lot of different areas of Jenkins, ranging from Configuration as Code, “cloud native” improvements, security fixes, Jenkins X, Evergreen, and the list goes on. So how does that translate to Blue Ocean?

Blue Ocean accomplished many things. It created a great excitement, it made many Jenkins users’ lives far better, and it paved the way for driving other significant projects that transform Jenkins, such as Jenkins X. At the same time, I think it hasn’t yet attained the “escape velocity” of community collaboration like core did a decade ago. There are multiple reasons for that. Partly, it’s because of  the JavaScript SPA skill set requirement that are not readily available within the Jenkins community. Also, more importantly, it hasn’t attained the sufficient level of extensibility, which made it difficult for plugin developers to contribute productively. The team took on some serious efforts to tackle this challenge, and you can see them on some branches and JEPs, but it’s a truly unique problem, and we haven’t cracked that egg yet. So Blue Ocean is kind of at a crossroad — It needs to tackle some hard problems before it can attain the true parity with the classic UI, but our initial attempt at that didn’t pan out.

In the meantime, what’s happening is that we’ve been focusing on other major efforts around Jenkins. Many of those I already mentioned above and elsewhere, which all require significant brain juice and time. And those big ticket items all have major impact on UI. For example, with Cloud Native Jenkins as a distributed software, how do we need to put together the UI in that world? If CasC is very successful, maybe we can let that take the place of the system configuration UI. As those efforts were going out first, Blue Ocean was left in a reactive mode.

The bottom line is, as it stands right now, CloudBees haven’t yet come to “the CloudBees’ plan” on Blue Ocean. Different people, myself included, have various thoughts, but they still need to come together to form one coherent plan. The key leader in this process is Jenn Briden <jbr...@cloudbees.com>. She is the product manager that is responsible for this area. In authoring this response I talked with her, she has thoughts, and she is willing to talk to people if anyone have thoughts and opinions. She is interested in working with you and she’ll reach out to you, and I suggest others with thoughts to send her an email, while we work on how she can more proactively engage in the community.

For the time being, CloudBees is doing what it can to fix regressions, bugs, and doing the necessary maintenance to retain the same level of functionalities as the rest of Jenkins evolves. Many of the people who have worked on Blue Ocean are still around, such as  Keith, Nicu, Josh, Ivan, et al. And what you saw is  them holding the fort. I will do my part to ensure Jenn to get the necessary organizational support to engage in the community and form a plan, and to have that communicated well when that happens.  Or if somebody else is willing to step up and carry the torch forward, I’d love that, too.

And I recognize this problem applies more broadly. As the pace of innovation accelerates, it’s good that our thoughts and thinking continue to evolve on key efforts to incorporate more thoughts and polish ideas, but it needs to come hand in hand with better communication and engagement, and we fell short on the area, as this thread highlights. We had some leadership changes, including James’ departure, and that didn’t help either.  That’s something I’m well aware of, and me and others having been working on it.

That’s the honest answer I can provide at the moment, as CTO of CloudBees. 

Craig Rodrigues

unread,
Dec 27, 2018, 12:30:50 AM12/27/18
to Jenkins Developers, Kohsuke Kawaguchi
Kohsuke,

Thanks for your honest and open response about my query about Cloudbees resources allocated to Blue Ocean.

I am very happy with Cloudbees' investment in Blue Ocean.  When I show the UI to co-workers
and managers, they are impressed.  That in turn makes it easier to promote the use of Pipeline
and other "modern" Jenkins technologies in organizations that are using Jenkins, but may not be on the latest stuff.

In terms of Blue Ocean, I have seen initially a very active and engaging involvement from Cloudbees in terms
of kicking off the project and carrying it along.  Unfortunately, the involvement from Cloudbees has become much
more passive.  From what you have described, there are a few passionate and talented developers
at Cloudbees who are holding the fort on Blue Ocean.  I am grateful for the enthusiasm, skill, and motivation
of these developers.  It is always a pleasure to interact with Cloudbees developers.

However, my concern is that if the current mode is "holding the fort", then the appearance from the
outside is that Blue Ocean is being passionately supported by a few developers, but it is not
a high priority from Cloudbees management, and the developers are not being actively supported or given a clear
direction/roadmap to work on Blue Ocean.  In other companies, I have seen where this mode of operation
can lead to burnout and frustration on behalf of developers.

I understand that Cloudbees is focusing on a lot of technical areas which are very important for the
future of the Jenkins ecosystem.  I'm glad to see this.  I also understand that resources are limited,
and deciding what resources to allocate to what project can be tricky.

Blue Ocean is a significant piece of technical work, and due to its complexity, I think Cloudbees
should continue to have a leadership role in its ongoing maintenance/bugfixes, and evolution.
There just are not enough developers in the open source Jenkins community who
are versed enough in modern Javascript/NodeJS to make significant contributions to Blue Ocean.

I would like to suggest the following:

1.  Cloudbees should select one person, either a developer or manager to "own" Blue Ocean.
2.  The owner of Blue Ocean should make regular appearances (maybe once  week) in the Blue Ocean gitter channel: https://gitter.im/jenkinsci/blueocean-plugin
     to get an idea what problems the community is having with Blue Ocean, and also
     give periodic updates on future plans, roadmap, etc.
3.  All bugs in JIRA should be assigned to this owner of Blue Ocean.  There should be no unassigned Blue Ocean bugs.
    Also, bugs assigned to previous owners, such as James Dumay, should be assigned to the active owner.
4.  This owner should triage bugs into separate piles: easy to fix, hard to fix, won't fix, etc.    
5.  Cloudbees should assign 1 or 2 developers to officially work on Blue Ocean part-time, say 1 to 2 days a week, to
     work on the Blue Ocean bug backlog.  If other Cloudbees developers pitch in and help out, that's awesome, but
     there should be at least a few developers officially assigned to Blue Ocean, and aware of the roadmap.
6.  If possible, Cloudbees should assign a UI/UX person for maybe 1 day a week to oversee overall changes to Blue Ocean, and make sure
     that any changes improve UI and usability, and don't become a new kitchen sink.

In terms of the work that needs to be done on Blue Ocean, my gut feeling is that there are two categories:

1.  Maintenance/bugfixes and minor filling of "pot holes" to bring Blue Ocean to feature parity with the Classic UI.
2.  Major interface changes to the Blue Ocean UI.  For example, adding customized test reports to Blue Ocean test report viewer: https://issues.jenkins-ci.org/browse/JENKINS-50589

If Cloudbees can at least allocate some resources to officially work on Category 1 at a low level of activity,
that would be an improvement over the current situation.

Thanks again for listening to my feedback.

Feel free to contact me off the mailing lists for further feedback.
I am also in the SF Bay Area, and can drop by the Cloudbees office to chat if you want.
A few years ago, I dropped by the Cloudbees office to chat with Andrew Bayer about
Pipeline.

--
Craig

Kohsuke Kawaguchi

unread,
Jan 2, 2019, 7:33:20 PM1/2/19
to jenkin...@googlegroups.com
Thanks for your positive words and the suggestions.

Speaking as myself, not necessarily representing CloudBees' collective opinion, the idea of one person playing a leadership role is quite consistent with what we've been generally doing lately in the Jenkins project -- plugin maintainers, officers, SIG leaders, and JEP sponsors to name a few. I think its effect of creating an information flow has been useful. So I'm a big fan of that.


--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3DrPVcZpEKTPr8a%3D86_qx33Z7jxFoJTjCBPUnSHB-EvXsDsHQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
Kohsuke Kawaguchi

Ryan

unread,
Jan 11, 2019, 1:04:44 PM1/11/19
to Jenkins Developers
I'm a big fan of Blue Ocean as well.  I'd love to see more investment from CouldBees to pushing Blue Ocean to it's limits.  Glad to hear CloudBees is still thinking about it.

Ullrich Hafner

unread,
Jan 15, 2019, 6:27:03 PM1/15/19
to Jenkins Developers
Thanks Kohsuke and Jenn for describing the plans for Blue Ocean.

While I understand, that you all are moving away from long-lived road maps I think it still would make sense if you would clarify your vision for Blue Ocean and Jenkins (and the classic UI) in more detail. 

Blue Ocean started three years ago with the vision to replace the whole UI, i.e. jenkins/job/pipeline configuration *and* the visualization of the job results. While I think we have a lot of exciting results for the former part (and JCaC for the configuratuion), the latter part has only results for less than 1% of the plugins. In "Jenkins: Shifting Gears“ Kohsuke also mentioned that the next development version of Jenkins will have no UI at all. This makes me somewhat uncertain about the future of the UI part in Jenkins. Are there still plans to replace the visualization of the job results of all plugins with Blue Ocean? Or wouldn’t it be easier to rework the classic UI by letting plugins use the old-style jelly model with some modern JS libraries like Bootstrap, JQuery, Datatables, ECharts, etc? Or thinking one step further: should we forget the Jenkins job visualization UI at all and plugin authors should create their own stand-alone UI (e.g. using a simple Spring Boot application) and read all information from the pluggable storage of a UI-less Jenkins using REST services? 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

Kohsuke Kawaguchi

unread,
Jan 17, 2019, 3:36:35 PM1/17/19
to jenkin...@googlegroups.com
On Tue, Jan 15, 2019 at 3:27 PM Ullrich Hafner <ullrich...@gmail.com> wrote:
Thanks Kohsuke and Jenn for describing the plans for Blue Ocean.

While I understand, that you all are moving away from long-lived road maps I think it still would make sense if you would clarify your vision for Blue Ocean and Jenkins (and the classic UI) in more detail. 

I agree. I can share my own thoughts, but at the end of the day, I think it needs to come from people who "own" this. I'm not a part of the product/engineering teams who are defining this, and I agree with you that it's important for me that they share their perspectives here.

Blue Ocean started three years ago with the vision to replace the whole UI, i.e. jenkins/job/pipeline configuration *and* the visualization of the job results. While I think we have a lot of exciting results for the former part (and JCaC for the configuratuion), the latter part has only results for less than 1% of the plugins. In "Jenkins: Shifting Gears“ Kohsuke also mentioned that the next development version of Jenkins will have no UI at all. This makes me somewhat uncertain about the future of the UI part in Jenkins. Are there still plans to replace the visualization of the job results of all plugins with Blue Ocean? Or wouldn’t it be easier to rework the classic UI by letting plugins use the old-style jelly model with some modern JS libraries like Bootstrap, JQuery, Datatables, ECharts, etc? Or thinking one step further: should we forget the Jenkins job visualization UI at all and plugin authors should create their own stand-alone UI (e.g. using a simple Spring Boot application) and read all information from the pluggable storage of a UI-less Jenkins using REST services? 

I agree with your assessment that the "visualization of the job results" have the large gap today because it covers only a small part of the plugins. That led to my call to action in DW|JW keynote that the next leg of Blue Ocean's effort should focus on the extensibility. It's still just a call to action and not a "CloudBees' plan" because it didn't get to the point of a consensus of the organization.

I want to clarify that when I said "no UI" in "Shifting Gears," what I meant is that the first milestone of cloud native Jenkins can be achieved a lot easier if we drop the UI from it, and that despite that draw back, that milestone would be still plenty useful for sizable people. But that's just first milestone. In a long run, I think UI is a crucial part of the value of Jenkins. It's what differentiated Jenkins from cron in the first place, and an important part of the continuous integration/delivery is to give visibility to more people, which to me necessarily includes consolidating information.

To the best of my knowledge, nobody currently has a viable plan to "replace the visualization of the job results of all plugins with Blue Ocean." It's great that you are exploring more options, such as "modern JS libraries on top of classic UI" and "let plugins build their own stand-alone UI."  I welcome more of those conversations.

Riffing off  that brainstorming, I think one key change in this space is that individualized feedback matters a lot more than it used to be. Back then, the amount of automation was small enough that showing everything to everyone was normal. Now, that had turned into fire hose, and I think CI/CD is expected to provide personalized, context sensitive signals to developers in places that they expect (PR, chat, etc.) I think we have some catch-up to do in that space. Just like analysis-core was a foundational subsystem that opened up the whole space in Jenkins, I think there's a room to create a similar foundational subsystem that opens up a whole personalized context sensitive communication with individual users. And to me, that's an important part of "UI."



For more options, visit https://groups.google.com/d/optout.
--
Kohsuke Kawaguchi

Craig Rodrigues

unread,
Jan 19, 2019, 1:08:48 AM1/19/19
to Jenkins Developers
In my current job, we ely on the both the classic Jenkins UI and
the Blue Ocean UI very heavily.  We have hundreds of tests, producing huge
log files.  We use the  test report viewer in classic UI and Blue Ocean very heavily.

Two things (out of many things) that I like about the Blue Ocean UI are:

1.  massive text log files can be loaded more quickly in a web browser
2.  it is possible to hyperlink directly to a single line in a log file, which is very useful for pasting
     into an e-mail or a Slack message, to share with co-workers.

I understand that the focus of Cloudbees has shifted to other things, and maybe
for the next few years the pace of massive new work on Blue Ocean will be slow.
However, it would still be nice to have someone (Cloudbees ?) fix some of the minor
pot holes in Blue Ocean.  For example:

If some level of activity (even low level) could be invested in fixing these types of pot holes, that would be nice.
If I am able, I will try to submit patches, but I'm a bit busy with my job, and
am not an expert in Node.js.

--
Craig

Michael Neale

unread,
Jan 22, 2019, 12:01:31 AM1/22/19
to Jenkins Developers
Responding (but obviously nothing official) but I like the points brought up by Craig and Uli. 

To Ulis point: extensibility in GUI is haaard, and I don't think blue ocean has solved it to the point that those rich visual aspects of the 99% he alludes to can be catered to. There are some great ideas here - I liked the one of plugins thinking about visualisation specific to them (which may be able to be incorporated in many places). This plays into Kohsukes point "I think one key change in this space is that individualized feedback matters a lot more than it used to be" which I strongly agree with too. Eg people are looking at results right in pull requests, or slack messages and so on. 

To Craig's point - that is a great and fairly reasonable hitlist to make something end to end useful. On the first one I put a comment (not sure if pipeline jobs can be disabled at all...) but it is valid. The others are doable (the hard one is editing build info - as that is where extensible GUIs of plugins can kick in - but likely the scope can be contained here to be reasonable to make something useful end to end). That would be great!

For the executors one - we could resurrect the old executor visualisation plugin (this was mostly done as a demo of extensibility, but perhaps it is time to fold it in) - there is some code here: https://github.com/jenkinsci/blueocean-executor-info-plugin which may be useful for that (doesn't need to be its own plugin, really...)

Craig Rodrigues

unread,
Feb 2, 2019, 7:01:46 PM2/2/19
to Jenkins Developers
Hi,

I attended the recent Pipeline Authoring SIG meeting ( https://jenkins.io/sigs/pipeline-authoring/ ) led
by Andrew Bayer.  I found the meeting to be well organized and very informative.

It may or may not work for Blue Ocean, but I found this SIG model of interacting with the community
to be quite effective.

--
Craig
Reply all
Reply to author
Forward
0 new messages