Thanks for the info, very enlightening. This full process sounds like something I could "work up to" - I like the multiple checks(env tests). I could remove dev/qna1(presumably since I'll do that stuff during my dev), but qna2 & staging are great ideas that I'd not considered. I could really hammer away at the production database and check results/debug without actually impacting everyone who's using the system!
--Jonathan
Tim Funk wrote:
There should be no reason you are not able to do all your development on a windows laptop. That being said ... here's how we do things ...
When possible all code is written and compiled on our Windows laptops. If anyone wants to look at the latest revision of code - they need to run it off their laptop.
For developer integration testing - all the code is tagged (in CVS) by the configuration manager. (CM) (An alternative fancy word for release manager) The CM tags the appropriate files for the development sandbox. From there developer integration testing may occur. This environment is built entirely from verion control. Files do not enter this environment unless they went through CVS.
For QNA work the CM will once again tag the files to be able to our QNA environment. Here is where the users test. We actually have 2 QNA environments running off the same source code base. Why 2? Because one QNA instance points to a development database while the second instance points to a replica of the production database. Two databases (still not counting production) are needs since some QNA testing cannot be done without changing the production database first (where the changes get replicated back to the TEST database).
Once acceptance testing is done - we have a staging environment. (Code gets here the same way, tag in CVS then build from source) This is a mirror image of the production server except for the database pointing to a replica of the production database(same one that QNA points to). This is a mirror image! If we ever get a bug report against production - we should be able to reproduce it in staging. (This allows us to make changes - confirm there are OK in a staging sandbox and reliably move them to production).
Then we have the production box.
Each instance above is its own dedicated tomcat - where each tomcat could be a different version if needed. (Think about your upgrades)
If you hae enough memory available you can easily run your dev, 2 qna, and staging instances on the same machine. Unless you have a lot of developers and a lot of testers - the load on that box is not going to be high. This also assumes your databases are different machines too. Running a database and application server on the same box is a quick way to run out of resources.
So in summary, before code makes it to production it can be tested in the following environments:
- Laptop
- dev - developer integration
- qna1 (dev database)
- qna2 (production database replica)
- staging
It sounds like a lot of environments and a lot of paperwork but CVS + ANT plus a shared build philosphy makes this very manageable.
-Tim
Jonathan Wilson wrote:
This is a general "How do you develop a webapp with tomcat/ant with a different development/production server"
I'm trying to setup my development environment so that I have a development version of my webapp, and a production version of my webapp. My webapp has corporate-wide responsibilities(in a 24-7 environment) and requires very little downtime. Up to now I've managed to do development tasks on the running version(with a few hickups), but I need to start making larger feature changes that I can fully test, without restarting the server and kicking everyone with a session off the system while doing their work.
I now understand how ant can help me deploy for different targets, but how do I develop code and test it(without producing all the notification emails, updates to the database, etc) in my development-server and then "turn this debug code off" in the production-server when it's deployed?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
