[prev in list] [next in list] [prev in thread] [next in thread] 

List:       maven-user
Subject:    Re: Continuous Delivery with Maven now possible?
From:       Eric Benzacar <eric () benzacar ! ca>
Date:       2017-05-05 1:25:23
Message-ID: CA+T+PjGF9CTB0=qG0-bFGESJ6aXXF-AoVjXtrkK_U8WmwMxzTg () mail ! gmail ! com
[Download RAW message or body]


Hi,

Thanks for the detailed response.  You have a lot of great points in there,
and most of them I agree with (and partially implement already).  As a
CI/CD server, I'm using Jenkins and constantly trying to find better ways
to do things.


> First if you make a release your release process must create a tag in your
> version control with this state of your source code. Furthermore you should
> bake informations like the revision number or sha1 of your version control
> system into your resulting artifacts (configuration of maven-jar, maven-war
> etc.) and a branch name is also helpful which I always encourage
> independent of the usage of this here. This makes traceability more
> easier...
>

I'm not currently tagging my code in my build (shameful - I know).  Sadly,
I haven't figured out the "best" way to create my tags on my build server
and push them to my central repo, without completely polluting my repo (I
would rather not have thousands of tags in my repo).  I suspect if I only
auto-tag my builds for RCs, it will reduce the amount of pollution.  But in
a way, at the end of the day, I really only care about the tag for the code
that actually makes it to Prod.

I am already injecting my commit id, build date, build user, build engine
into the Manifest of my artifact, although that too is being done through a
bit of a workaround.  I don't know if there is a Jenkins plugin that will
do this automatically, but at the moment, I have my org pom defined such
that these properties are added to the manifests for jars, wars and ears.
And I pass the parameters using -Dscm.commitId=xxxx etc at the maven
build.  I don't know if there is a better way to do this, and if there is,
I would love to hear about it.



> So based on some Continuous Delivery setups in theses days the created tag
> is not that essential. It is only essential to create a new artifact very
> fast without some run of versions-plugin or bash/script vodoo to only
> change the version number in all pom files and produce one, two or three
> (release plugin) checkins which only contain information about the changed
> versions in pom file nothing more interesting...So if you are working with
> branches the version numbers in pom files are always a pain cause they
> produce always conflicts....
>

Agreed - changing version numbers is constantly a royal pain.  Between
merge conflicts and a nuissance to rebuild each time, I would love to avoid
it, if possible, without losing any of the traceability it provides.



> Furthermore based on the above described scenario the question comes into
> my mind: Is the version control the righ tool/location to answer this
> question? In the meantime I tend to say no. The artifact repository (Nexus
> for example) is the better tool/location to answer this question...but this
> a very controversy thing...
>

Agreed again.  I believe that the sources should also be automatically
generated and delivered to Nexus along with the binary.  Not only does this
allow for traceability, it also helps significantly in the debugging
process.  However, it is critical to know in the source control which
versions (ie: which commits) of a source file made it into which
build/release.


> Furthermore if you think about this statement in consequence this means
> you are not allowed to use any version ranges in none of your pom files
> cause this will result in more complicated problems than only not knowing
> the version number from your version control...
>

True.  I don't currently use version ranges (have not really ever seen the
need for it), so it isn't as much of an issue for me.  But I can understand
your point.



> The separation between the "build pom" and the "consumer pom" which is
> implicitly done by this. This means the "build pom" is checked into version
> control but not the resulting "consumer pom" which is only intended for
> consumers of your artifacts and only being available in the destination
> artifact repository which has been built by a technical process. This is
> the same as we compile a Java class cause we only have as a result the
> compiled class file in our jar file but not the source files...
>

Very valid.  However, I also look at it from another perspective.  I like
to be able to check out code at any commit, and be able to know which
"version" it is.  The easiest way to do that is to have a pom with a
version in it that specifies that at that particular snapshot in time, I
was looking at the entire code for version 1.2.3-SNAPSHOT, or
1.2.5.RELEASE.  Have parameters in the version info loses that clarity.



> You have the pom which contains the properties with the versions parts
> like revision,changelist and sha1 and the resulting pom file which is
> installed into the repository (see also flatten-maven-plugin)...or just
> define the property(ies) via command line...
>

I need to look at the flatten-maven-plugin a little more closely.  Is the
pom.xml and pom.properties that maven embeds into the artifact the
"compiled" (or consumer) pom, or is it just a copy of the build pom?


What you mentioned about have the versions-maven-plugin is correct and it
> needed to be improved to let the plugin only change the properties like
> revision,changelist,sha1 to be changed is something which I already thougt
> about which would mean only to change a single pom file (usually the
> project parent in a multi module build).....
>

Would that be contrary to your point though?  My point of the
versions-plugin is to have it be able to modify parts of the pom file and
then we would have to commit the updated pom.  In your idea, however, the
source pom has no version specified directly - it is always coming from an
environment variable - so why would you want/need the versions-plugin?

Are you using the Jenkins Pipeline plugin to manage any of this process?
Are you using Jenkins for your CI/CD?  If so, can you please share
additional details of your whole process?  I would love to see/hear how
others have their CI servers configured to handle these builds.

Thanks!

Eric


[prev in list] [next in list] [prev in thread] [next in thread]