This is a whishlist for how I’m wishing Go.cd will evolve.
The list is explained with more words below
- Sharable, filtered Home view
- Fewer clicks for (human) build masters
- Comments/metadata on pipelines
- Comments/metadata on pipeline run(s)
- Config diff blame
- Easy renaming of pipelines and stages
- Visual modeling of pipelines
Before going in to details - I do not claim that Go.cd and Jenkins are tools that does the same thing. They don’t. My perspective is simply that Jenkins is well known, and I’d like to see the threshold of moving from Jenkins to Go, to lower.
Sharable, filtered Home view
This one is called Views in Jenkins. This feature allows you to select which jobs (among the full set of available Jenkins jobs) to display on a page. This page has links to other views, and the “All” view which shows all jobs. This is used heavily to keep the noise to signal ratio in check.
In Go.cd, you can restrict individuals from even viewing pipelines in a pipeline group. But this doesn’t work when your organization’s policy is “Everyone should be able to do everything”. Go.cd does allow dynamic, per user, per browser filtering of the Home view. However, this can’t be shared, is not permanent and whenever a new pipeline is added, it shows up in your filtered view.
Fewer clicks for (human) build masters
A human build master is a person that manually edits pipelines, stages, jobs and tasks. You can argue whether this is a good practice or not, but I’m 100% sure Go.cd want to support this mode of operation.
A very common cycle for a build master is this: edit a pipeline (perhaps fix a typo in a path), trigger it to run, look at the console output from the run, repeat. In Go.cd 15.2, a typical setup is to have three tabs open in order to achive the above cycle: the Admin view where you can edit the pipeline; the Home view where you can trigger a pipeline; the History view where you can easily see the latest run and get access to console output. Trying to do this with one tab will require at least 10 clicks with your mouse (try it). with Jenkins, this is 5 clicks.
A colleague said: “Jenkins’ UI feels like it’s object oriented - you can right-click on things/dropdown and get to details quicker. Go.cd feels like it’s action and role oriented - just like clear case and things from the 20th century”. I completely understands this view.
Comments/metadata on pipelines
A typical comment found at the top of a Jenkins server would be: “This set of jobs builds component X. Talk to team Blue if you want to make changes. The nightly system is deployed to https://blue.x.consul.company.com/”.
The same thing is typically found for each job: “This job moves artifacts from the Maven world (Nexus) to YUM channels (Artifactory). The URL to the YUM channel is published and readily available for each downstream job to be picked up here: http://url.to.jenkins”.
Incredibly useful for a big setup, especially if you don’t have a Value Stream Map built in.
Comments/metadata on a run
“We’re looking at this right now / Team Blue” or “This failed due to disk hardware failure on build-machine-03, see https://jira/browse/TICKET-123 for details”.
Config diff blame
With this, what I’m looking for is to be able to make diffs of two configurations and not only see what is different, but also who made that change so I can go talk to that person.
Easy renaming of pipelines and stages
Pipelines currently can’t be renamed, at all.
Stages can be renamed, as long as there are no downstream stages depending on the one you’re trying to rename. If you’re unlucky, you have to temporarily break/remove the dependency in the downstream pipelines (probably pause them as you’re doing this), then rename the stage, add the dependency back in downstream pipes (and un-pause them). Or you edit the XML file manually and hope you don’t make mistakes. That option is probably easier (which says something about the UI/UX of this operation).
Visual modeling of pipelines
Remember Yahoo! Pipes? You “add a repo”, “add a pipeline box”, “connect the to using a pipe”. Simple operations in the browser. Man if you could model your pipelines, material and stages in one view and not care about the details while just getting the overall picture and flow of it in place.
See Value Stream Map from config only
Somehow, you can’t get a Value Stream Map (VSM) from reading configuration only. While it’s perfectly possible for things to change as they’re edited and execution is happening, while modeling the flow of work, it would be great to see the VSM even though a single job has not yet run.