Deployment – Should the Deploy Script Be an Artifact of the Build?

buildsdeploymentJenkins

This is a web project written in Java.

So, I'm writing the build and the deploy scripts. To create the build, I used ant. The continuous build is done with Jenkins.

The build generates 3 different artifacts:

  1. The war file
  2. A zip with layouts
  3. A zip with images

So far, so good, but now I need to write the deploy script, which should:

  • Deploy the war (artifact 1) to the tomcat running at server 1
  • Place the artifact 2 at server 1 in a specific directory
  • Place the artifact 3 at server 2 in a specific directory

So I was talking with my colleague and he said that we should also generate an artifact (maybe deploy.xml) that deploys these artifacts when placed at the correct server.

So there would be another script, that would:

  • Download the jenkins artifacts
  • scp to each server and place the deploy.xml there
  • remotely invoke the deploy.xml

What makes me a little uncomfortable is the act of having the deploy.xml as a build artifact. The motivation behind this would be to be able to make a deploy without needing to have access to the VCS repositories, so a build would be self-contained, ie, any build could go into production only with what was generated by Jenkins.

Where should the deploy scripts be placed? Should they be only at the VCS or should they be build artifacts too?

Best Answer

My experience is that everything that can be automated should be. If you can describe it as step 1, step 2, .... then it should be a script. If the script can be auto-generated to include build specific info (e.g. revision tag), then that's what you should do. This is not for the sake of being lazy, but for the sake of being predictable and reproducible.

Note bene: you should also have an auto-generated revert script that can be used by anyone on the team in case the auto-generated deploy script goes bat sh*t crazy and hoses the production server.

Related Topic