Continuous integration and pre-integration

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 th开发者_Go百科e 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?

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

Having done some research on this, I've spent the last few days playing around with CruiseControl.NET. It looks like it can probably do everything I'm looking for, by virtue of its extensibility. There's no obstacle to firing off another plugin at the end of build that does all the deployment and sign-off. Some of the requirements are complicated and take an indeterminate amount of time though, so I think some sort of state persistence like WWF would be valuable. I'll have to experiment and bring it up with my colleagues.

Consider CloudMunch for this. CloudMunch provides a build engine (based on Jenkins), Build progression workflow on top of it to have manual workflow managed on top of it with a clean RBAC support to manage what you are looking at.

Disclaimer: I work at CloudMunch.