I have ci, so our staging environment builds itself.
Should I have a script that not only builds production but does all the branching for it as well?
When you have 1 code base on 2 different urls with skinning, should they be required to build at once?
views:
154answers:
4In my opinion anything the computer is capable of doing automatically it should do, because it can do it faster, easier and without thought from you. Within reason of course, but stuff like that can be very trivial to automate, so I've always been a proponent of automating that whole process.
and plus it can be fun too!
The only way to be too automated is if you are spending more time fighting with building or fixing automation scripts than you would just doing the job manually. As long as your automation scripts take less time and produce fewer errors than doing the job manually, then automation is great.
Scripts to build and branch for production are a great idea!
I like to separate the build and deploy steps into two separate steps. The output of the build step should be a package that is placed in a repository or staging area. This package should be independent of the target environments.
The deploy step is responsible for configuring the target environment and installing the package.
The reasons I prefer this approach are:
- I have one package that can run in my development, test and production environments. That should cut down the arguments between QA and development.
- There may be different elements that need to be configured during deployment. Application server settings, database schemas, data loads, etc. that might not be as easy to do from the automated build script.
In my opinion it's only too automated if no one in your production support group can deploy an application manually in a pinch. Automated deployments really cut down on simple but common errors such as configuration mistakes. However, a manual deployment must always be an option.