Re: Snapshot deployments by CI

[Hervé BOUTEMY]

Le samedi 10 février 2018, 00:10:14 CET Olivier Lamy a écrit :
> Policy: snaphots from master branches (and possibly long lived maintenance
> branches) are deployed automatically.
+1
for long lived branches, the version must have some differentiator from master

> 
> Build setup: downstream projects must be build after a master build and
> deploy.
if possible, that would be great

Regards,

Hervé

> 
> On 9 February 2018 at 13:03, Stephen Connolly <
> 
> stephen.alan.conno...@gmail.com> wrote:
> > Write down the policy you would like
> > 
> > On 9 February 2018 at 12:25, Olivier Lamy  wrote:
> > > On 9 February 2018 at 12:01, Stephen Connolly <
> > > 
> > > stephen.alan.conno...@gmail.com> 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  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 <
> > > > > 
> > > > > stephen.alan.conno...@gmail.com> 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
> > > > > > 
> 

Re: Snapshot deployments by CI

[Olivier Lamy]

Policy: snaphots from master branches (and possibly long lived maintenance
branches) are deployed automatically.

Build setup: downstream projects must be build after a master build and
deploy.

On 9 February 2018 at 13:03, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Write down the policy you would like
>
> On 9 February 2018 at 12:25, Olivier Lamy  wrote:
>
> > On 9 February 2018 at 12:01, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> 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  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 <
> > > > stephen.alan.conno...@gmail.com> 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
> >
>



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

Re: Snapshot deployments by CI

[Stephen Connolly]

Write down the policy you would like

On 9 February 2018 at 12:25, Olivier Lamy  wrote:

> On 9 February 2018 at 12:01, Stephen Connolly <
> stephen.alan.conno...@gmail.com> 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  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 <
> > > stephen.alan.conno...@gmail.com> 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
>

Re: Snapshot deployments by CI

[Olivier Lamy]

On 9 February 2018 at 12:01, Stephen Connolly <
stephen.alan.conno...@gmail.com> 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  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 <
> > stephen.alan.conno...@gmail.com> 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

Re: Snapshot deployments by CI

[Stephen Connolly]

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.

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  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 <
> stephen.alan.conno...@gmail.com> 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
>

Re: Snapshot deployments by CI

[Olivier Lamy]

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 <
stephen.alan.conno...@gmail.com> 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

Snapshot deployments by CI

[Stephen Connolly]

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