I don’t have a uportal specific answer, but if you want a Java generic answer, I can offer.
Note, I just read Eric's overlay email, so my email is probably a generation back (maven vs ant :) ). Not sure exactly what the pros and cons are. I think there might not be something in each Java software for this since each institution has different envs and different things that vary in various envs. For Internet2 Grouper and Kuali Rice this is what I do: 1. Make a build of the software (uportal). Expand this War to your filesystem 2. Identify what files are different in various environments, move them to an "env specific" folder. Substitute the parts of the files which differ per env with ant variables (e.g. @someVar@ ) 3. Make a build.properties which has the values for each var for each env 4. Make a build.xml which builds the envs in one build and substitutes the vars 5. Commit everything to a local CVS or SVN (so you can track changes and have an institutional central system of record) 6. Make a sync script which syncs a new expanded build of uportal to your CVS/SVN project (this is for uportal upgrades). After this you can compare the files to your CVS/SVN and remove the files which differ per env, etc when you upgrade Grouper has a bunch of wars in each env (might be more complicated than what you are doing), here is the documentation and examples of the build script and properties file. Doc https://spaces.internet2.edu/display/GrouperWG/Managing+Grouper+in+several+environments build.xml https://spaces.internet2.edu/download/attachments/11081389/build.xml build.example.properties (this is committed to local cvs/svn, maybe you don’t copy the real one since it might have passwords in it) https://spaces.internet2.edu/download/attachments/11081389/build.example.properties Regards Chris -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of John A Parker Sent: Wednesday, June 30, 2010 9:49 AM To: [email protected] Subject: [uportal-dev] Deployment Strategies... I'll admit it up front... I'm old school. Take that into account while considering the following. We're new to uPortal 3.2.1 having been on v2.5.3. for years. Our standard Tomcat deployment platform involves a stack starting at the OS (in our current case being 64bit RHEL5 on VMs) and topping off at the Tomcat container (for uPortal Tomcat v6.0.26, but for other applications - Tomcat v5.5.28). This stack is the basis for our "hosted" Tomcat offerings to the Cornell University community. As far as uPortal 3.2.1: We've gotten through the process of building our own copy of uPortal.ear, manually extracting its components (the various .wars and .jars), and then deploying these pieces into our Tomcat container. Everywhere that I read of deployment strategies (for new instances or for new/altered components) I keep finding the approach is to use ant/maven to build and deploy. (This seems to even include the introduction of new skins.) Unless I block maven's automatic download of updated source it seems to me I'm faced with builds containing more changes than I intend. It also seems like I need to do builds on every server I plan on instantiating a new uPortal instance (dev, test, prod, ...). My questions/concerns are these: Is there no way to make controlled changes to the application stack? For example: I want to introduce an update to a Cornell skin. Is there no way to make JUST that change to my instances? Is there no way to build and deploy JUST the modules affected by updates/fixes/etc. without replacing our entire application with recompiled objects whose only difference is the date stamps put into them by the compiler? If I want three instances that are identical EXCEPT for a handful of know configuration files, why would I want to do three builds? Why not make a "gold copy" and reuse it? As you can tell, I want rigid control over changes to my deployments. It just feels like this build-to-deploy approach is looser than I'm comfortable with. Thoughts? John -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
