ThoughtWorks first released the commercial product that would become Go in 2008. It was rebranded later, shortly after the public announcement of Golang. Yes, it was a confusing move, but at the time there was no reason to believe that a programming language might conflict with a continuous delivery tool. Golang has produced a large and robust community, so of course it's confusing now. But it didn't come out of nowhere.
Might be hard to do, since it has been around for a while, but here's the Github issue on the project about the name: https://github.com/gocd/gocd/issues/131
apparently Thoughtworks has been building the Go continuous delivery tool as a custom product from even before Google made Go! I think the word "GO" hasn't been trademarked yet.
Speaking of golang (go), this slide [0] lists breaking new ground in programming language research as a non-goal. That may include language name research.
This is exciting. I've used Go-CI (that's what I'm calling it) before and it's a very cool product for pipelining. Kudos to TW for open-sourcing it. Time to get the plugins rolling!
The name gocd has been getting quite a bit of traction on twitter and such, and that's the name of the GitHub repo. Searching for that might be more effective.
I'm curious why this is a Java/JRuby on Rails project and not natively written in Go itself. Does anyone have some insight here? Is it that the project requirements themselves lean towards Rails tooling? I'm sure I'm not the only one surprised by this.
EDIT: Ah, I'm not the smartest cookie in the jar. It, in fact, has nothing to do with Golang. I agree with the poster below who mentions this criticism.
The pipeline features of gocd seems very nice. However, last time I looked at gocd it did not support feature branches. As far as I could tell, it was not due to technical reasons but rather due to the whole feature branch vs continuous integration philosophy differences.
Any idea whether feature branch support will be added in the future?
Go was their (our) commercial product which initially started from CruiseControl as the base. Go is a whole different beast and has gained a lot of features over the years. Now, it has been open sourced as well.
It's definitely not Java only, but it's also not really a replacement for MSDeploy. Instead, Go would run MSDeploy as the last step in a deployment pipeline. Check out http://bit.ly/RSAz3U for an MS based pipeline (though sadly for your question not MSDeploy)
I hope this helps- but Go is not a build tool - but a deployment pipeline tool.
Go runs builds on your machines and can call out to various build tools- like Ant, Nant, rake - or if all else fails- the shell. So anything you can run on the command line of your machine (either windows or *nix) can be automated by Snap.
side note: an interesting build tool that i've been using for past couple of years is Quickbuild - http://www.pmease.com/. take a look if you've got a lot of build configurations could be streamlined by using inheritance.
The answer to this question probably deserves a blog post. But, as mentioned by @willejs here (https://news.ycombinator.com/item?id=7646496), Jenkins has a well established community of plugins and plugin writers and so, is quite extensible. Go has good visualisation and good modeling capability, allowing you to model complex build and deployment workflows using a combination of tasks running in parallel and serial.
Both have many more pros and cons. To do justice to it, it needs a blog post. Let's see. Maybe I'll write one soon.
I'd used Go (continuous delivery) at University before I'd heard about Go(lang). Yes, whilst in the perfect world everything would be named a short, memorable, unqiue (,descriptive?) name - that's not the case. The two items in question are distinct enough that searching for golang vs go cd will produce relevant results.
