maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Irfan Sayed <irfu.sa...@gmail.com>
Subject Re: Maven and Continous Integration / Continous Delivery
Date Wed, 20 Apr 2016 11:19:37 GMT
here is what needs to be done:

   - while building the packages, use the mvn option -DnewVersion and
   replace the new version in POM.xml. this will happen through Jenkins server
   (for example CI server ) . for this, you need to make all POMs writable.
   - once the packages are built with new version, you deploy the newly
   created packages on some node and verify the sanity/smoking . execute some
   test cases..
   - if the smoke fails, you can anyway rollback as this was the on the fly
   change in the POM file.
   - once those are passed and package is working fine. you need to release
   that version of POM with maven release plugin
   - that will have following advantages:
      - sanitized build with all smoke passed
      - no need to have snapshot version in the POM so you can easily
      release. you got the releasable candidate always.
   - dependency:
      - the projects which we are dependent on this, for this we can have
      Jenkins job to update all the child POMs so that they can pull the newly
      created version.

hope this helps

Regards,



On Wed, Apr 20, 2016 at 4:25 PM, Hohl, Gerrit <g.hohl@aurenz.de> wrote:

> Hello Stephen,
>
> I forgot that I not only have the problem in the IDE about debugging and
> viewing the code of project A from project B, I also can't do a local build
> which depends on the right version.
>
> I also have to add that the viewing even works for Eclipse using the
> Eclipse-Maven-Plugin as it recognizes only the name of the artifact when
> looking for an open project in the IDE and doesn't care for the version.
> But that is not really a feature as you will get problems if you want to
> use / debug with a version from your artifact repository which is different
> from the one which you have checked-out in your IDE.
>
> Regards,
> Gerrit
>
>
> -----Urspr√ľngliche Nachricht-----
> Von: Hohl, Gerrit [mailto:g.hohl@aurenz.de]
> Gesendet: Mittwoch, 20. April 2016 12:08
> An: Maven Users List
> Betreff: AW: Maven and Continous Integration / Continous Delivery
>
> Hello Stephen,
>
> thank you very much for your fast and long answer.
> Somehow that seems very complicated.
> And unfortunately it also doesn't answer some of my questions.
>
> Let' say we have a project A with the following POM (short version just as
> an example):
>
> <project>
>         <groupId>com.company</groupId>
>         <artificateId>project-a</artificateId>
>         <version>1.0-SNAPSHOT</version>
>         <packaging>pom</packaging>
> </project>
>
> If I build this my CI server will produce an artifact project-a-1.0.123
> (123 is the build number) and put this into the artifact repository.
>
> Then I have another project B with the following POM:
>
> <project>
>         <groupId>com.company</groupId>
>         <artificateId>project-b</artificateId>
>         <version>1.0-SNAPSHOT</version>
>         <packaging>pom</packaging>
>         <dependencyManagement>
>                 <dependencies>
>                         <groupId>com.company</groupId>
>                         <artificateId>project-a</artificateId>
>                         <version>???</version>
>                 </dependencies>
>         </dependencyManagement>
>         <dependencies>
>                 <dependency>
>                         <groupId>com.company</groupId>
>                         <artificateId>project-a</artificateId>
>                 </dependency>
>         </dependencies>
> </project>
>
> The resulting artifact will also something like project-b-1.0.234 (234 is
> the build number) and put into the artifact repository.
> But I will have the problem with the "???" at the version tag of project
> A. I can put there also "1.0-SNAPSHOT" which maybe would be okay for the
> environment of the developer. But if I want to build it on the CI server I
> have to define a unique version as I don't want that dependencies switch
> automatically and builds can't be repeated.
> If I put a defined version there I also need that defined version in the
> project A. Otherwise I will get problems in the IDE as it maybe don't
> realize that project B uses the project A which I currently have
> checked-out. Means if I do debugging I will always end up in the sources of
> the artifact downloaded from the artifact repository and not in the source
> code of project A which I also have checked-out.
>
> Regards,
> Gerrit
>
> -----Urspr√ľngliche Nachricht-----
> Von: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Gesendet: Mittwoch, 20. April 2016 11:47
> An: Maven Users List
> Betreff: Re: Maven and Continous Integration / Continous Delivery
>
> If I were doing this myself here is what I would do:
>
> I would use a MRM that has staging support and setup a Jenkins Pipeline
> that starts by doing `mvn release:prepare release:perform -B
> -DpushChanges=false -DlocalCheckout=true "-DdevelopmentVersion=dev-SNAPSHOT"
> "-DreleaseVersion=${BUILD_ID}" "-DpreparationGoals=clean validate"` it
> should also capture the GIT repo state so that the tag and release commits
> can be resurrected on a different node (because I'd be using e.g. docker
> based build slaves that are ephemeral)
>
> That will basically perform a release with the appropriate commits.
>
> Then you do the rest of your downstream tests on the release artifacts.
>
> If anything fails then I would drop the staging repo and nobody is any the
> wiser
>
> If it's all good and you are all set to push to production you now have a
> choice:
>
> * Do you want a human intervention or auto-deploy?
>
> If a human intervention - put an input step in your pipeline to get
> confirmation to continue
>
> Now we need to do the deployment for real.
>
> So we grab a node, restore the git repo and now we can push the tag
> upstream, release the staging repo and push the released artifacts into
> production.
>
>
>
>
> Now here are some of the tricks that we do with this approach:
>
>    - We do not push the release commits back to the git server, we only
>    push the tag (and only on a successful build that is being deployed into
>    production - a tag for *every* build is not necessary, alternatively you
>    could delete tags that are not needed any more and push every tag)
>
>    This is important as there could be intervening commits in master that
>    modify the pom.xml and as a result the merge may not be possible.
>    - We leave the pom with a dummy -SNAPSHOT version for developers, thus
>    they never have to worry about merge conflicts from master due to the
>    release plugin bumping version numbers
>    - We specify the release version using the build id (or some other
>    component controlled by the CI server... we want something that is
> either a
>    timestamp or a strictly increasing function)
>    - We skip the preparation checks. Because nobody will ever see the
>    borked tag, we only need to test once and we will throw away everything
> if
>    something went wrong, so nobody has to worry about broken artifacts.
>
>
> That is how I would handle it. Given a bit more time I could probably make
> it an even nicer flow (e.g. we could push the tags always, but into a
> different git repo and then we can pull those tags over to the developer
> repo for promotion to deploy
>
>
>
> On 20 April 2016 at 10:07, Hohl, Gerrit <g.hohl@aurenz.de> wrote:
>
> > Hello everyone, :-)
> >
> >
> >
> > I'm currently sitting on the book "Continuous Delivery" written by Jez
> > Humble and David Farley.
> >
> > They write that each build is a potential release candidate. And each
> > build should be triggered by the check-in into the SCM.
> >
> > So far, so good. But how do I realize that in Maven?
> >
> > Up until now the version number in our Maven projects and modules have
> > been static. If it had to be changed the developer had to perform that
> > step.
> >
> > But if the CI server performs the build as well as putting the result
> > into the repository (in our case Nexus), the resulting artifacts have
> > to include the build number in some way. Otherwise I overwrite the
> > same artifact other and other again until a developer changes the
> > version in the POM file. Depending projects then will see only the
> > last version of the artifact and builds won't be repeatable (means the
> > functionality of the artifact changes without anyone noticing it).
> >
> > One way would be to modify the POM between the check-out from the SCM
> > and the Maven build process and writing the build number into it.
> >
> > But then I will have the problem in the IDE that it don't understand
> > that the current version I've checked-out is the version I have
> > referred on in another project I've checked-out.
> >
> > If the CI server checks-in the changed POM file afterwards it will
> > trigger the next build. Also it will cause problems if the POM was
> > changed in the SCM in the meantime as the CI maybe can't merge it.
> >
> >
> >
> > Anyone solved that problem?
> >
> >
> >
> > Regards,
> >
> > Gerrit
> >
> >
> >
> >
>
> -----------------------
>  ssi,-i e-ssi@v.aer
> rdtn mn,-i e-lmeac.g
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message