Building for different environments - how do _you_ do it?

[EJ Ciramella <ej...@upromise.com>]

So how are other people building for both dev and other environments?

 

For example, how does one support multiple environments like the
following:

 

1 - Dev integration

2 - QA stack 1

3 - QA stack 2

4 - QA stack 3

5 - Staging

6 - Prod

7 - local developer builds

 

How do other people support variables that can be the same from local
builds through production but support the option to change them at the
last minute?  Are people building multiple version of say an ear
deployment to support all the different environments?

RE: Building for different environments - how do _you_ do it?

["Beelen, M. - SPLXL" <Ma...@klm.com>]

Hello,

Although my personal option is that you should have 1 build for all your
environments and configure all environment specific issues within that
environment (using JNDI or config.properties), there are other options.

On SpringONE'07 Joris Kuipers gave a presentation about this topic.
Some information about that is available in his blog. [1]
Read "Code samples from SpringOne 'Beyond the obvious' talk"

(Since you're in EAR/WAR-land, his posting about "Using a shared parent
application context in a multi-war Spring application" might be of
interest to.)

With kind regards,
  Marco Beelen
  Software Engineer
  IPROFS 

[1]: http://blog.springsource.com/main/author/jkuipers/




-----Original Message-----
From: EJ Ciramella [mailto:ejciramella@upromise.com] 
Sent: Wednesday, June 04, 2008 2:32 PM
To: Maven Users List
Subject: RE: Building for different environments - how do _you_ do it?

Can you expand on this or is there an example of this some where?

We ARE in ear/war land though...

-----Original Message-----
From: Dave Feltenberger [mailto:dave.feltenberger@gmail.com]
Sent: Tuesday, June 03, 2008 11:43 PM
To: Maven Users List
Subject: Re: Building for different environments - how do _you_ do it?

Another possibility, if you're not in a J2EE container and don't
necessarily have access to JNDI (or don't want to rely on server config
vs. a self-contained JAR/WAR) is to package all the environment
configurations together and use something like Spring and an environment
variable to filter a context or properties file.  I've found this to be
very useful, as the same artifact can be deployed in dev, prod, staging,
qa, etc. without having to re-build and risk potential differences in
the artifacts.

Dave

On Tue, Jun 3, 2008 at 2:22 PM, Paul Davis <pa...@gmail.com> wrote:

> The best thing is to NOT create a different build for different 
> environments.
>
> When environment specific stuff is needed (EARs and WARs) look up the
info
> from JNDI and put that configuration on the server.
> Then if something needs to change, you don't need to create a new
build.
>
> If you have to do it, you could probably create a profile for each 
> environment setting a variable.
> Then the files specific to that environment could be "filtered" based
on
> the
> value of that variable.
> You'd just specify the profile to use when creating the build.
>
> On Tue, Jun 3, 2008 at 11:14 AM, EJ Ciramella
<ej...@upromise.com>
> wrote:
>
> > So how are other people building for both dev and other
environments?
> >
> >
> >
> > For example, how does one support multiple environments like the
> > following:
> >
> >
> >
> > 1 - Dev integration
> >
> > 2 - QA stack 1
> >
> > 3 - QA stack 2
> >
> > 4 - QA stack 3
> >
> > 5 - Staging
> >
> > 6 - Prod
> >
> > 7 - local developer builds
> >
> >
> >
> > How do other people support variables that can be the same from
local
> > builds through production but support the option to change them at
the
> > last minute?  Are people building multiple version of say an ear 
> > deployment to support all the different environments?
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286 
**********************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Building for different environments - how do _you_ do it?

[EJ Ciramella <ej...@upromise.com>]

Can you expand on this or is there an example of this some where?

We ARE in ear/war land though...

-----Original Message-----
From: Dave Feltenberger [mailto:dave.feltenberger@gmail.com] 
Sent: Tuesday, June 03, 2008 11:43 PM
To: Maven Users List
Subject: Re: Building for different environments - how do _you_ do it?

Another possibility, if you're not in a J2EE container and don't
necessarily
have access to JNDI (or don't want to rely on server config vs. a
self-contained JAR/WAR) is to package all the environment configurations
together and use something like Spring and an environment variable to
filter
a context or properties file.  I've found this to be very useful, as the
same artifact can be deployed in dev, prod, staging, qa, etc. without
having
to re-build and risk potential differences in the artifacts.

Dave

On Tue, Jun 3, 2008 at 2:22 PM, Paul Davis <pa...@gmail.com> wrote:

> The best thing is to NOT create a different build for different
> environments.
>
> When environment specific stuff is needed (EARs and WARs) look up the
info
> from JNDI and put that configuration on the server.
> Then if something needs to change, you don't need to create a new
build.
>
> If you have to do it, you could probably create a profile for each
> environment setting a variable.
> Then the files specific to that environment could be "filtered" based
on
> the
> value of that variable.
> You'd just specify the profile to use when creating the build.
>
> On Tue, Jun 3, 2008 at 11:14 AM, EJ Ciramella
<ej...@upromise.com>
> wrote:
>
> > So how are other people building for both dev and other
environments?
> >
> >
> >
> > For example, how does one support multiple environments like the
> > following:
> >
> >
> >
> > 1 - Dev integration
> >
> > 2 - QA stack 1
> >
> > 3 - QA stack 2
> >
> > 4 - QA stack 3
> >
> > 5 - Staging
> >
> > 6 - Prod
> >
> > 7 - local developer builds
> >
> >
> >
> > How do other people support variables that can be the same from
local
> > builds through production but support the option to change them at
the
> > last minute?  Are people building multiple version of say an ear
> > deployment to support all the different environments?
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Building for different environments - how do _you_ do it?

[Dave Feltenberger <da...@gmail.com>]

Another possibility, if you're not in a J2EE container and don't necessarily
have access to JNDI (or don't want to rely on server config vs. a
self-contained JAR/WAR) is to package all the environment configurations
together and use something like Spring and an environment variable to filter
a context or properties file.  I've found this to be very useful, as the
same artifact can be deployed in dev, prod, staging, qa, etc. without having
to re-build and risk potential differences in the artifacts.

Dave

On Tue, Jun 3, 2008 at 2:22 PM, Paul Davis <pa...@gmail.com> wrote:

> The best thing is to NOT create a different build for different
> environments.
>
> When environment specific stuff is needed (EARs and WARs) look up the info
> from JNDI and put that configuration on the server.
> Then if something needs to change, you don't need to create a new build.
>
> If you have to do it, you could probably create a profile for each
> environment setting a variable.
> Then the files specific to that environment could be "filtered" based on
> the
> value of that variable.
> You'd just specify the profile to use when creating the build.
>
> On Tue, Jun 3, 2008 at 11:14 AM, EJ Ciramella <ej...@upromise.com>
> wrote:
>
> > So how are other people building for both dev and other environments?
> >
> >
> >
> > For example, how does one support multiple environments like the
> > following:
> >
> >
> >
> > 1 - Dev integration
> >
> > 2 - QA stack 1
> >
> > 3 - QA stack 2
> >
> > 4 - QA stack 3
> >
> > 5 - Staging
> >
> > 6 - Prod
> >
> > 7 - local developer builds
> >
> >
> >
> > How do other people support variables that can be the same from local
> > builds through production but support the option to change them at the
> > last minute?  Are people building multiple version of say an ear
> > deployment to support all the different environments?
> >
> >
>

RE: Building for different environments - how do _you_ do it?

[EJ Ciramella <ej...@upromise.com>]

I wrote a plugin that looks at a combination of profiles
(localdev+generalstackinfo+stack+machine type combo) that generates a
property file which is used by ant (which is what we're using for
deployments).  You do this once and then manage the settings inside the
pre-generated property file.

This is a recent change as we were doing what you're talking about
(generating multiple zip files for all different environments).  Our
build was taking ~3 hours.  The property file method takes roughly 26
min (as there's no generation.

The hard part is propagating developer settings that are valid through
to production, you can't use filters because they take precedence over
profiles and when two disparate projects connect to the same db (for
example), where do you put that setting?  You can't just put it in
profiles.xml otherwise you have a duplicate from project to project. 

-----Original Message-----
From: Paul Davis [mailto:pauledavis@gmail.com] 
Sent: Tuesday, June 03, 2008 2:22 PM
To: Maven Users List
Subject: Re: Building for different environments - how do _you_ do it?

The best thing is to NOT create a different build for different
environments.

When environment specific stuff is needed (EARs and WARs) look up the
info
from JNDI and put that configuration on the server.
Then if something needs to change, you don't need to create a new build.

If you have to do it, you could probably create a profile for each
environment setting a variable.
Then the files specific to that environment could be "filtered" based on
the
value of that variable.
You'd just specify the profile to use when creating the build.

On Tue, Jun 3, 2008 at 11:14 AM, EJ Ciramella <ej...@upromise.com>
wrote:

> So how are other people building for both dev and other environments?
>
>
>
> For example, how does one support multiple environments like the
> following:
>
>
>
> 1 - Dev integration
>
> 2 - QA stack 1
>
> 3 - QA stack 2
>
> 4 - QA stack 3
>
> 5 - Staging
>
> 6 - Prod
>
> 7 - local developer builds
>
>
>
> How do other people support variables that can be the same from local
> builds through production but support the option to change them at the
> last minute?  Are people building multiple version of say an ear
> deployment to support all the different environments?
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Building for different environments - how do _you_ do it?

[Paul Davis <pa...@gmail.com>]

The best thing is to NOT create a different build for different
environments.

When environment specific stuff is needed (EARs and WARs) look up the info
from JNDI and put that configuration on the server.
Then if something needs to change, you don't need to create a new build.

If you have to do it, you could probably create a profile for each
environment setting a variable.
Then the files specific to that environment could be "filtered" based on the
value of that variable.
You'd just specify the profile to use when creating the build.

On Tue, Jun 3, 2008 at 11:14 AM, EJ Ciramella <ej...@upromise.com>
wrote:

> So how are other people building for both dev and other environments?
>
>
>
> For example, how does one support multiple environments like the
> following:
>
>
>
> 1 - Dev integration
>
> 2 - QA stack 1
>
> 3 - QA stack 2
>
> 4 - QA stack 3
>
> 5 - Staging
>
> 6 - Prod
>
> 7 - local developer builds
>
>
>
> How do other people support variables that can be the same from local
> builds through production but support the option to change them at the
> last minute?  Are people building multiple version of say an ear
> deployment to support all the different environments?
>
>