Why version configuration?
Fully versioned configuration is a prerequisite for fully automated deployment. By fully automated deployment, we mean the ability to deploy to a set of machines (physical, virtual or cloud) having nothing but a basic level of provisioning (OS, hotfixes, basic network and disk config).
This is a topic by itself *. Many of us don’t have this level of automation. That’s ok. It is a journey. Some of us use golden images with basic application infrastructure (web servers, load balancers, caches, databases etc) already set up. On top of this we may run deployment scripts using rake, powershell, capistrano, fabric, ant, maven etc.
In all of the above scenarios, Go’s command repository can come handy.
Enter command repository
This a new feature introduced as part of release 13.1. It is an enhancement to Custom Commands in Go. Rather than start from scratch with command name and arguments, you now have the option to look up a command from a repository of useful commands maintained by the Go team. The lookup provides a starting point, you may need to edit the arguments, specify a working directory etc. Once saved, the behaviour is the same as a manually entered custom command.
Go-server looks up these commands from a bundled repository that is a clone of https://github.com/goteam/go-command-repo (contributions welcome)
You might think, “But these are all inline commands. Where are the version controlled scripts?” Good point. The default public repository only hosts commonly used commands in an inline fashion. They are good for experimentation and getting the command right for your situation. If you are already past this stage, simply switch to a private repository. Note that in this mode (no inline commands), we’ll be using this feature not so much as a command repository but rather as a searchable annotated index of configuration scripts.
A searchable annotated index of configuration scripts
Switch to a private repository to use your own set of commands. As a somewhat simplistic example, say you have an existing repository of config scripts organized like this:
.
+-- app-x
¦ +-- build
¦ +-- deploy
¦ +-- provision
+-- app-y
+-- build
+-- deploy
+-- provision
Simply create a parallel hierarchy like this to hold the annotated index.
.
+-- app-x
¦ +-- build
¦ +-- deploy
¦ +-- provision
+-- app-y
¦ +-- build
¦ +-- deploy
¦ +-- provision
+-- cmd-repo
+-- app-x
¦ +-- build
¦ +-- deploy
¦ +-- provision
+-- app-y
+-- build
+-- deploy
+-- provision
For app-x/build/buildfile, create a corresponding index entry under cmd-repo/app-x/build/buildr.xml with contents:
<!--
name: build app-x
description: clean and build app-x with buildr
keywords: app-x, build, buildr
-->
<exec command="buildr">
<arg>-f</arg>
<arg>app-x/build/buildfile</arg>
<arg>clean</arg>
<arg>build</arg>
</exec>
Clone/checkout the repo on the Go server and point Go to look under $server_root/db/command_repository/my-pvt-repo/cmd-repo. Now, when you need to create a task in Go, you can simply lookup build, buildr or app-x. Don’t forget to add the config-script-repo as a material to the corresponding pipeline. Please refer to the product documentation for more detail.
*Further reading: