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.
