Snapshot deployments by CI

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Snapshot deployments by CI

stephenconnolly
I personally think there are a lot of issues with CI automatically
deploying snapshots...

Some of these issues a social, and some are not.

Hervé, Olivier,

I suggest we start by writing down the policy you think you want... i’ll
poke holes, you fix or ack until we get a good compromise... then we can
implement.

Policy should cover:
* what to do on different branches
* who is responsible for snapshots and non snapshots

Eg

CI will auto deploy snapshots only on the master branch. Other branches
manually with the version changed to include branch name as a qualifier.
Releases will be deployed manually, ideally from the master branch only.
--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: Snapshot deployments by CI

olamy
On 9 February 2018 at 12:01, Stephen Connolly <
[hidden email]> wrote:

> Document what you think the policy should be and we'll go from there.
>
> My (current) preferred policy is:
>
>     There is no automatic deployment of snapshots. Developers can manually
> publish snapshots on an as needed basis and if they require downstream
> builds to pick those up then they need to configure the downstream jobs
> with the explicit timestamped snapshot version.


> The above, IMHO, leads to the least amount of confusion as to why specific
> builds are failing, but it does not provide as nice a user experience as I
> would like.
>
> Ideally I would like each branch name to be able to pull the latest
> snapshots from matching branch names of other repositories in the org
> folder where the artifacts were captured by Jenkins in the "verify" phase
> or by using a different "deploy" plugin. That would enable the CI server to
> manage the lifetime of those artifacts and trigger cross-repository
> dependencies. The end developers would not see these CI only artifacts, and
> would have to build and install locally. This has the advantage that your
> local build always uses what you locally installed... you don't have to
> worry about starting the next day and doing `mvn clean install` on the repo
> you were trying to debug... going to make a cup of coffee... and coming
> back to find stuff not working because you didn't see Maven doing it's "oh
> I haven't checked for newer snapshots in 24h, I last checked yesterday
> morning... oh look a new snapshot, let's ignore the snapshot that was
> installed locally at 4pm yesterday" and replacing your locally installed
> snapshot with the latest from the CI server.
>
Sorry but I don't want to go to over complicated things and too much
bureaucracy.....
IMHO The problem was more due a monolithic build of all shared/plugins
etc... (as if only one part of the source was modified everything was
rebuild and redeploy even non touched modules)
We had a very convenient auto deployment in the past of trunk(s)/master(s)
Someone modified a shared library so it's deploy then a build of downstream
projects are scheduled to verify everything is still working,
And then everything is deployed for early testers.
so it's pretty simple (and IMHO should be stay very simple as we are a very
limited number of volunteers who don't want to waste in over complicated
procedures...)

>
> But anyway, that is my opinion and rationale. We are a community, my
> opinion should not dictate what the community wants to do.
>
> I do feel that we need to write down and document what our policy actually
> is before we try and implement it.
>
>
>
> On 9 February 2018 at 09:06, Olivier Lamy <[hidden email]> wrote:
>
> > Perso I don't want anything else than master deployed..
> > wip feature branch doesn't make really sense to be deployed.
> > and makes our life easier :-)
> >
> > On 9 February 2018 at 07:40, Stephen Connolly <
> > [hidden email]> wrote:
> >
> > > I personally think there are a lot of issues with CI automatically
> > > deploying snapshots...
> > >
> > > Some of these issues a social, and some are not.
> > >
> > > Hervé, Olivier,
> > >
> > > I suggest we start by writing down the policy you think you want...
> i’ll
> > > poke holes, you fix or ack until we get a good compromise... then we
> can
> > > implement.
> > >
> > > Policy should cover:
> > > * what to do on different branches
> > > * who is responsible for snapshots and non snapshots
> > >
> > > Eg
> > >
> > > CI will auto deploy snapshots only on the master branch. Other branches
> > > manually with the version changed to include branch name as a
> qualifier.
> > > Releases will be deployed manually, ideally from the master branch
> only.
> > > --
> > > Sent from my phone
> > >
> >
> >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>



--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy