maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Podgursky <bpodgur...@gmail.com>
Subject Re: An idea I had for one way of doing Continuous Delivery with Maven
Date Fri, 06 May 2016 00:19:08 GMT
sorry, meant " MY_PROJECT-1.0-SNAPSHOT-deploy.tar.gz"

On Thu, May 5, 2016 at 5:18 PM, Ben Podgursky <bpodgursky@gmail.com> wrote:

> 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 <
> stephen.alan.connolly@gmail.com> wrote:
>
>> On 5 May 2016 at 10:00, Robert Scholte <rfscholte@apache.org> 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 <
>> > stephen.alan.connolly@gmail.com> 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: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>> >
>>
>
>

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