Configuring Hudson to deploy a build

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

Answer 1

I have several hudson jobs per projects:

1. A main job that just builds the project and runs the tests. If it succeeds, it launches the following jobs:
2. A code metrics job (PMD, FindBugs, Cobertura, CheckStyle, also JavaDoc generation) and
3. A deploy job that builds the project using mvn package -DskipTests and deploys the war on tomcat

I find that separating these made things easier, only the first job listens for SCM changes.

However, another way would be to let the 3rd job also listen to the SCM (but with a longer interval, perhaps an hour).

Answer 2

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.