Separate Building from Deployment with Hudson

Question

We have started using Hudson, and the current workflow is:

checkout locally > code > run tests > update > run tests > commit

Rather that polling, Hudson simply sits there until we instantiate a build. It then:

checkout locally > run Phing script

The Phing script then:

svn export latest revision > run tests (if successful) > generates reports etc.. > compresses export > scp to production server > .. do magic to make site live...

That all works fine and dandy, however it doesn't really give us the ability to any kind of of "staging" QA and every build builds the repo head revision. Ideally we would like Hudson to poll or use post commit hooks build each commit and:

checkout locally > run Phing task to run tests and if successful, generates reports etc..

Then be able to manually instantiate an automated deployment (via Phing task) to either "staging QA environment or production from with each specific build. Not every commit will be deployed to QA.

Is this work flow even possible from with Hudson, or are we going to need to manually run our deployment Phing tasks after.

Jagir

Answer 1

I ended up doing something similar to Peter Schuetze suggestion. I used only the only job however. I use 3 build parameters, deploy (bool), environment (choice) and revision (text). I then altered my Phing scripts to only do deployments if the deploy parameter is true, in which case it will deploy the specified revision to the specified environment. By default deploy is false, revision is head and environment is staging. Now when Hudson polls svn, it sees the deploy parameter is false and bypasses the deployment tasks.

Jagir

Answer 2

I separated the build/test job (job1) and the deploy job (job2). Job1 runs on trunk after every commit (Hudson polls, but post commit hook would work as well). It also archives the build artifacts. Job2 will be started manually. It gets the build_number from job1 as a build parameter (I like the run parameter) and downloads the artifacts from job1, into it's own workspace. It them runs the deployment. In you case I would add another parameter (choice parameter) to determine to what environment you want to deploy.

With the description setter plugin, you can print out the run number from job1 and the environment and you can than easily see in the job history what build was deployed when to what environment.

Krissykrista

I ended up doing something similar. I used only the only job however. I use 3 build parameters, deploy (bool), environment (choice) and revision (text). I then altered my Phing scripts to only do deployments if the deploy parameter is true, in which case it will deploy the specified revision to the specified environment. By default deploy is false, revision is head and environment is staging. Now when Hudson polls svn, it sees the deploy parameter is false and bypasses the deployment tasks. – Jagir

I want to do the same, as I'm new in Jenkins/hudson, can you give more technical details if possible? – Rennarennane

Where do you struggle? First create a build job. That should give you some hands on experience to ask more specific questions (which probably should be it's own question and not a comment to an answer). – Krissykrista

I created a "Multi-configuration project name" and added just one parameter for now "environnment" with two choices : dev and prod – Rennarennane

A Multi-configuration project is for running several tests at the same time. E.g. you want to run a build for Windows, Linux, and your favorite UNIX. It will start a build for each of the configuration choices. What you probably want is a free-style software project with parameters. Then you can run either a dev or a prod deployment. – Krissykrista

Thank you Peter, I already asked a stackoverflow question (#21240734) that still without any resposnse :(, I added my repository in "subversion" part, I added "Publish Over FTP" plugin to send my changed files (how can I asking svn about that? ) by FTP after builds. what should I do after that? – Rennarennane

Answer 3

I'm not entirely clear on what you want to achieve, but I'm wondering whether you are using the Phing plugin? Perhaps what you want is not currently possible through Hudson and may require changing your development process to make it possible.

Kavanagh