Beauty and the Beast
Creative Commons License photo credit: eyesore9

SCP And SSH

This is the second part of my brainstorming "session" about automating software deployment and execution on a remote computer from yesterday. I did some investigation and found a very useful resource (part of the Paul Duvall’s excellent "Automation for the people" series) about patterns for automatic deployment (also see the newest article here). Also check out SmartFrog’s Patterns Of Deployment, which covers deployment topics extensively.

Paul’s approach is to use SCP for secure copying (distributing) of files and SSH for remotely invoking processes. The advantages I see in this approach are that it uses standard protocols and is very flexible, including support for public key infrastructure (PKI). The only thing is that I don’t know which tools to use for Windows for SCP and SSH – I’m looking for free software which would be easy to set up both for clients and for servers. And by "easy set up" I don’t mean MSI installations – I would like a simple copy and run type of installation.

A commenter Jean-Philippe Daigle also suggested among other things using rsync for publishing new build packages to other servers. There is also an rsync alternative for Windows called Unison. Again, I’m not sure how much work is needed to set these things up before using them for CI purposes. And also I see a problem of using a bunch of tools each of which solves only a part of the problem – from my experience this results in a CI setup which is fairly brittle.

Feedback Problem

I thought a little about how the continuous integration (CI) process would look like if I implemented an Agent service described in the previous article. The main problem I detected was the lack of good feedback from such an Agent – if it were to run our long running integration tests we wouldn’t be able to see the progress like it is possible when using CI servers like CruiseControl.NET (CCNET).

I started looking at the problem from a wider perspective – what we really need is a distributed CI system which would be able to provide control and monitoring of CI builds from a single point. This is opposed to how things are done with CCNET – you have to set up a separate project for each stage of the CI build and you also have to install separate instances of CCNET on each server that is a part of the build configuration (main build server, integration server, database server etc.). This makes setting up CI for a project quite time consuming.

Requirements

So what would this CI system have to have to be useful:

  • CI process should be treated integrally: if the CI process consists of several stages (some of which may run in parallel or even on different computers), it should be treated as a single unit (internally separated into several stages). The configuration would specify the CI workflow and then the CI system would take care of all the necessary wiring. That doesn’t mean that you wouldn’t be able to get the feedback for each individual stage, if you wanted.
  • A single configuration point: the configuration for all of these stages should be located in a single place (in the main build service, let’s call it a Controller), not spread out over several computers.
  • Native support for version-controlled CI project configuration file(s): the Controller should only have to have the basic configuration (like how to fetch files from the version control system (VCS)). The rest of the CI configuration would be retrieved from VCS and thus could be dynamically updated with each new version.
  • A single monitoring point: the Controller would have to provide some kind of Web user interface which would display the status of the CI process (including statuses for all of the CI process’ stages on all other servers). The UI would have to be simple, just displaying raw build outputs (although the support for CCNET-like XSLT transformations could be provided).
  • Minimum installation and configuration friction: all of the CI system’s components should be able to run with minimal prerequisites. Edit the configuration file and run the Controller executable from a command line – this should be enough. I’m thinking about an integrated Web server (so no extra Web server installation would be needed) and automatic pushing of CI Agents to all of other servers which are part of the CI process.
  • Support for automatic deployment: the ability to remotely deploy and run software (the essence of yesterday’s post) as part of a CI process stage should be intrinsic. 

This ends my brainstorming session for today.