Potential feature request for enhanced materials API (beware, branch talk)

[Ken Mugrage]

I don't think we want to provide really extravagant branching support in Go for what I believe to be good reasons (http://martinfowler.com/bliki/FeatureBranch.html). That said, in the world of SCMs like Git it would be great to have an easier way to switch a personal pipeline for a short period of time. Consider the following potential workflow...

I want to be able to submit very discrete pull requests but I have existing requests pending on master. I created a new branch called "events" and made my changes there. I have a personal pipeline for testing local changes, but it's pointed at the master branch. 

I'd like to have a script written that would allow me to do something like "switch_branch.rb myGoServer myGoPipeline myMaterialName myNewBranch". Maybe some of that is pre-configured of course, but the point is that Go would be updated to watch the new branch. 

Opinions?

--

Ken Mugrage - ThoughtWorks Studios
kmug...@thoughtworks.com | http://www.thoughtworks.com | Twitter: @kmugrage
Go, the Continuous Delivery platform is now open source! http://www.go.cd/

[Jens Rantil]

Ken,

I asked a similar question on the users' mailing list: https://groups.google.com/d/msg/go-cd/sX7NLgT6v3s/vvARG3yLU4EJ I also just created a Github issue for this here: https://github.com/gocd/gocd/issues/298

Cheers,

Jens

[Ken Mugrage]

Very interested in other opinions on potential branching support. I believe my preference would be fairly limited support, such as the ability to run the first pipeline automatically but not anything downstream. Just a thought. 

Anyone else? This has been quite the topic for quite a while so here's a chance to determine how (or if) it gets done!

Ken

[Brett Cave]

On Wednesday, 25 June 2014 17:24:50 UTC+2, Ken Mugrage wrote:

Very interested in other opinions on potential branching support. I believe my preference would be fairly limited support, such as the ability to run the first pipeline automatically but not anything downstream. Just a thought. 

Anyone else? This has been quite the topic for quite a while so here's a chance to determine how (or if) it gets done!

I think this would be a really useful feature to have in Go, especially for anyone following the GitHub flow (feature branches off master) or a more verbose variation of master branch <-- dev branch <-- feature branches.

I was going to start playing around with plugins to see if I could get it to work with this. If this feature was available in Go, i would consider creating 2 pipelines: 1 that builds off master only and has downstreams through to Prod deployment pipelines, and another that polls all branches (not too sure of the internal of git and how to do this) that can build and test, and trigger a QA downstream.

Your suggestion of don't trigger downstreams if branch != master would also work, but could end up being restrictive, especially if I use a downstream pipeline to deploy to QA and want to test the code in a feature branch.

[Yohan Beschi]

Hello guys,

@Ken, I'm the one who ask about multiple branches in today's webinar.

Even if today we are far the the waterfall model, release iterations can be long (one month). Therefore if there is a bug (let's say a critical one) in production 10 days after the release we need to fix it and release a new version fast without all the new code committed by the developers during theses 10 days.

Consequently I came to the conclusion that I needed at least 2 branches in my CD system (one for the developpers and one for the production). We use feature/hotfix branches but I don't see where/how these could fit in Go or any CD tool (templating a dev pipeline for each branches seems quite enough).

And because we have 4 environments for each of our apps (Dev, Staging, UAT and Production), I currently fighting to reduce releases gaps to Staging and UAT (at most one week) to avoid maintaining 2 others branches.

Here some screenshots of slides I made. What I want to avoid:

• Horizontal arrows can be interpreted as branches or CD pipelines
  
• The black curved arrow means "we have a bug in UAT, developers please fix it"
  
• The green curved arrows are releases
  
• The blue curved arrows are merges
  

or even worse:

So I came up with 2 unsatisfying solutions:

Solution 1

• Light blue arrows are automated actions
  
• Darker blue arrows are manual actions
  
• Orange boxes are pipelines in CD terms (Blockers is for critical bugs fixed that need to be release)
  
• Grey boxes are pipelines in Go terms
  
• Transient env, is a short-live instance. We deploy the app on it and when the production pipeline ends, it is automatically terminated)

Problem: we have 2 different pipelines for the release in production and 2 different places to look for the actual version in production.

Solution 2

Artifact promotion means that we saved somewhere the version of the validated artifact. Then we manually launch the Production pipeline, which will check the version and pull it from Nexus for example and execute the other stages.

Problem: The production pipeline will not be show in either CD or Blockers pipeline Value Stream Map.

What would help to model a single Value Stream Map of the 3 pipelines shown in the screenshots is some kind of partial fan-in, not the all or nothing one.

Of course Continuous Deployment with a deployment every day in production will solve all of these issues, unfortunately this kind of decision is out of my hands.

Yohan

[dha...@thoughtworks.com]

GitHub flow support ++ (https://guides.github.com/introduction/flow/index.html)

This is important both for open source projects (GoCD could certainly use it) and for teams that decide to use GitHub flow. It's a relatively popular way of working for many teams (despite how I may feel about feature branching).

[srinivas upadhya]

Updates about feature branch/pull request builds on #298.