Why I Love Go

I was just reflecting a bit on why I like Go (from ThoughtWorks Studios). I had previously been using Jenkins (which I love), and while I still love Jenkins and would happily use it again, here are some of the reasons why Go wins in my book for trying to do continuous delivery.

Recently, Dan Gilmer spoke at ChefConf about how Ancestry.com uses Go and Chef for continuous delivery. Prior to leaving Ancestry.com, I helped pioneer the early use of Go and Chef as an Agile coach for the development teams. Here is Dan's talk:

What I Love About Go

Workflow visualization. I love the idea of separating build pipelines from deploy pipelines, each with their mini-workflows. When I was coaching teams at Ancestry, I always taught them to identify their own business process and then document that as a pipeline and value stream map. The "pipeline" entity in Go is powerful for communicating to developers and product owners the business process they are using. I love the transparency. The caveat though, is that you have to mature as a team to find out the appropriate boundary of what belongs in your build scripts (ant, maven, etc.) versus the tasks of your pipeline stages.

Pipeline groups. I don't use these at Premier Fitness Camp because I'm using the community edition. However, at Ancestry, I loved being able to group pipelines per team and put security on them. Plus, in harmony with my statements above, the group of pipelines represents a boundary around all the business processes a team must use to release its software.

Environments. We didn't mature at Ancestry to my vision of using Environments before I left, but I did really like how the Environments view let you see what version was deployed via a given pipeline. I thought that was very powerful. With the use of configuration management (like Chef) knowledge about environment configuration, including application version, may not be as useful in Go. However, go makes it very transparent which version is in an environment. As long as you model your pipeline label template correctly, and put the right agents in the right place, this could be cool.

If I had the enterprise edition, plus a few remote agents, I'd probably use the Environments view a lot. Currently, I have modeled my deploy pipeline so that it triggers Chef to do the deployment on my remote servers. The pipeline version number matches the produced artifact number and Chef fetches the artifact from Go, so I know from looking at my pipeline group what version is out on a server, even without the Environments view.

Replay a version in the past or replay a failed stage. I love the ability to replay a failed stage in the middle of a pipeline without starting over. I know you can do this with Jenkins because you can just play a job. With Jenkins though, I get the feeling that I'm starting something from scratch rather than picking up the context of the overall pipeline.

What I Miss from Jenkins

Code coverage charts. Jenkins had a plugin for visualizing historical code coverage. In Go, I have to produce these on my own (since a plugin community/capability exists yet) and embed them in as an artifact and a custom tab.

Unit test trending charts. Same as code coverage charts above.