BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News ThoughtWorks Open Sources Go, a CD Tool

ThoughtWorks Open Sources Go, a CD Tool

This item in japanese

Lire ce contenu en français

Bookmarks

ThoughtWorks has recently open sourced their Continuous Delivery (CD) tool, called Go, having its origins in CruiseControl and providing a pipeline process that covers the entire code development process: continuous integration, testing and deploying.

While Go’s GitHub account still waits to be populated with source code, developers can grab the binaries, both the client and agent, which are available for Windows, Mac OS X, Linux, Solaris, or as a Java JAR.

InfoQ has talked to Ken Mugrage, Open Source Program Manager at ThoughtWorks Studios, to find out more about their plans regarding Go.

InfoQ: What makes Go desirable?

The ability to model a build / test / deploy process is captured in a concept called a pipeline. Since go was purpose built to be a CD tool, this concept is core to the product. Having pipelines as a first-order concept and dependency management that “just works” makes it simple to model even the most complex workflows. Many other products have attempted to bolt-on the same functionality but it's typically a veneer or plug-in that makes it look like a pipeline.

InfoQ: Tell us a bit about Go’s history.

Go was first created as a commercial product called "Cruise" in 2007. The team creating it quickly realized that the architecture of previous continuous integration solutions would not support the way we wanted to implement grids and the build, test and deployment workflow. This led to the decision to create an entirely new commercial product. Subsequent releases saw the product grow in terms of both features and is ability to support large build farms and multiple, large teams. Our 2.0 product, renamed Go, included the ability to run a large suite of acceptance tests across the grid and report back which tests are currently breaking and which check-in broke them, a unique capability in a commercial CI tool at the time. 

InfoQ: Why open sourcing Go?

The short answer is that we've come to the conclusion it's the right thing to do. As a company, ThoughtWorks' is dedicated to promoting solid technical practices. In fact one of our 3 guiding principals (we call them pillars) is to "Champion software excellence and revolutionize the IT industry". We see making Go an open source product as a big way that we can promote solid continuous delivery practices. 

More and more the industry also expects that any software that is part of platform or infrastructure be OSS. There are various reasons: expectations of higher security & robustness, ability to contribute, richer community, and, frankly, the price works for them. Since Go is a big part of your data center, many people consider it infrastructure. Our customers use Go to orchestrate the full build and deploy lifecycle of all their applications.

InfoQ: What other tools does Go require to be integrated with to achieve a fully automated deployment pipeline?

This is actually a little bit of a tough question. Go itself doesn't require anything, so the list would be determined by the users' build / test / deploy cycle.

Go orchestrates the numerous moving parts involved in promoting software from code composition to a production environment where users can access it. Go watches a version control system or package repository for changes. When it senses changes, it runs other tools as required by your build / test / deploy cycle.  These include build managers like Apache Ant, Apache Maven, Microsoft MSBuild; automated testing tools like Selenium, Twist, Cucumber; infrastructure management tools like Chef, Puppet and many more. Go can run anything you can execute from the command line. 

InfoQ: Are you going to continue developing a commercial version of Go? Are you continuing to provide support for it?

There will be commercial add-ons and professional support offered for Go. The add-ons are to be determined by demand, but they will be things like the ability to connect to an external database (inside of the embedded one mostly used) for very large deployments to improve performance. 

I've had the pleasure of talking to most of our existing customers about the new model, and am happy to say that without exception they have been happy. 

While Go is a CD tool that can be installed on-premises or in the cloud, ThoughtWorks offers another continuous delivery solution called Snap, which is a hosted CD tool. Go can scale up to automate the CD process on hundreds of machines; Snap is meant to be a leaner tool for “applications with simpler deployment needs,” told us Badrinath Janakiraman, Product Owner of Snap, who added that “this does not mean a simpler application, just a simpler testing/deployment model.“

The advantage of Snap over Go is that “Snap lets ‘serverless’ organizations (with everything from source-code to applications being hosted on various SaaS & PaaS services) get started on their CD journey with minimal effort. Once teams get comfortable designing applications that are meant to be released on demand, they may choose to move off of Snap as their deployment needs get more complex,” said Janakiraman.

Snap does continuous integration for Java, Ruby, Python, JavaScript & Node.js projects, supporting a number of databases –Sqlite3, PostgreSQL, MySQL, Redis, CouchDB, MongoDB –, testing done via Capybara, Selenium, PhantomJS, and deployment on Heroku or AWS. Other build/testing/deployment configurations may be supported on request.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Poor name choice

    by Dean Schulze,

    • Poor name choice

      by Dean Schulze,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      They should have used a different name. It's going to create confusion with the Google Go language, and as golang users know the word "go" is a very poor search term.

      Does Go do continuous builds for applications written in Go? I can only imagine what a search would turn up.

    • Re: Poor name choice

      by Jeff Hain,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      They could rename it "goo", because it glues delivery steps together.
      But "go" looks like just a short name, "GoCD" being the full name.

    • Re: Poor name choice

      by Sriram Narayan,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      It was named Go before Google announced golang. And yes, it can run anything that can be exec'd on the agent (build machine). See support.thoughtworks.com/entries/22873043-Go-s-...

    • Re: Poor name choice

      by Dean Schulze,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      The Go language was announced at least 4 years ago. Still, it would have been better to release GoCD with a different name, or to not shorten it to Go.

    • Re: Poor name choice

      by Jez Humble,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Here's some history on the tool. It was released under the name "Go" back in 2010: www.thoughtworks.com/insights/blog/go-goes-open...

    • Re: Poor name choice

      by Ken Mugrage,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      It would be great if we didn't have the name conflict, and you're absolutely right that it's hard to search for.

      To be completely transparent, we probably would have changed the name if it wasn't for the delay that would cause in releasing the code to the public. Once the code is released should the community of users and contributors want to change the name (and believe that effort is of a higher priority than other work) the existing team will happily support the decision.

      I hope this makes sense. If you'd like to discuss in greater detail please do join the mailing list you'll find on the website. Feature requests, criticism etc is gladly accepted as a much needed form of contribution for an open source project.

    • Great tool and good that it is opensourced.

      by PRABHAKARAN THATCHINAMOORTHY,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Its great that it got free. We are using GO for CD for the last 3 years, and it was great. its easy. We asked our other teams across globe to try it, and use it, but they ignored us just because it was proprietory. Also earlier for a trial version, we have email a person, then follow a process which was cumbersome. Now, as it is opensource, and the binaries of Go-Agent and Go-Server can be downloaded, our offshore teams have accepted to give a try on GO. I am pretty confident, once they try it, they will love it. Its simple, intuitive, powerful.

    • Re: Poor name choice

      by PRABHAKARAN THATCHINAMOORTHY,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Come on. GO is an apt word when compared to names like XL Deploy, rundeck, puppet, Jenkins, Hudson etc. We can be picky, but the name truly reflects its purpose.

      As a build engineer, I care about the name of the languages or tools around build and release management, and it does not clash with any of the other ones.
      Also when I google terms like "continous delivery", CI, CD, etc, the Google's "Go" language never gets listed.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT