Continuous integration and pre-integration

Question

I'm posting a part-question, part-rambling in the hope that it will generate discussion as well as answer my question, which is more a series of requirements if I'm honest.

At my workplace, builds are very labour-intensive. This is because our team is very small and there is suspicion that automation will inevitably go wrong because we don't have the expertise in the team to do it properly. This I consider to be a reasonable - but flawed - argument. I do have a middle-manager on my side, who seems to enjoy the concept of automation and has employed numerous small automation features quite successfully.

What I'm aiming to do is tie a sort of automated build environment in with our release system, which requires managers to produce various documentation. This is a requirement of TickIT certification and is not for negotiation. What I am imagining doing is producing a (Windows) Workflow - for which we have IT infrastructure set up and which is familiar company-wide - which prompts the managers for documentation which must be committed in order for a build and release to occur. We are not a software company, we are a company which sells software, so these features need to be pitched at the non-technical.

So in summary, our use case would look something like:

• Manager reviews the task tracker and authorises a release based on current state
• Workflow kicks off, having cached the current SVN revision
• Workflow demands from the project manager a number of pdf documents etc which need to be built into the installation package
• Workflow fires off the build process on the previously cached SVN revision on an integration manager such as CruiseControl (I'm including in this everything that continuous integration does, including unit tests)
• Completed installation packages are automatically installed on various virtual machines (the complete set of supported operating systems and languages) and which are made available to QA
• Upon complete sign-off from QA, installation packages are released to web

Naturally, since nothing ever works properly, the ability to 'break' the workflow and proceed manually at any time should be included, as we don't want release held up by a stupid machine that can't do its job when a bit of common sense would do just as well.

Does anybody have anything which could be considered a case study on this sort of process, or any comments on how straightforward or challenging it might be, or even how appropriate it is?

Answer 1

We solved exactly this problem recently for one of our clients. Our implementation involved the following components (but you can achieve the same with different tools depending on your organisation).

• JIRA workflow - orchestrate the process (and capture performance metrics) manage approvals and track history for auditing
• JIRA plugin - Trigger builds\deployments\tests via CI server (Hudson\Jenkins). Listener: respond to status updates from Hudson\Jenkins
• Jenkins plugin - to interact with JIRA
• build-pipeline-plugin - to manage the Jenkins workflow
• deployment scripts - orchestrated by Jenkins\Groovy

It sounds complex, but a lot of these tools have great APIs to work with, so you can get a stable solution together in a reasonable timeframe.

Cheers,

Geoff