views:

61

answers:

2

I have an automated deployment process for a Java app where currently I'm building the app on a build machine, checking the build into scm, and having the production machine pull the build artifact (which is a zip) and through ant move the class and config files to where they're supposed to be.

I've seen other strategies where the production machine pulls the source from scm and builds it itself.

The thing I don't like about the former approach is that if I'm building for production instead of staging or dev or whatever, I have to manually specify the env in the build. If the target server were in charge of this, though, there would be less thought and friction involved in the build. However, I also like using the exact same build as was being tested on staging.

So, I guess my question is, is it preferred to copy the already build/already tested app to production or to have production build the app again once it's been tested.

+1  A: 

I always prefer keeping as little as humanly possible on a production server - less to update, less to go wrong.

philjohn
+2  A: 

If you already have an automated build system that is creating a testing build, how hard is it to extend that so that it builds both a testing build and a production build at the same time. This way you get the security of knowing they were built from the exact same checked out source and you have less manual labor. I really cringe at the idea of checking built artifacts into SCM!

BryanD