Skip to content

Instantly share code, notes, and snippets.

@mscottford
Created May 6, 2010 21:48
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mscottford/392746 to your computer and use it in GitHub Desktop.
Save mscottford/392746 to your computer and use it in GitHub Desktop.

Continuous Integration Brainstorm

I spent some time today looking for a good continuous integration server that was ruby friendly and user friendly. I did not like my choices. So I decided that I would come up with my wish list for what I want a CI solution to look like. Here goes.

Problems

This is the list of problems that I would like to solve with a new CI solution. (Yeah! I want to reinvent the wheel!)

  • Is it running?
    • There needs to be a very easy way to determine if the server is running.
  • Need to be able to trigger builds from outside systems
    • Should be able to have an external system tell it to build
  • Need to be able to define detectable events that can trigger a build
    • Should be able to trigger a new build when any of the following happens
      • Check in to remote source control server
      • X amount of time has passed since last build
      • When the clock strikes X
      • A new version of an external dependency is available
        • I have gems in mind when I write this, but I would like for the core design to not care about the type of external dependency. The core design should just know that it needs to check something (anything), and if it has changed, then build.
  • Need to be able to define a build as a series of distributed steps
    • I have two examples in mind for this one:
      • Run all headless test (tests that can run without a gui) on the server, then call out to a remote machine(s) that can run the gui tests. Need to be able to define more than one of these in case they are different operating systems.
  • Need to support a wide variety of source control solutions
    • Once again, I don't want the core design to care about what kind of source control solution is used.
    • The core design should be separated into two different responsibilities:
      • How do we grab the latest copy code.
      • How do we detect if there have been changes. This responsibility should be optional, because it may not be possible for every service.
  • Need to support pushing build results to remotes services.
    • The description is a little vague. What I mean is that the service should be able to send notifications about the result of the build via email, SMS, REST, whatever.
    • As with before, the core design needs to not care about the notification method.
  • Need to support multiple ways to pull build results.
    • I am thinking of several, RSS, HTTP status codes ala CI Joe, JSON, XML, a simple web page
  • Needs to be very easy to configure
    • Dead simple, as few options as possible
  • Needs to be very multi build system friendly
    • Support for rake, ant, msbuild, make, shell script, or bash script
  • Needs to be able to run on Linux, Mac OS and Windows

That should cover it, but that is a lot. I need to think more about this, or I just need to start working on some prototypes. If only there were more hours in a day. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment