You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Hayward Lam <hl...@carms.ca> on 2008/11/06 20:46:31 UTC
Release Management Questions
Hi all,
We have in-house maven projects. The build requires environment specific
property replacement (i.e. dev, qa and prod) and we set up profiles for
them. When the project has been tested and is ready for release, we can
deploy the artifacts (dev, qa and prod) to our internal maven
repository.
My questions are:
1) Is there some sort of release management tool that can automate
this process?
2) We use Hudson for continuous integration. The configuration will
be based on each environment only (i.e. -P env-dev). So, each build will
have its own build number. Is there some consolidated way to do this?
i.e. same build number for dev, qa and prod.
3) What is the practice that works for you?
Thanks
Re: Release Management Questions
Posted by Rogier Peters <ro...@gmail.com>.
Do you know about http://maven.apache.org/plugins/maven-release-plugin/ ?
If you need more info I can ping my colleagues who have a similar setup
On Thu, Nov 6, 2008 at 8:46 PM, Hayward Lam <hl...@carms.ca> wrote:
> Hi all,
>
>
>
> We have in-house maven projects. The build requires environment specific
> property replacement (i.e. dev, qa and prod) and we set up profiles for
> them. When the project has been tested and is ready for release, we can
> deploy the artifacts (dev, qa and prod) to our internal maven
> repository.
>
>
>
> My questions are:
>
> 1) Is there some sort of release management tool that can automate
> this process?
>
> 2) We use Hudson for continuous integration. The configuration will
> be based on each environment only (i.e. -P env-dev). So, each build will
> have its own build number. Is there some consolidated way to do this?
> i.e. same build number for dev, qa and prod.
>
> 3) What is the practice that works for you?
>
>
>
> Thanks
>
>
Re: Release Management Questions
Posted by Nikolas Everett <ni...@gmail.com>.
I go by the principal of least calls in the middle of the night and tend to
keep my configuration in two places: Administrative and Internal.
I externalize some stuff like jdbc connection strings, username, passwords,
etc into administrative configuration. These have to change if your
environment changes, might be different in different deployments, and maybe
shouldn't be known by the software developers. You don't want system
administrators calling you if they have to move a deployment or fail over a
database or something.
I keep hand coded SQL or anything else where you can break the application
by tinkering in the internal configuration which is loaded from the
classpath.
Sometimes its a good idea to expose tuning stuff like thread pool sizes and
batch sizes. This violates the phone call rule, but can be a life saver.
On the other hand, I can definitely see how it is nice to just check one
thing into subversion and let another team deploy it.
On Fri, Nov 7, 2008 at 8:10 PM, Geoffrey Wiseman <geoffrey.wiseman@gmail.com
> wrote:
> On Fri, Nov 7, 2008 at 3:45 PM, Rusty Wright <ru...@gmail.com>
> wrote:
>
> > What are the pros and cons for this?
> >
> > I feel more comfortable having everything in the war file, because then
> if
> > I change one of the properties files all I have to do is rebuild, check
> the
> > war file in to subversion, then our release management people check it
> out
> > on the appropriate layer. If the properties file was external then
> that's
> > another file for them to have to deal with.
> >
> > It seems less error prone when the war file is completely self contained.
>
>
> If you've only got one environment or the configuration isn't
> environmental,
> I'd agree; if you're likely to have more than one environment and
> environmental configuration, then I'd argue for configuration to be
> externalized, so that one WAR can live in testing, staging and production
> (or whatever your needs are for multiple environments -- such as multiple
> clients) without needing to be changed and rebuilt.
>
> - Geoffrey
> --
> Geoffrey Wiseman
>
RE: Release Management Questions
Posted by Martin Gainty <mg...@hotmail.com>.
agreed..
Keep it simple with properties files reflecting environment specific attributes..hostname,Ports,JRE,maven-repositories ..
Martin
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.
> Date: Fri, 7 Nov 2008 20:10:38 -0500
> From: geoffrey.wiseman@gmail.com
> To: users@maven.apache.org
> Subject: Re: Release Management Questions
> CC: randy@berkeley.edu
>
> On Fri, Nov 7, 2008 at 3:45 PM, Rusty Wright <ru...@gmail.com> wrote:
>
> > What are the pros and cons for this?
> >
> > I feel more comfortable having everything in the war file, because then if
> > I change one of the properties files all I have to do is rebuild, check the
> > war file in to subversion, then our release management people check it out
> > on the appropriate layer. If the properties file was external then that's
> > another file for them to have to deal with.
> >
> > It seems less error prone when the war file is completely self contained.
>
>
> If you've only got one environment or the configuration isn't environmental,
> I'd agree; if you're likely to have more than one environment and
> environmental configuration, then I'd argue for configuration to be
> externalized, so that one WAR can live in testing, staging and production
> (or whatever your needs are for multiple environments -- such as multiple
> clients) without needing to be changed and rebuilt.
>
> - Geoffrey
> --
> Geoffrey Wiseman
_________________________________________________________________
Color coding for safety: Windows Live Hotmail alerts you to suspicious email.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety_112008
Re: Release Management Questions
Posted by Rusty Wright <ru...@gmail.com>.
(Not sure if it's clear from how I said it when I said "In theory it sounds like a good idea, and that's what I did before I started using maven ..." but what I meant was "In theory it sounds like a good idea having the environment specific configuration stuff outside the war file ...")
I think one reason I prefer having everything in the war file is because so far I've whenever I've need to tweak the configuration and I've also needed to tweak the code.
Another is because I've only used tomcat, where you're more likely to directly manage your own configuration stuff.
Thanks for your feedback; it's been good food for thought.
Geoffrey Wiseman wrote:
> On Mon, Nov 10, 2008 at 7:29 PM, Martin Gainty <mg...@hotmail.com> wrote:
>
>> i agree with randy
>>
>> murphy's law applies..
>> if <dev/qa/prod> properties was packaged with the war then you would'nt
>> have to worry about finding it...
>> its always in the war
>>
>
> Honestly, if that works for you, so be it.
>
> I personally don't want to have to rebuild the WAR to reconfigure. I don't
> want operations people to have to dig around inside a WAR or a source
> repository. I want them to be able to take the WAR, drop it somewhere, edit
> a text file and you're done. I want to know that if I build a new version
> of the WAR, I don't have to worry if they've changed configuration settings
> since I last gave it to them. I want to know that if there's a new
> environment, the developers don't need to be involved to get it up and
> running.
>
> These are the kinds of advantages that I feel like i'm getting from
> externalizing the configuration, but there are other ways to go about it.
>
> - Geoffrey
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Release Management Questions
Posted by Geoffrey Wiseman <ge...@gmail.com>.
On Mon, Nov 10, 2008 at 7:29 PM, Martin Gainty <mg...@hotmail.com> wrote:
> i agree with randy
>
> murphy's law applies..
> if <dev/qa/prod> properties was packaged with the war then you would'nt
> have to worry about finding it...
> its always in the war
>
Honestly, if that works for you, so be it.
I personally don't want to have to rebuild the WAR to reconfigure. I don't
want operations people to have to dig around inside a WAR or a source
repository. I want them to be able to take the WAR, drop it somewhere, edit
a text file and you're done. I want to know that if I build a new version
of the WAR, I don't have to worry if they've changed configuration settings
since I last gave it to them. I want to know that if there's a new
environment, the developers don't need to be involved to get it up and
running.
These are the kinds of advantages that I feel like i'm getting from
externalizing the configuration, but there are other ways to go about it.
- Geoffrey
--
Geoffrey Wiseman
RE: Release Management Questions
Posted by Martin Gainty <mg...@hotmail.com>.
i agree with randy
murphy's law applies..
if <dev/qa/prod> properties was packaged with the war then you would'nt have to worry about finding it...
its always in the war
Martin
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.
> Date: Mon, 10 Nov 2008 15:52:40 -0800
> From: rusty.wright@gmail.com
> To: geoffrey.wiseman@gmail.com
> CC: users@maven.apache.org; randy@berkeley.edu
> Subject: Re: Release Management Questions
>
> Ok, thanks.
>
> I still don't see what the problem is with having all of the configuration in the war file.
>
> In theory it sounds like a good idea, and that's what I did before I started using maven, but with maven and its profiles it's too easy to simply make 3 wars for each dev, qa, and prod environment. Having environment specific stuff outside of the war, and it would seem to me, not controlled by the pom, seems like extra, and possibly error prone work.
>
>
> Geoffrey Wiseman wrote:
> > On Sat, Nov 8, 2008 at 1:01 PM, Rusty Wright <rusty.wright@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > But I do have multiple environments.
> >
> > How do you manage the different configuration files for the
> > different environments?
> >
> > Do they have different names and the application figures out which
> > environment it's on and then uses the appropriately named
> > configuration file? I tried that; it's too fragile.
> >
> > Or do the configuration files have the same name on all environments
> > and you have to ensure that the right ones are installed? That's
> > what I'm using now with symbolic links. For example, db.properties
> > is what the app uses but it's a symbolic link to db-dev.properties.
> >
> >
> > I mostly to the latter -- i've experimented with some kind of
> > centralized configuration with discovery, but haven't ended up with
> > something i'm happy with, so I mostly just load configuration from the
> > classpath with a predefined name, and use the container to add the
> > appropriate directory into the classpath in each environment.
> > --
> > Geoffrey Wiseman
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
_________________________________________________________________
Color coding for safety: Windows Live Hotmail alerts you to suspicious email.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety_112008
Re: Release Management Questions
Posted by Rusty Wright <ru...@gmail.com>.
Ok, thanks.
I still don't see what the problem is with having all of the configuration in the war file.
In theory it sounds like a good idea, and that's what I did before I started using maven, but with maven and its profiles it's too easy to simply make 3 wars for each dev, qa, and prod environment. Having environment specific stuff outside of the war, and it would seem to me, not controlled by the pom, seems like extra, and possibly error prone work.
Geoffrey Wiseman wrote:
> On Sat, Nov 8, 2008 at 1:01 PM, Rusty Wright <rusty.wright@gmail.com
> <ma...@gmail.com>> wrote:
>
> But I do have multiple environments.
>
> How do you manage the different configuration files for the
> different environments?
>
> Do they have different names and the application figures out which
> environment it's on and then uses the appropriately named
> configuration file? I tried that; it's too fragile.
>
> Or do the configuration files have the same name on all environments
> and you have to ensure that the right ones are installed? That's
> what I'm using now with symbolic links. For example, db.properties
> is what the app uses but it's a symbolic link to db-dev.properties.
>
>
> I mostly to the latter -- i've experimented with some kind of
> centralized configuration with discovery, but haven't ended up with
> something i'm happy with, so I mostly just load configuration from the
> classpath with a predefined name, and use the container to add the
> appropriate directory into the classpath in each environment.
> --
> Geoffrey Wiseman
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Release Management Questions
Posted by Geoffrey Wiseman <ge...@gmail.com>.
On Sat, Nov 8, 2008 at 1:01 PM, Rusty Wright <ru...@gmail.com> wrote:
> But I do have multiple environments.
>
> How do you manage the different configuration files for the different
> environments?
>
> Do they have different names and the application figures out which
> environment it's on and then uses the appropriately named configuration
> file? I tried that; it's too fragile.
>
> Or do the configuration files have the same name on all environments and
> you have to ensure that the right ones are installed? That's what I'm using
> now with symbolic links. For example, db.properties is what the app uses
> but it's a symbolic link to db-dev.properties.
I mostly to the latter -- i've experimented with some kind of centralized
configuration with discovery, but haven't ended up with something i'm happy
with, so I mostly just load configuration from the classpath with a
predefined name, and use the container to add the appropriate directory into
the classpath in each environment.
--
Geoffrey Wiseman
Re: Release Management Questions
Posted by Rusty Wright <ru...@gmail.com>.
But I do have multiple environments.
How do you manage the different configuration files for the different environments?
Do they have different names and the application figures out which environment it's on and then uses the appropriately named configuration file? I tried that; it's too fragile.
Or do the configuration files have the same name on all environments and you have to ensure that the right ones are installed? That's what I'm using now with symbolic links. For example, db.properties is what the app uses but it's a symbolic link to db-dev.properties.
Geoffrey Wiseman wrote:
> On Fri, Nov 7, 2008 at 3:45 PM, Rusty Wright <ru...@gmail.com> wrote:
>
>> What are the pros and cons for this?
>>
>> I feel more comfortable having everything in the war file, because then if
>> I change one of the properties files all I have to do is rebuild, check the
>> war file in to subversion, then our release management people check it out
>> on the appropriate layer. If the properties file was external then that's
>> another file for them to have to deal with.
>>
>> It seems less error prone when the war file is completely self contained.
>
>
> If you've only got one environment or the configuration isn't environmental,
> I'd agree; if you're likely to have more than one environment and
> environmental configuration, then I'd argue for configuration to be
> externalized, so that one WAR can live in testing, staging and production
> (or whatever your needs are for multiple environments -- such as multiple
> clients) without needing to be changed and rebuilt.
>
> - Geoffrey
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Release Management Questions
Posted by Geoffrey Wiseman <ge...@gmail.com>.
On Fri, Nov 7, 2008 at 3:45 PM, Rusty Wright <ru...@gmail.com> wrote:
> What are the pros and cons for this?
>
> I feel more comfortable having everything in the war file, because then if
> I change one of the properties files all I have to do is rebuild, check the
> war file in to subversion, then our release management people check it out
> on the appropriate layer. If the properties file was external then that's
> another file for them to have to deal with.
>
> It seems less error prone when the war file is completely self contained.
If you've only got one environment or the configuration isn't environmental,
I'd agree; if you're likely to have more than one environment and
environmental configuration, then I'd argue for configuration to be
externalized, so that one WAR can live in testing, staging and production
(or whatever your needs are for multiple environments -- such as multiple
clients) without needing to be changed and rebuilt.
- Geoffrey
--
Geoffrey Wiseman
Re: Release Management Questions
Posted by Rusty Wright <ru...@gmail.com>.
What are the pros and cons for this?
I feel more comfortable having everything in the war file, because then if I change one of the properties files all I have to do is rebuild, check the war file in to subversion, then our release management people check it out on the appropriate layer. If the properties file was external then that's another file for them to have to deal with.
It seems less error prone when the war file is completely self contained.
Michael McCallum wrote:
> I would highly recommend you externalise environmental configuration such that you don't need to rebuild any artifacts when moving them from one environment to another.
>
> On Fri, 07 Nov 2008 08:46:31 Hayward Lam wrote:
>> Hi all,
>>
>>
>>
>> We have in-house maven projects. The build requires environment specific
>> property replacement (i.e. dev, qa and prod) and we set up profiles for
>> them. When the project has been tested and is ready for release, we can
>> deploy the artifacts (dev, qa and prod) to our internal maven
>> repository.
>>
>>
>>
>> My questions are:
>>
>> 1) Is there some sort of release management tool that can automate
>> this process?
>>
>> 2) We use Hudson for continuous integration. The configuration will
>> be based on each environment only (i.e. -P env-dev). So, each build will
>> have its own build number. Is there some consolidated way to do this?
>> i.e. same build number for dev, qa and prod.
>>
>> 3) What is the practice that works for you?
>>
>>
>>
>> Thanks
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Release Management Questions
Posted by Michael McCallum <gh...@apache.org>.
I would highly recommend you externalise environmental configuration such that you don't need to rebuild any artifacts when moving them from one environment to another.
On Fri, 07 Nov 2008 08:46:31 Hayward Lam wrote:
> Hi all,
>
>
>
> We have in-house maven projects. The build requires environment specific
> property replacement (i.e. dev, qa and prod) and we set up profiles for
> them. When the project has been tested and is ready for release, we can
> deploy the artifacts (dev, qa and prod) to our internal maven
> repository.
>
>
>
> My questions are:
>
> 1) Is there some sort of release management tool that can automate
> this process?
>
> 2) We use Hudson for continuous integration. The configuration will
> be based on each environment only (i.e. -P env-dev). So, each build will
> have its own build number. Is there some consolidated way to do this?
> i.e. same build number for dev, qa and prod.
>
> 3) What is the practice that works for you?
>
>
>
> Thanks
>
>
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Release Management Questions
Posted by Hayward Lam <hl...@carms.ca>.
This is one approach I am considering as well.
-----Original Message-----
From: Michael McCallum [mailto:gholam@apache.org]
Sent: November 6, 2008 5:05 PM
To: Maven Users List
Subject: Re: Release Management Questions
I would highly recommend you externalise environmental configuration such that you don't need to rebuild any artifacts when moving them from one environment to another.
On Fri, 07 Nov 2008 08:46:31 Hayward Lam wrote:
> Hi all,
>
>
>
> We have in-house maven projects. The build requires environment specific
> property replacement (i.e. dev, qa and prod) and we set up profiles for
> them. When the project has been tested and is ready for release, we can
> deploy the artifacts (dev, qa and prod) to our internal maven
> repository.
>
>
>
> My questions are:
>
> 1) Is there some sort of release management tool that can automate
> this process?
>
> 2) We use Hudson for continuous integration. The configuration will
> be based on each environment only (i.e. -P env-dev). So, each build will
> have its own build number. Is there some consolidated way to do this?
> i.e. same build number for dev, qa and prod.
>
> 3) What is the practice that works for you?
>
>
>
> Thanks
>
>
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
__________ Information from ESET Smart Security, version of virus signature database 3592 (20081106) __________
The message was checked by ESET Smart Security.
http://www.eset.com
__________ Information from ESET Smart Security, version of virus signature database 3594 (20081107) __________
The message was checked by ESET Smart Security.
http://www.eset.com
RE: Release Management Questions
Posted by Hayward Lam <hl...@carms.ca>.
Thanks for the URL. It looks like something we can use.
-----Original Message-----
From: Rogier Peters [mailto:rogier.peters@gmail.com]
Sent: November 7, 2008 3:14 AM
To: Maven Users List
Subject: Re: Release Management Questions
Do you know about http://maven.apache.org/plugins/maven-release-plugin/
?
If you need more info I can ping my colleagues who have a similar setup
On Thu, Nov 6, 2008 at 8:46 PM, Hayward Lam <hl...@carms.ca> wrote:
> Hi all,
>
>
>
> We have in-house maven projects. The build requires environment
specific
> property replacement (i.e. dev, qa and prod) and we set up profiles
for
> them. When the project has been tested and is ready for release, we
can
> deploy the artifacts (dev, qa and prod) to our internal maven
> repository.
>
>
>
> My questions are:
>
> 1) Is there some sort of release management tool that can
automate
> this process?
>
> 2) We use Hudson for continuous integration. The configuration
will
> be based on each environment only (i.e. -P env-dev). So, each build
will
> have its own build number. Is there some consolidated way to do this?
> i.e. same build number for dev, qa and prod.
>
> 3) What is the practice that works for you?
>
>
>
> Thanks
>
>
__________ Information from ESET Smart Security, version of virus
signature database 3594 (20081107) __________
The message was checked by ESET Smart Security.
http://www.eset.com
__________ Information from ESET Smart Security, version of virus
signature database 3594 (20081107) __________
The message was checked by ESET Smart Security.
http://www.eset.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org