Over a million developers have joined DZone.

Go 2.2: Free Community Edition No Longer Requires a License

DZone 's Guide to

Go 2.2: Free Community Edition No Longer Requires a License

· DevOps Zone ·
Free Resource
When it comes to practicing what you preach as a software company, ThoughtWorks Studios is a prime example of an organization that eats its own dogfood.  Before the reboot of their release management software, called " Go" (Formerly "Cruise"), the developers were using it internally to develop, test, and deploy their solutions.  Today, TWS still uses Go to develop Go, and the company has its own software to thank for the on-time, quality release of Go 2.2.

One of the main changes to Go is that it no longer requires a license to run the free community edition.  This was due to compelling feedback from the Go userbase.  Now the installation process for the community edition is much simpler.

Go and the other supporting solutions, Twist (test automation) and Mingle (collaboration), are becoming more OpenSocial enabled.  If you use Mingle 3.3 with Go 2.2 you’ll be able to see the Mingle card activity (fixed bugs, completed features, etc.) between two deployments.  A new config interface in 2.2 is another major feature that the less XML-savvy users will love.

Chad Wathington, the VP of Product Development described the major new features in more detail:

End-to-end Tracebility

Go has a very neat integration with Mingle now that allows you to compare two builds and see how they differ from both a changeset/pipeline dependency (what we call materials) and requirements perspective.  So, for example, if I want to create release notes, I can select the currently deployed build, compare it to the new release build, and get bill of materials and a list of all the cards that were worked on in between the two builds (based on the team's checkins).  From that list I can see the state of the items - did they get worked on and finished, did they get worked on and were finished but are now in a state of rework, or did they get worked on but not finished?  Nothing else shows you traceability back to your requirements this way - it's clean and not heavyweight.

Configuration interface

Previously, all configuration in Go was done through XML.  This made several activities, like copying pipeline configurations, before we built templates easier and it also appealed to sysadmin types.  However, many of our customers have asked for a more convenient GUI configuration method.  Go 2.2 has both -- a great GUI for configuring Go and the older XML that some Go customers prefer.

License-free Community Edition

Now you can just download the free Community Edition of Go and go.  There's no need to put in a license.

Go is a tool meant to bring concepts like "DevOps" and "Continuous Delivery" to fruition.  Jez Humble gave some illuminating commentary in his interview with Jullian Simpson.

“Build pipeline” was always a commonly-used variant within ThoughtWorks. But yes, you’re right that we are trying to focus holistically on the problem of delivering software, not just on the development space.  So continuous integration is still important, but – as the DevOps movement correctly asserts – unless you work to change the rest of the organization, and in particular the relationships between development, testing, and operations, you’re not actually going to see the results that you want to. In most places, the main delivery risk isn’t in getting the software dev complete, it’s in the “last mile” from dev complete to release."  

... [There is functionality in Go that] none of the other free products have. For example, there is built-in test reporting that lets you throw a bunch of automated tests at the build grid and tells you which ones are currently broken, which check-in broke each one, and who was responsible for that check-in – i.e. what’s broken and who broke it. We’re going to continue adding stuff to the Community Edition to keep it the best possible tool for developers, based on our own experiences dog-fooding it.

The classic process-chaining model that the other tools follow is very flexible, but it’s hopeless at getting any idea of the bigger picture of what’s going on in your organization, or seeing where a particular build went, or tracing back from a particular deployment back along the process it came through and who touched it. As a result of its model, Go is somewhat opinionated about how you do things. For example it expects you to promote binaries rather than source code. But I believe that’s a good thing – the tool should make doing the right thing easy.

Keep an eye out for DZone's own interview with Jez Humble on the state of DevOps and Go 2.2.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}