Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
this question is good / it makes us want to plus-one / wish i could answer –  sparkleshy Dec 14 '11 at 17:02
add comment

2 Answers

up vote 6 down vote accepted

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.

share|improve this answer
add comment

All that Peter Rowell wrote, is correct, in addition I would:

For the deploy script file

  • if it was written by someone, it needs to be in version control.
  • if it was generated and can be generated again, it usually does not go into version control.

For the deploy process:

  • If you like your artefacts to be self-contained and if it could be done easily, then the file could be a build artefact, meaning that it's packaged with the build result in such a manner that it's usable for deployment.
  • On the other hand, deployments get more and more complex so sooner or later you will need a dedicated program (read some code) that does the deployment and a Jenkins build artefact is not self contained any more.

This is rather depending on your process and how you like to handle deployments.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.