Alex Rivera | Logout

The simplest way to deploy to production with builds

Asked 2012-02-14T15:20:43.300
22

I must confess I'm new to maven world after years of living in the world of monstrous debuild/ant/makefile chimeric constructions. I just don't have yet that very feeling which helps seasoned developer to choose right decisions, and it's looks like there are plenty different ways in maven.

So, I have a simple project containing of web-app. I want basically following:

  • deploy to development Tomcat (I'm using tomcat:deploy), then do nothing.
  • deploy to production Tomcat, but before deployment update git repo, add tagged commit and upgrade build version.

For distinguishing between development and production I've created profiles, dev and prod. The dev profile is activated by default. When I want to deploy something to production, I just type mvn -P prod tomcat:deploy

I've read about release plugin, as well as about buildnumber plugin. But I'm just not sure I'm going the right way.

So, the question is - what is the most succint, self-contained and "mavenish" way to resolve the task I'm asking about.

tomcat deployment maven
Edit
Report

1 Answer

4

The original question asked for "the best practice" to do production deploys with Maven. I expected to get more than one "best practice" and offered the bounty to see different solutions and learn from them. I do not care if they are pure maven solutions or if they utilize different tools.

Parallel to this thread I did also some researching and would like to post here the different approaches I am seeing. I tried 1) and 3), they are pure maven and regardless what Aaron is saying, they are working also.

In my current project I have a development environment, a test environment, a staging environment and a production environment. From my maven pom I would like to work with the development environment and deploy only to the test environment. I see the following approaches with maven pom:

  1. profiles with filtering properties
    When working with this approach the deliverable (the war file) has to be rebuilded for different environments. This forced me to offer the bounty because I didn't like that.
  2. profiles wit Maven WAR overlays or assembly plugin
    This also generated different artefacts for different platforms. But instead of rebuilding the war file it will be unpacked/patched/repacked (for the war overlay) or build and packed with different settings (assembly plugin). I didn't like this solution either.
  3. A deployment plugin (eg. Cargo plugin) without profiles
    Specify the complete build with installation and also include the cargo plugin doing a remote deployment but not connect it to any phase. So I always work with the development environment but when I explicitely call the cargo plugin it deploys the war from the repository to a container
answered 2012-06-08T11:11:59.710

Your Answer