Forgot to mention - I have a coworker who came from a company where they had a very complex deployment with clusters and many different applications sharing configuration. There they had a central configuration server where all the applications programmatically could look up configuration parameters. Something like this takes a lot of commitment across development teams, but maybe something like this would work for you.
On 8/6/08, Ken Liu <[EMAIL PROTECTED]> wrote: > > 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] >> >> >
