You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Maarten Volders <ma...@sherpa-consulting.be> on 2007/04/28 23:01:20 UTC
HOWTO: (Build / ) Release mgmt in multi environment
Hi,
I have the following question on how to setup a Maven environment in a multi
environment (test, staging, production). Ps.this is the first Maven project
I'm doing ... having an ANT background.
Lets' start by talking what I have. We have a multi project structure and
are using profiles (-Denv=test) which sets all the configuration data during
the build lifecycle. Up until now we were just using the
1.0-SNAPSHOTversion for all our modules but a release is coming near
and it seems I
don't have a clear view on what has to happen now.
I've read about the release:prepare / perform plugin but I'm unsure how it
should be handled in a multi environment. So here come the questions:
1. What exactly does the release plugin provide on the end, is it a packaged
module .war / .jar with the newly set version and stored in the repository?
2. Now we deploy a version to our servers using cargo and specify the
profile we want to use, for example -Denv=test when we want to put something
in the test environment. What I've seen so far of the release plugin is that
you need to specify the profile to which environment you are building.
Because the DB url / driver are kept in the maven profiles and are needed to
run the tests and to work with in the deployed application. So do we need to
release multiple versions? What I mean is do we need to release something
like app-test-1.0.war app-staging-1.0.war app-production-1.0.war? I guess so
because how else will we get the correct version if we want to deploy on a
specific version, if we have just version application-1.0.war we have no
idea for which environment it can be used. But .. if so ... I have no idea
on how to do this with the release plugin, because you can add a version id
like test1.0 or production-1.0 but after the first entry the sources will
already be tagged in scm, so what about the others?
Or do you provide just one release app-1.0.jar ... which actually makes more
sense to me because we release 1 version which needs to work for all
environments. But how do we handle this Up until now I've always put my
application variables in the profiles (i.e. datasource, connection url,
userid passw, email settings ...) but when we only release one version an
use that to deploy to ALL environments how will the correct application
values be set?
3. Also the same for testing (unit / integration), during the development we
test against the test database, we we deploy to staging the build lifecycle
rexecutes all these tests again, should these tests be ran against the test
database or against the staging database? But what about production do you
still run the test against the production database that way, but we still
want to run tests.. against which database are we testing this? Test, Dev?
I would really like to know what the best practices are on how to build /
deploy / release in a multi environment. And feel free to inform me on this
topic and not be limited to the questions above ;-)
Looking forward to your responses!!!
Grtz
M.
Re: HOWTO: (Build / ) Release mgmt in multi environment
Posted by Roland Asmann <Ro...@cfc.at>.
No problem, just wanted to make sure you knew.
I hope you did see that I tried to answer some of your questions as well, so
don't just read the 'insulting' part of my mail! ;-)
On Monday 30 April 2007 13:34, Maarten Volders wrote:
> Thanks for the feedback, It was not my intetion to post multiple times, but
> I posted the first time, I didn't see anything appearing. So a reposted
> because I thought something was wrong with my account :-) But it seems it
> took a while before it was on the list ... therefore I apologize!
>
> Grtz
--
Roland Asmann
CFC Informationssysteme Entwicklungsgesellschaft m.b.H
Bäckerstrasse 1/2/7
A-1010 Wien
FN 266155f, Handelsgericht Wien
Tel.: +43/1/513 88 77 - 27
Fax.: +43/1/513 88 62
Email: Roland.Asmann@cfc.at
Web: www.cfc.at
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: HOWTO: (Build / ) Release mgmt in multi environment
Posted by Maarten Volders <ma...@sherpa-consulting.be>.
Thanks for the feedback, It was not my intetion to post multiple times, but
I posted the first time, I didn't see anything appearing. So a reposted
because I thought something was wrong with my account :-) But it seems it
took a while before it was on the list ... therefore I apologize!
Grtz
On 4/30/07, Roland Asmann <Ro...@cfc.at> wrote:
>
> If someone doesn't answer your questions right away, please don't send it
> again! People might be busy, or maybe nobody knows the answer(s) to your
> question.
>
> I'll see if I can answer parts of your mail though.
>
> On Saturday 28 April 2007 23:01, Maarten Volders wrote:
> > Hi,
> >
> > I have the following question on how to setup a Maven environment in a
> > multi environment (test, staging, production). Ps.this is the first
> Maven
> > project I'm doing ... having an ANT background.
> >
> > Lets' start by talking what I have. We have a multi project structure
> and
> > are using profiles (-Denv=test) which sets all the configuration data
> > during the build lifecycle. Up until now we were just using the
> > 1.0-SNAPSHOTversion for all our modules but a release is coming near
> > and it seems I
> > don't have a clear view on what has to happen now.
> >
> > I've read about the release:prepare / perform plugin but I'm unsure how
> it
> > should be handled in a multi environment. So here come the questions:
> >
> > 1. What exactly does the release plugin provide on the end, is it a
> > packaged module .war / .jar with the newly set version and stored in the
> > repository?
>
> The release-plugin will update your POM to the version you specify as the
> release-version. It will also commit and tag this verison in your SCM.
> After that, it will prepare the POM for the new iteration (meaning it
> updates
> the version once again) and commits that to your SCM as well.
> Also, a JAR/WAR/EAR/whatever is build and released in the specified
> (company-)repository. Along with any sites you have configured.
>
> >
> > 2. Now we deploy a version to our servers using cargo and specify the
> > profile we want to use, for example -Denv=test when we want to put
> > something in the test environment. What I've seen so far of the release
> > plugin is that you need to specify the profile to which environment you
> are
> > building. Because the DB url / driver are kept in the maven profiles and
> > are needed to run the tests and to work with in the deployed
> application.
> > So do we need to release multiple versions? What I mean is do we need to
> > release something like app-test-1.0.war app-staging-1.0.war
> > app-production-1.0.war? I guess so because how else will we get the
> correct
> > version if we want to deploy on a specific version, if we have just
> version
> > application-1.0.war we have no idea for which environment it can be
> used.
> > But .. if so ... I have no idea on how to do this with the release
> plugin,
> > because you can add a version id like test1.0 or production-1.0 but
> after
> > the first entry the sources will already be tagged in scm, so what about
> > the others?
> >
> > Or do you provide just one release app-1.0.jar ... which actually makes
> > more sense to me because we release 1 version which needs to work for
> all
> > environments. But how do we handle this Up until now I've always put my
> > application variables in the profiles (i.e. datasource, connection url,
> > userid passw, email settings ...) but when we only release one version
> an
> > use that to deploy to ALL environments how will the correct application
> > values be set?
>
> Do you really need to release the project in all profiles? Normally your
> release would consist of the production-version, the others are
> 'internals'
> (meaning they are meant for internal use only).
> If you indeed only need this one released, you can just use the
> release-plugin
> with the production-profile.
>
> If you want all of them released, I think it would be best to make the
> releases one after another, based on the POM that has just been 'updated'.
> Example:
> You release the test-profile first. The release-plugin will ask you for
> the
> version of the release, which we give as 'test-1.0'. Next, the plugin will
> ask you for the new version-number. This one you can than give as your
> original version: 1.0-SNAPSHOT.
> You repeat this process for the staging-profile.
> For the production-profile, you will do almost the same, only this time
> you
> WILL change the new working version of your project to e.g. 1.1-SNAPSHOT.
>
> This works, because the ONLY things that is changed in the POM is the
> version.
> Try it if you are not sure, do a dryRun on the release-plugin, tell the
> plugin all the versions and compare the original POM with the new one
> (carefull not to confuse it with the release POM, that one IS different!).
>
> As for releasing one artifact: I think you're on the wrong track for that!
> If
> you want to tell your server which version to use, you will NOT need
> profiles, but you need configurations that can be read at runtime!
> Profiles
> are NOT runtime-parts, they are build-parts.
>
> >
> > 3. Also the same for testing (unit / integration), during the
> development
> > we test against the test database, we we deploy to staging the build
> > lifecycle rexecutes all these tests again, should these tests be ran
> > against the test database or against the staging database? But what
> about
> > production do you still run the test against the production database
> that
> > way, but we still want to run tests.. against which database are we
> testing
> > this? Test, Dev?
>
> As to which database to use, I don't think anybody but you can answer that
> question... Personally I wouldn't run tests against the
> production-database,
> because you might just fill it up with test-data. And if your tests fail,
> how
> will you get any test-data out of the DB? Or even worse: your test deletes
> some stuff for the DB that shouldn't have been deleted.... What now?
>
> My personal opinion in this, would be to run tests on the test-DB and
> maybe
> even on the staging-DB, but NEVER against the production-DB.
>
> >
> > I would really like to know what the best practices are on how to build
> /
> > deploy / release in a multi environment. And feel free to inform me on
> this
> > topic and not be limited to the questions above ;-)
>
> Hope this clarified some of your questions. Feel free to ask more if you
> want
> to, that's a lot easier than for all of us to tell you everything about
> Maven
> at once... It's just too much and probably better to learn about XX when
> you're working with it!
>
> >
> > Looking forward to your responses!!!
> >
> > Grtz
> >
> > M.
>
> --
> Roland Asmann
>
> CFC Informationssysteme Entwicklungsgesellschaft m.b.H
> Bäckerstrasse 1/2/7
> A-1010 Wien
> FN 266155f, Handelsgericht Wien
>
> Tel.: +43/1/513 88 77 - 27
> Fax.: +43/1/513 88 62
> Email: Roland.Asmann@cfc.at
> Web: www.cfc.at
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: HOWTO: (Build / ) Release mgmt in multi environment
Posted by Roland Asmann <Ro...@cfc.at>.
Hi David,
Sorry about the late response, yesterday was a holiday and it was one of the
few that I actually don't ignore.
As for your question, I am not quite sure about your sub-module versioning,
since you didn't really explain it, but I'll do my best on answering.
In the latest snapshot-version of the release-plugin, there is a parameter
called 'autoVersionSubmodules'. It's description reads:
/**
* Whether to automatically assign submodules the parent version. If set to
false,
* the user will be prompted for the version of each submodules.
*
* @parameter expression="${autoVersionSubmodules}" default-value="false"
*/
This would mean, that if you use the same version on your sub-modules as well
(which is what I presume, this is the part I'm not sure about from your
mail!), you would only have to set the version once.
If this would solve your problem, you could checkout the latest version of the
release-plugin, build it, deploy it and use it on your projects.
Another solution would be to do a dryRun once, and check the
file 'release.properties'. You might be able to trick maven into using
settings that you entered into that file.
Or, as the others have already said, checkout the plugin and write your own
solution.
I hope one of the answers will do the trick for you.
On Tuesday 01 May 2007 18:42, David C. Hicks wrote:
> Thanks for the links. I'm a bit "under water" right now, but if I can
> get a chance to come up for air, I may just do that.
>
> David Roussel wrote:
> > If you've got that far, then your on your way to making a change and
> > trying it out
> >
> > Have a look at:
> > - http://maven.apache.org/guides/development/guide-m2-development.html
> > - http://maven.apache.org/plugin-developers/index.html
> > - http://maven.apache.org/developers/index.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
--
Roland Asmann
CFC Informationssysteme Entwicklungsgesellschaft m.b.H
Bäckerstrasse 1/2/7
A-1010 Wien
FN 266155f, Handelsgericht Wien
Tel.: +43/1/513 88 77 - 27
Fax.: +43/1/513 88 62
Email: Roland.Asmann@cfc.at
Web: www.cfc.at
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: HOWTO: (Build / ) Release mgmt in multi environment
Posted by Wayne Fay <wa...@gmail.com>.
Other people have asked for/suggested this previously, but it seems no
one has actually done it yet, so if it is functionality you desire,
I'd strongly suggest implementing it in a way that you like, and then
contributing it back.
You might want to check JIRA to make sure a bug hasn't already been
filed for this issue, so you can attach your code patch to the proper
issue, or make a new one if none exists.
Wayne
On 5/1/07, David Roussel <na...@diroussel.xsmail.com> wrote:
>
> If you've got that far, then your on your way to making a change and trying
> it out
>
> Have a look at:
> - http://maven.apache.org/guides/development/guide-m2-development.html
> - http://maven.apache.org/plugin-developers/index.html
> - http://maven.apache.org/developers/index.html
>
>
> David C. Hicks wrote:
> >
> > Well, I did a little browsing through the maven-release-plugin code
> > base, and I see that what I'm looking for (below) isn't currently
> > possible. It doesn't look like it would be terribly difficult to insert
> > a check for a system property into DefaultVersionInfo#getNextVersion,
> > though, that could pull off this stunt. Since I'm not involved in the
> > plugin development, I guess the best I can do is offer it up as a thought.
> >
> > David C. Hicks wrote:
> >> Maybe it's a bad idea and please feel free to let me know if there is
> >> a good reason to change this strategy, but we don't use the typical
> >> Maven version numbering scheme. We work in an agile environment and
> >> use our iteration number as the minor version number. The major
> >> number is reserved for major releases, as usual. The revision is used
> >> when we release a "patch" release during an iteration to fix specific
> >> problems for our QE department prior to the usual iteration release.
> >> So, for example, my current project's release is 0.18.0 meaning that
> >> we've released iteration 18 to QE. We're currently working on
> >> 0.19.0-SNAPSHOT.
> >>
> >> I understand that I can use the --batchmode switch to keep the release
> >> plugin from asking me for new release numbers, a big problem because
> >> we have about six sub-projects that all must be re-versioned for both
> >> release and a new snapshot. It's not good to have to key in new
> >> versions six times each. :-) What would be nice, is if I could
> >> specify the new release/snapshot versions in some kind of system
> >> property, something like the -DdryRun property. Do you know if this
> >> is possible?
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/HOWTO%3A-%28Build---%29-Release-mgmt-in-multi-environment-tf3663526s177.html#a10269969
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: HOWTO: (Build / ) Release mgmt in multi environment
Posted by "David C. Hicks" <dh...@i-hicks.org>.
Thanks for the links. I'm a bit "under water" right now, but if I can
get a chance to come up for air, I may just do that.
David Roussel wrote:
> If you've got that far, then your on your way to making a change and trying
> it out
>
> Have a look at:
> - http://maven.apache.org/guides/development/guide-m2-development.html
> - http://maven.apache.org/plugin-developers/index.html
> - http://maven.apache.org/developers/index.html
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: HOWTO: (Build / ) Release mgmt in multi environment
Posted by David Roussel <na...@diroussel.xsmail.com>.
If you've got that far, then your on your way to making a change and trying
it out
Have a look at:
- http://maven.apache.org/guides/development/guide-m2-development.html
- http://maven.apache.org/plugin-developers/index.html
- http://maven.apache.org/developers/index.html
David C. Hicks wrote:
>
> Well, I did a little browsing through the maven-release-plugin code
> base, and I see that what I'm looking for (below) isn't currently
> possible. It doesn't look like it would be terribly difficult to insert
> a check for a system property into DefaultVersionInfo#getNextVersion,
> though, that could pull off this stunt. Since I'm not involved in the
> plugin development, I guess the best I can do is offer it up as a thought.
>
> David C. Hicks wrote:
>> Maybe it's a bad idea and please feel free to let me know if there is
>> a good reason to change this strategy, but we don't use the typical
>> Maven version numbering scheme. We work in an agile environment and
>> use our iteration number as the minor version number. The major
>> number is reserved for major releases, as usual. The revision is used
>> when we release a "patch" release during an iteration to fix specific
>> problems for our QE department prior to the usual iteration release.
>> So, for example, my current project's release is 0.18.0 meaning that
>> we've released iteration 18 to QE. We're currently working on
>> 0.19.0-SNAPSHOT.
>>
>> I understand that I can use the --batchmode switch to keep the release
>> plugin from asking me for new release numbers, a big problem because
>> we have about six sub-projects that all must be re-versioned for both
>> release and a new snapshot. It's not good to have to key in new
>> versions six times each. :-) What would be nice, is if I could
>> specify the new release/snapshot versions in some kind of system
>> property, something like the -DdryRun property. Do you know if this
>> is possible?
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/HOWTO%3A-%28Build---%29-Release-mgmt-in-multi-environment-tf3663526s177.html#a10269969
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: HOWTO: (Build / ) Release mgmt in multi environment
Posted by "David C. Hicks" <dh...@i-hicks.org>.
Well, I did a little browsing through the maven-release-plugin code
base, and I see that what I'm looking for (below) isn't currently
possible. It doesn't look like it would be terribly difficult to insert
a check for a system property into DefaultVersionInfo#getNextVersion,
though, that could pull off this stunt. Since I'm not involved in the
plugin development, I guess the best I can do is offer it up as a thought.
David C. Hicks wrote:
> Maybe it's a bad idea and please feel free to let me know if there is
> a good reason to change this strategy, but we don't use the typical
> Maven version numbering scheme. We work in an agile environment and
> use our iteration number as the minor version number. The major
> number is reserved for major releases, as usual. The revision is used
> when we release a "patch" release during an iteration to fix specific
> problems for our QE department prior to the usual iteration release.
> So, for example, my current project's release is 0.18.0 meaning that
> we've released iteration 18 to QE. We're currently working on
> 0.19.0-SNAPSHOT.
>
> I understand that I can use the --batchmode switch to keep the release
> plugin from asking me for new release numbers, a big problem because
> we have about six sub-projects that all must be re-versioned for both
> release and a new snapshot. It's not good to have to key in new
> versions six times each. :-) What would be nice, is if I could
> specify the new release/snapshot versions in some kind of system
> property, something like the -DdryRun property. Do you know if this
> is possible?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: HOWTO: (Build / ) Release mgmt in multi environment
Posted by "David C. Hicks" <dh...@i-hicks.org>.
Roland Asmann wrote:
> The release-plugin will update your POM to the version you specify as the
> release-version. It will also commit and tag this verison in your SCM.
> After that, it will prepare the POM for the new iteration (meaning it updates
> the version once again) and commits that to your SCM as well.
> Also, a JAR/WAR/EAR/whatever is build and released in the specified
> (company-)repository. Along with any sites you have configured.
>
>
Hi Roland,
I've been following this thread with great curiosity because I'm
struggling with some related issues. You seem quite knowledgeable about
how the release plugin operates, so I'm hoping you might know of a trick
or two that can help me out.
Maybe it's a bad idea, and please feel free to let me know if there is a
good reason to change this strategy, but we don't use the typical Maven
version numbering scheme. We work in an agile environment and use our
iteration number as the minor version number. The major number is
reserved for major releases, as usual. The revision is used when we
release a "patch" release during an iteration to fix specific problems
for our QE department prior to the usual iteration release. So, for
example, my current project's release is 0.18.0 meaning that we've
released iteration 18 to QE. We're currently working on 0.19.0-SNAPSHOT.
I understand that I can use the --batchmode switch to keep the release
plugin from asking me for new release numbers, a big problem because we
have about six sub-projects that all must be re-versioned for both
release and a new snapshot. It's not good to have to key in new
versions six times each. :-) What would be nice, is if I could specify
the new release/snapshot versions in some kind of system property,
something like the -DdryRun property. Do you know if this is possible?
Thanks for you patience with my long explanation, but I thought the
detail might be helpful.
Regards -
David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: HOWTO: (Build / ) Release mgmt in multi environment
Posted by Roland Asmann <Ro...@cfc.at>.
If someone doesn't answer your questions right away, please don't send it
again! People might be busy, or maybe nobody knows the answer(s) to your
question.
I'll see if I can answer parts of your mail though.
On Saturday 28 April 2007 23:01, Maarten Volders wrote:
> Hi,
>
> I have the following question on how to setup a Maven environment in a
> multi environment (test, staging, production). Ps.this is the first Maven
> project I'm doing ... having an ANT background.
>
> Lets' start by talking what I have. We have a multi project structure and
> are using profiles (-Denv=test) which sets all the configuration data
> during the build lifecycle. Up until now we were just using the
> 1.0-SNAPSHOTversion for all our modules but a release is coming near
> and it seems I
> don't have a clear view on what has to happen now.
>
> I've read about the release:prepare / perform plugin but I'm unsure how it
> should be handled in a multi environment. So here come the questions:
>
> 1. What exactly does the release plugin provide on the end, is it a
> packaged module .war / .jar with the newly set version and stored in the
> repository?
The release-plugin will update your POM to the version you specify as the
release-version. It will also commit and tag this verison in your SCM.
After that, it will prepare the POM for the new iteration (meaning it updates
the version once again) and commits that to your SCM as well.
Also, a JAR/WAR/EAR/whatever is build and released in the specified
(company-)repository. Along with any sites you have configured.
>
> 2. Now we deploy a version to our servers using cargo and specify the
> profile we want to use, for example -Denv=test when we want to put
> something in the test environment. What I've seen so far of the release
> plugin is that you need to specify the profile to which environment you are
> building. Because the DB url / driver are kept in the maven profiles and
> are needed to run the tests and to work with in the deployed application.
> So do we need to release multiple versions? What I mean is do we need to
> release something like app-test-1.0.war app-staging-1.0.war
> app-production-1.0.war? I guess so because how else will we get the correct
> version if we want to deploy on a specific version, if we have just version
> application-1.0.war we have no idea for which environment it can be used.
> But .. if so ... I have no idea on how to do this with the release plugin,
> because you can add a version id like test1.0 or production-1.0 but after
> the first entry the sources will already be tagged in scm, so what about
> the others?
>
> Or do you provide just one release app-1.0.jar ... which actually makes
> more sense to me because we release 1 version which needs to work for all
> environments. But how do we handle this Up until now I've always put my
> application variables in the profiles (i.e. datasource, connection url,
> userid passw, email settings ...) but when we only release one version an
> use that to deploy to ALL environments how will the correct application
> values be set?
Do you really need to release the project in all profiles? Normally your
release would consist of the production-version, the others are 'internals'
(meaning they are meant for internal use only).
If you indeed only need this one released, you can just use the release-plugin
with the production-profile.
If you want all of them released, I think it would be best to make the
releases one after another, based on the POM that has just been 'updated'.
Example:
You release the test-profile first. The release-plugin will ask you for the
version of the release, which we give as 'test-1.0'. Next, the plugin will
ask you for the new version-number. This one you can than give as your
original version: 1.0-SNAPSHOT.
You repeat this process for the staging-profile.
For the production-profile, you will do almost the same, only this time you
WILL change the new working version of your project to e.g. 1.1-SNAPSHOT.
This works, because the ONLY things that is changed in the POM is the version.
Try it if you are not sure, do a dryRun on the release-plugin, tell the
plugin all the versions and compare the original POM with the new one
(carefull not to confuse it with the release POM, that one IS different!).
As for releasing one artifact: I think you're on the wrong track for that! If
you want to tell your server which version to use, you will NOT need
profiles, but you need configurations that can be read at runtime! Profiles
are NOT runtime-parts, they are build-parts.
>
> 3. Also the same for testing (unit / integration), during the development
> we test against the test database, we we deploy to staging the build
> lifecycle rexecutes all these tests again, should these tests be ran
> against the test database or against the staging database? But what about
> production do you still run the test against the production database that
> way, but we still want to run tests.. against which database are we testing
> this? Test, Dev?
As to which database to use, I don't think anybody but you can answer that
question... Personally I wouldn't run tests against the production-database,
because you might just fill it up with test-data. And if your tests fail, how
will you get any test-data out of the DB? Or even worse: your test deletes
some stuff for the DB that shouldn't have been deleted.... What now?
My personal opinion in this, would be to run tests on the test-DB and maybe
even on the staging-DB, but NEVER against the production-DB.
>
> I would really like to know what the best practices are on how to build /
> deploy / release in a multi environment. And feel free to inform me on this
> topic and not be limited to the questions above ;-)
Hope this clarified some of your questions. Feel free to ask more if you want
to, that's a lot easier than for all of us to tell you everything about Maven
at once... It's just too much and probably better to learn about XX when
you're working with it!
>
> Looking forward to your responses!!!
>
> Grtz
>
> M.
--
Roland Asmann
CFC Informationssysteme Entwicklungsgesellschaft m.b.H
Bäckerstrasse 1/2/7
A-1010 Wien
FN 266155f, Handelsgericht Wien
Tel.: +43/1/513 88 77 - 27
Fax.: +43/1/513 88 62
Email: Roland.Asmann@cfc.at
Web: www.cfc.at
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org