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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] Web: www.cfc.at --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
