Dan,
Thanks for the update. I'm at the state where I am trying to integrated CD
with a large multi-module maven project and trying to get this process
running smoothly with Jenkins. For the moment, I'm ok to use a
split-Continuous Deployment concept - similar to yours. ie: using
SNAPSHOTs for development phase, and anything in a release branch becomes
an release candidate. Meaning that any commits into the release/ branch
produce a potentially shippable version.
But that means that I need poms with version numbers as moving targets (ie:
sometimes with SNAPSHOTs, sometimes without). Based on Karl Heinz
Marbaise's suggestions, I am planning on building my poms as follows:
parent pom:
<groupId>com.benze</groupId>
<artifactId>parent</artifactId>
<version>${revision}${sha1}${changelist}</version>
<packaging>pom</packaging>
<properties>
<revision>1.3.1</revision>
<changelist>-SNAPSHOT</changelist>
<sha1/>
</properties>
but in my child poms, I'm not sure how to refer to the parent:
<artifactId>webapp</artifactId>
<packaging>war</packaging>
<parent>
<groupId>com.benze</groupId>
<artifactId>parent</artifactId>
<version> ??????? </version>
<relativePath>../superpom</relativePath>
</parent>
How do you refer to the parent pom with a constantly (non-defined) moving
version? In the past, without using properties like this, I could use the
maven-versions-plugin to update the version numbers, but now I don't even
see how I can do that. If the revision is defined at the command line in
Jenkins (ie: -Drevision=4.5.0), how do I deal with the child poms? If
memory serves, the child cannot use properties for the parent version
number.
How/where to do you specify your semantic version number? I remember you
said you use the buildnumber-m-p for the build number, but that
how/where/when do you specify the sematic version number? Do you have to
manually change it in the poms at RC time? Is it only defined during the
build process?
Do you have an example of your pom structure and Jenkinsfile pipeline that
you can share to help me better grasp how to handle this integration?
Thanks,
Eric
On Fri, Jun 2, 2017 at 5:34 AM, Dan Tran <dant...@gmail.com> wrote:
> Just want to share our final outcomes
>
> 1. Use snapshot build during development phase
>
> 2. At release candidate phase, switch jenkinsfile to release mode
>
> * For small projects, use version less Maven continuous deliver
> friendly,
>
> * For large projects, use versions-maven-plugin to change version in
> all poms at pre-build
>
> * Automate the process to tag the final RC (we deploy a
> build.properties to maven repo at each build, use its info to tag the SCM)
>
> Whenever, the startup performance issue for large project is fixed, we will
> switch to full version less build
>
> -Dan
>
> On Sun, May 14, 2017 at 7:23 PM, Dan Tran <dant...@gmail.com> wrote:
>
> > I also noticed it takes about a minute for the build to roll after this
> >
> > [INFO] Error stacktraces are turned on.
> > [INFO] Scanning for projects...
> >
> > This is not a good news for local dev build
> >
> > here are 2 time summaries running 250+ modules with skipTests and 4
> thread
> > smart builder. The first one does not use <version>${revision}</version>
> >
> > [INFO] ------------------------------------------------------------
> > ------------
> > [INFO] Total time: 04:05 min (Wall Clock)
> > [INFO] Finished at: 2017-05-14T19:16:32-07:00
> > [INFO] Final Memory: 680M/2078M
> >
> > [INFO] ------------------------------------------------------------
> > ------------
> > [INFO] Total time: 05:56 min (Wall Clock)
> > [INFO] Finished at: 2017-05-14T19:11:00-07:00
> > [INFO] Final Memory: 1726M/3561M
> >
> >
> > -D
> >
>
