The best practice is to externalize all environment specific configuration. A single ear should be deployable to any environment without rebuilding. This is not just to simplify configuration, it is also beneficial from a QA standpoint because a binary can be moved between different environments dev->qa->uat->prod without the possibility of introducing defects as a result of a bad build.
In my workplace, we build a single EAR that can be deployed in one of many (half dozen) environments, and then the specific configurations for each environment are managed/packaged separately using assemblies. At deployment time, these assemblies are unzipped (we don't automatically deploy apps for various reasons), and the EAR is dropped into the app server deploy directory. We do have the problem you mentioned of copy/paste between configuration files. It's not enough of a problem for us to warrant a more sophisticated approach, but if we did need it, we would probably use filtering or some similar mechanism to generate the configuration/property files from a template. Ken On 7/31/08, EJ Ciramella <[EMAIL PROTECTED]> wrote: > > This only hints at solutions to #2 below: > > > 2 - How does one deploy said generated application zip/tar file? > > There's nothing I can see supplied in any plugin to support large > scale > > deployments (say, six app servers, four web servers, a db server, a > > utils server and another half dozen or so third party servers). We've > > been using ant and an internally written shell script. > > Yes, we drop maven once the build is headed anywhere other than the > local machine - but even within this developer environment, how do you > share properties/configuration/etc across different applications without > massive copy/paste duplication? How does anyone build to support > multiple environments? Are you really rebuilding the ear with a > different configuration? Is your ear over say, 20 mb? > > Are people just NOT building this level of complexity within maven? > > Even if the configuration/profiles was pushed out into a "corporate" pom > (something outside of the general project structure), if/when that > changed, you'd have a million poms to update to point them to a new > parent version. > > -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 31, 2008 4:48 PM > To: Maven Users List > Subject: Re: Maven 'deploy' relationship to large-scale software > deployment > > I think you'll find that Maven itself stops at the repository. So the > best thing to do is to use tools that can take artifacts from the > repository and deploy them. > > There are lots of other solutions around for doing this sort of thing > beyond that point and they specialise in handling the new set of > problems it brings. I've generally found those doing the deployment > are very separate from the rest of the development team and often have > their own chosen set of tooling. > > You could use Maven itself to do this - though I'm not aware of any > plugins that focus on this. While Cargo is generally used for test > setups, it could serve this purpose as well, but it's mostly a space > for a new piece of work. > > Cheers, > Brett > > 2008/8/1 EJ Ciramella <[EMAIL PROTECTED]>: > > No, I don't understand how to do it either. I just stepped out of a > > meeting where we were discussing how we can deploy the same set of > > applications (which _some_ share properties) across 10 - 15 different > > environments. Some environments have different configurations, some > are > > carbon copies. > > > > There doesn't seem to be any maven solution to either/all of these > > problems: > > > > 1 - Where does a property go (say db connection string) that's shared > > between different applications such that there isn't duplication? No > > one wants to have to search/replace values in various profiles.xml or > > pom.xml files (I don't mind, but others in the organization have > > objected). Here, since there are so many applications pointed at the > > same db, that could be a dozen or so files that have the same db > string. > > > > 2 - How does one deploy said generated application zip/tar file? > > There's nothing I can see supplied in any plugin to support large > scale > > deployments (say, six app servers, four web servers, a db server, a > > utils server and another half dozen or so third party servers). We've > > been using ant and a internally written shell script. > > > > 3 - How do people configure these things? I've heard every answer > from > > "we generate a zipped/tarred up application file for every > environment" > > to "we use installshield and don't have to worry" and everything in > > between. We have in one environment alone, 6 jboss servers for ONE > > application. That ear that gets deployed there (and all it's > supporting > > files) even compressed in a zip takes close to 200 mb. I'm not about > to > > generate 1200 mb worth of ear files with each build (sometimes there's > > three or more built in a single day). > > > > I feel like either there are different terms to describe these things > or > > no one is doing anything to this scale. > > > > I'd love some feedback/suggestions as to how others are doing this. > > > > -----Original Message----- > > From: stug23 [mailto:[EMAIL PROTECTED] > > Sent: Thursday, July 31, 2008 10:25 AM > > To: [email protected] > > Subject: Re: Maven 'deploy' relationship to large-scale software > > deployment > > > > > > Am I alone in needing to understand how Maven relates to large-scale > > software > > deployment? > > > > :confused: > > > > > > stug23 wrote: > >> > >> Maven has its own notion of 'deploying' a software artifact to a > Maven > >> repository. And there are quite a number of 'out of band' Maven > > plugins > >> such as Cargo that can remotely deploy a war file to a running web > >> container. > >> > >> My question centers on how Maven relates to situations where once a > >> software system has been built and tested, the software components > > then > >> need to be globally distributed to many sites. This notion of > > 'deploying' > >> would appear to be quite different than the one embodied in Maven's > > deploy > >> goal. > >> > >> What experiences have developers here had in leveraging Maven for > >> large-scale deployments? When did you stop using Maven and resort to > >> other solutions for deploying bundled software to many distributed > > sites? > >> Or were you able to use Maven for your large-scale software > deployment > >> right out to the sites? > >> > >> I would be interested in comments on how others have dealt with this > > part > >> of software deployment. My use case involves distributing 10s of SOA > >> services and web applications to many sites. > >> > > > > -- > > View this message in context: > > > http://www.nabble.com/Maven-%27deploy%27-relationship-to-large-scale-sof > > tware-deployment-tp18717756p18755789.html > > Sent from the Maven - Users mailing list archive at Nabble.com. > > > > > > --------------------------------------------------------------------- > > 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] > > > > > > > > -- > Brett Porter > Blog: http://blogs.exist.com/bporter/ > > --------------------------------------------------------------------- > 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] > >
