Question

I’m trying to configure Hudson so that I will be able to automatically deploy a build (a .war file) to Tomcat. The newly deployed build will then be used by someone to test the application.

I’ve tried using the Deploy Plugin to automatically deploy the .war file, and this works. However, the job that builds the .war file will run after every scm change (whenever code is committed). With the Deploy Plugin, the .war file would be deployed to Tomcat every time a build is made. Because code is commited frequently, this will mean that the web application will be restarted frequently as well, and this will interrupt the testing process.

I appreciate the fact that Hudson runs my unit-tests and makes a build regularly, so I don’t want to change the triggers for this job.

I am looking for a way that I can manually decide to deploy from within Hudson. I tried creating a separate job that will deploy the .war from the first job, but this didn’t work. Does anyone have any experience setting something like this up?

Answer 1

How to get the artifacts

Look at the section “How to rollback or redeploy a previous build” on the Deploy Plugin Page. It describes the basic idea. It uses the Copy Artifact Plugin to copy the artifacts from the build job to your current job (the deploy job). From there you do the same that you did in your build step.

How to trigger the deploy

The build job can not be triggered after you start the deploy so that first a build runs and than the deploy job. So there a a few options:

• manually trigger the build. The user that starts the deployment needs to select a specific run of the build job.
• scheduled deployment This could be part of the nightly tasks. The job gets triggered at a certain interval (like every night or every weekend). Since it is automated, the deploy job should pick up the last successful build (you don’t need a parametrized job then). You don’t have a chance to pass in a run number.
• the deploy job gets triggered every time a build finishes successful (doesn’t fit your requirement, but listed to complete the list)
• Some other (esoteric) trigger. This can be many different thinks e.g. remotely triggered by calling the the build URL. The call can come from one of your ticketing systen, test lab management system, or any other system you like. You can also trigger the deployment, by specific changes in your source control system, like changing the release number (e.g. marked by a keyword in the commit message). This trigger can be implemented within or outside of Hudson. There are other triggers available too. This includes but is not limited to html page change, change on a monitored part of the file system, IM message, email. The first three are implemented by a Hudson plugin. Have a look at the plugin list, to know what is all evailable
  or In both cases you need to make sure that the build job archives all artifacts needed for deployment.