You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by ginni <gi...@aero.org> on 2010/12/15 18:32:03 UTC
Deployment Advice?
We are just now using Maven and love the benefits thus far. Would anyone
please advise on the best setup for a production environment, as in: should
we/should we not use Hudson, Maven to do production application development
(is that possible?)? We are a small group of developers building our first
Tomcat servers and preparing to go live with an application we've just
developed for in-house use only. I've been tasked with coming up with a
formal 'process' to manage our releases. We set up an internal repository
and are using Nexus to manage it, which is working nicely. But how is it
best to handle pushing out our production application for our users?
Thanks!
Ginni
--
View this message in context: http://maven.40175.n5.nabble.com/Deployment-Advice-tp3306659p3306659.html
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: Deployment Advice?
Posted by Martin Höller <ma...@xss.co.at>.
Hi!
Am Donnerstag 16 Dezember 2010, 15:07:19 schrieb Ron Wheeler:
> On 16/12/2010 2:19 AM, Martin Höller wrote:
> > Hi Ron!
> >
> > Am Mittwoch 15 Dezember 2010, 23:04:49 schrieb Ron Wheeler:
> >> Use JNDI to manage the site specific aspects of your configuration. This
> >> will make deploying to test machines and production less painful.
> >
> > I saw you mentioning this a few times now. However, I don't get it what
> > you are actually doing here. Would you mind explaining this approach in
> > more detail.
> >
> > tia,
> > - martin
>
> Of course, it is fairly specific to what we need.
> 1) Database connection specification is clearly a place where JNDI is a
> great solution.
> 2) Site name/customer name - can be used in code to specify namespaces
> or build file specifications,
> 3) Webservice endpoint specifications so that clients use the right
> webservices for test and production by customer.
> 4) URLs for resources or error screens
>
> We have removed anything that relates to operations/deployment from the
> code and into the Tomcat configurations (server.xml) on the server
> instance.
>
> Is this what you are looking for?
Thanks for your replies Ron and Brett. It explains what I was askig for and
what we are already doing (for most things). We just do not use JNDI for
extranalising configuration but for example properties files (not included in
the JAR/WAR/EAR) or XML datasource configuration files.
thx,
- martin
PS: Already have "Apache Maven 2: Effective Implementation" (great book BTW),
it's just been a while since I last looked into it :)
Re: Deployment Advice?
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 16/12/2010 4:23 AM, Brett Porter wrote:
> On 16/12/2010, at 6:19 PM, Martin Höller wrote:
>
>> Hi Ron!
>>
>> Am Mittwoch 15 Dezember 2010, 23:04:49 schrieb Ron Wheeler:
>>> Use JNDI to manage the site specific aspects of your configuration. This
>>> will make deploying to test machines and production less painful.
>> I saw you mentioning this a few times now. However, I don't get it what you
>> are actually doing here. Would you mind explaining this approach in more
>> detail.
> It's not strictly related to automated deployment (though it might help)... the basic idea is to ensure that a single WAR can be used in any environment without being rebuilt. So anything specific to a target environment is "externalised" - typically database connections or a set of properties. These can all be specified through JNDI, or other similar techniques.
>
Exactly.
> More information can be found at slide 31: http://brettporter.files.wordpress.com/2007/11/ac-us-07-maven-best-practices.pdf. Or for those that have it, chapter 7 of "Apache Maven 2: Effective Implementation".
>
Great presentation. I would agree with everything here.
It is a presentation rather than a manual but the ideas are pretty clear.
> Cheers,
> Brett
>
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
>
>
>
>
>
> ---------------------------------------------------------------------
> 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: Deployment Advice?
Posted by Brett Porter <br...@apache.org>.
On 16/12/2010, at 6:19 PM, Martin Höller wrote:
> Hi Ron!
>
> Am Mittwoch 15 Dezember 2010, 23:04:49 schrieb Ron Wheeler:
>> Use JNDI to manage the site specific aspects of your configuration. This
>> will make deploying to test machines and production less painful.
>
> I saw you mentioning this a few times now. However, I don't get it what you
> are actually doing here. Would you mind explaining this approach in more
> detail.
It's not strictly related to automated deployment (though it might help)... the basic idea is to ensure that a single WAR can be used in any environment without being rebuilt. So anything specific to a target environment is "externalised" - typically database connections or a set of properties. These can all be specified through JNDI, or other similar techniques.
More information can be found at slide 31: http://brettporter.files.wordpress.com/2007/11/ac-us-07-maven-best-practices.pdf. Or for those that have it, chapter 7 of "Apache Maven 2: Effective Implementation".
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deployment Advice?
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 16/12/2010 2:19 AM, Martin Höller wrote:
> Hi Ron!
>
> Am Mittwoch 15 Dezember 2010, 23:04:49 schrieb Ron Wheeler:
>> Use JNDI to manage the site specific aspects of your configuration. This
>> will make deploying to test machines and production less painful.
> I saw you mentioning this a few times now. However, I don't get it what you
> are actually doing here. Would you mind explaining this approach in more
> detail.
>
> tia,
> - martin
Of course, it is fairly specific to what we need.
1) Database connection specification is clearly a place where JNDI is a
great solution.
2) Site name/customer name - can be used in code to specify namespaces
or build file specifications,
3) Webservice endpoint specifications so that clients use the right
webservices for test and production by customer.
4) URLs for resources or error screens
We have removed anything that relates to operations/deployment from the
code and into the Tomcat configurations (server.xml) on the server instance.
Is this what you are looking for?
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deployment Advice?
Posted by Martin Höller <ma...@xss.co.at>.
Hi Ron!
Am Mittwoch 15 Dezember 2010, 23:04:49 schrieb Ron Wheeler:
> Use JNDI to manage the site specific aspects of your configuration. This
> will make deploying to test machines and production less painful.
I saw you mentioning this a few times now. However, I don't get it what you
are actually doing here. Would you mind explaining this approach in more
detail.
tia,
- martin
Re: Deployment Advice?
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 15/12/2010 12:32 PM, ginni wrote:
> We are just now using Maven and love the benefits thus far. Would anyone
> please advise on the best setup for a production environment, as in: should
> we/should we not use Hudson, Maven to do production application development
> (is that possible?)? We are a small group of developers building our first
> Tomcat servers and preparing to go live with an application we've just
> developed for in-house use only. I've been tasked with coming up with a
> formal 'process' to manage our releases. We set up an internal repository
> and are using Nexus to manage it, which is working nicely. But how is it
> best to handle pushing out our production application for our users?
> Thanks!
>
> Ginni
Use JNDI to manage the site specific aspects of your configuration. This
will make deploying to test machines and production less painful.
There seems to be a lot of support here for Hudson but there are also a
lot of messes related to Hudson.
I am either ignorant or old fashioned, but I would stay away from Hudson
until you have a smooth deployment setup working without it.
I am also not completely convinced that testing that does not include
the user interface and usability issues is really a big benefit for most
web applications.
You can increase the stability of your applications and make unit
testing stronger by being thoughtful about how you architect your
application.
Look for ways to break out functions into services that can are simple
and and can be tested without relation to the View.
Think about how to convert MVC to MV-SOA.
Look for ways to make standalone libraries instead of packages inside a
webapp.
Criteria:
- Might be reusable,
- Might survive changes in application functionality without being changed
- Might encapsulate mutable functionality so that a changes in
functionality of the application can be achieved by changes only in the
library.
Yes you will still use packages in the library.
If you are not using Spring, start to use Spring.
#1 rule. Do not try to bend Maven.
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org