I see these discussions often, and I wanted to jump in and mention how we handle continuous deploys, because I feel that it avoids many of the downsides mentioned here, albeit with some (IMO) minor costs:
- all of our internal dependencies are SNAPSHOT. we do not do releases, ever, or ever depend on a fixed version - we attach to the package phase of our builds an assembly which packages the artifact and all of the dependencies it tested against into a tar.gz - we deploy the tar.gz to our artifact server with a snapshot version (ex, MY_PROJECT-1.0-deploy.tar.gz) - when deploying we simply take the last snapshot deploy artifact and unzip it in production (+ some config files etc). so while you use SNAPSHOT versions, you are guaranteed that you are deploying against tested dependencies. and you never have to commit updated dependency versions, do releases, etc. the only real cost is a bit of artifact server disk space… but disk space is incredibly cheap. On Thu, May 5, 2016 at 2:13 AM, Stephen Connolly < [email protected]> wrote: > On 5 May 2016 at 10:00, Robert Scholte <[email protected]> wrote: > > > Hi Stephen, nice blog. > > > > There are a few things I'd like to share: > > - The maven-release-plugin does several checks which ensures that you > have > > a reproducible artifact, where checking on SNAPSHOT dependencies is one > of > > the most important ones. (you can find a lot patterns based on the > > versions-maven-plugin on the web, but they forget these checks) > > > > This is one of the reasons why my suggestion is to actually cut a release > for every commit (just only push the tag - and just the tag - if the > release goes anywhere) > > > > - I still have this wish to have support a couple of strategies within > the > > maven-release-plugin, this could be one as well. > > > > Yes, I think it would be a valuable one to have in the default plugin, for > sure... and it may need some assistance from the scm plugin too > > > > > > In a continuous environment is becomes more and more important to be able > > to reproduce issues, which can be hard when things keep changing. This > > might even work with SNAPSHOT dependencies if your can get the > > distributable (either the deployable or executable artifact, assuming > they > > contain all the required dependencies) and have a testing setup which can > > test with this artifact. If you can reproduce it here, you can (re)write > it > > as an appropriate test and fix it. > > So next to all the current tests you need to do regression tests on the > > distributable as well. > > As long as this is not possible or secured in your pipeline, you should > > NEVER EVER want to depend on SNAPSHOT-dependencies. > > > > +1 > > One that we gain with the approach I suggest is that we can actually use > versions:resolve-ranges as we know that the pom will not be pushed back to > master. > > Thus developers can keep version ranges in the pom and the CI build will > resolve the ranges for each "release" > > I'd like to find a way to allow resolve-ranges to work with the current > release plugin flow... my working idea has been to inject e.g. XML PI > entities into the pom so that we know what range to restore, e.g. > pre-release pom has > > <dependency> > ... > <version>[1.2,2.0)</version> > </dependency> > > which would get resolved into the release pom as > > <dependency> > ... > <version>1.5<?versions-maven-plugin original="[1.2,2.0)"?></version> > </dependency> > > so that when we want to un-pin we can then see the original range and > up-lift it so that the development pom becomes > > <dependency> > ... > <version>[1.5,2.0)</version> > </dependency> > > > > > > > thanks, > > Robert > > > > > > On Wed, 04 May 2016 21:20:01 +0200, Stephen Connolly < > > [email protected]> wrote: > > > > Here's an embryonic idea I had for doing Continuous Delivery with Maven > >> > >> > >> > https://www.cloudbees.com/blog/new-way-do-continuous-delivery-maven-and-jenkins-pipeline > >> > >> Probably needs a little fleshing out. > >> > >> -Stephen > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
