[pre-verify over deploy]

[Fay Wong <ph...@gmail.com>]

Hi all,

Is there any solution to pre-verify the deploy before it actually got into
the repository?

Take this usecase for example:

In a team of 40 developer, every developer will deploy their module at any
time, once there's a error,

the final output software won't work and blocks other developer's flow.

So is there any pre-verify solution(such as jenkins CI-server) to be
enforced before the deploy overlapped the previous deploy?


Thanks,
faywong

Re: [pre-verify over deploy]

[Fay Wong <ph...@gmail.com>]

2014-10-30 6:15 GMT+08:00 Barrie Treloar <ba...@gmail.com>:

> On 30 October 2014 08:38, Curtis Rueden <ct...@wisc.edu> wrote:
>
> > Hi Fay,
> >
> > > Could i define a intermediate repository, everytime they deploy,
> > > jenkins will verify it.
> >
> > Why not have Jenkins do your deploys? I.e.: make it so that only Jenkins
> > has deploy permission to your remote repository. So your devs can no
> longer
> > run "mvn deploy" from the CLI and expect it to work, but instead just
> push
> > to master (or whatever integration branch) and then Jenkins runs the
> build.
> >
> > Once Jenkins does your deploys, you can set up your jobs to test for more
> > stringent conditions before actually doing the deploy. E.g.:
> >
> > $ git clean -fdx
> > $ mvn clean install
> > $ bin/verify-artifacts.sh
> > $ mvn deploy
> >
> > And "verify-artifacts.sh" does whatever further programmatic testing you
> > need.
> >
> > OTOH, in many cases, you don't need a shell script -- often times, you
> can
> > get what you need using Maven plugins like Surefire, Failsafe, and
> > Enforcer. If you go that route, it might be enough so that devs running
> > "mvn deploy" won't deploy bad stuff to the repo by default (unless they
> are
> > aggressive enough to run e.g. "mvn -DskipTests deploy" which would be
> > pretty bold).
> >
> > Regards,
> > Curtis
>
>
> Whether its Jenkins, or a developer, you've still pushed a release that
> could break the build.
>
> This is where you need some isolation available to your workflow.
>
> Stuff breaks - it happens, Fay needs to determine how they want to deal
> with it.
>

>>This is where you need some isolation available to your workflow.
Yes. Some other human engineering way(such as buys the first round of beer)
maybe can't solve this issue. I do need some defensive isolation to prevent
some guy from blocking others' develop process.

>>Why not have Jenkins do your deploys?
Maybe there's another process constraint i forget to mention:
The integration of source code & bytecode(the build output) follow
different flow and can't keep sync with each other.
If they keep sync with each other, Jenkins can do the right work.

Re: [pre-verify over deploy]

[Curtis Rueden <ct...@wisc.edu>]

Hi Barrie,

> Whether its Jenkins, or a developer, you've still pushed a release
> that could break the build.
>
> This is where you need some isolation available to your workflow.

Agreed!

However, for Fay's stated requirement, it may be sufficient to have a
broken master branch as long as the latest deployed SNAPSHOT is not broken,
since he stated:

> Currently my pain is our developer would deploy broken bytecode to our
> dev repository and broken others work.

Regards,
Curtis

On Wed, Oct 29, 2014 at 5:15 PM, Barrie Treloar <ba...@gmail.com> wrote:

> On 30 October 2014 08:38, Curtis Rueden <ct...@wisc.edu> wrote:
>
> > Hi Fay,
> >
> > > Could i define a intermediate repository, everytime they deploy,
> > > jenkins will verify it.
> >
> > Why not have Jenkins do your deploys? I.e.: make it so that only Jenkins
> > has deploy permission to your remote repository. So your devs can no
> longer
> > run "mvn deploy" from the CLI and expect it to work, but instead just
> push
> > to master (or whatever integration branch) and then Jenkins runs the
> build.
> >
> > Once Jenkins does your deploys, you can set up your jobs to test for more
> > stringent conditions before actually doing the deploy. E.g.:
> >
> > $ git clean -fdx
> > $ mvn clean install
> > $ bin/verify-artifacts.sh
> > $ mvn deploy
> >
> > And "verify-artifacts.sh" does whatever further programmatic testing you
> > need.
> >
> > OTOH, in many cases, you don't need a shell script -- often times, you
> can
> > get what you need using Maven plugins like Surefire, Failsafe, and
> > Enforcer. If you go that route, it might be enough so that devs running
> > "mvn deploy" won't deploy bad stuff to the repo by default (unless they
> are
> > aggressive enough to run e.g. "mvn -DskipTests deploy" which would be
> > pretty bold).
> >
> > Regards,
> > Curtis
>
>
> Whether its Jenkins, or a developer, you've still pushed a release that
> could break the build.
>
> This is where you need some isolation available to your workflow.
>
> Stuff breaks - it happens, Fay needs to determine how they want to deal
> with it.
>

Re: [pre-verify over deploy]

[Barrie Treloar <ba...@gmail.com>]

On 30 October 2014 08:38, Curtis Rueden <ct...@wisc.edu> wrote:

> Hi Fay,
>
> > Could i define a intermediate repository, everytime they deploy,
> > jenkins will verify it.
>
> Why not have Jenkins do your deploys? I.e.: make it so that only Jenkins
> has deploy permission to your remote repository. So your devs can no longer
> run "mvn deploy" from the CLI and expect it to work, but instead just push
> to master (or whatever integration branch) and then Jenkins runs the build.
>
> Once Jenkins does your deploys, you can set up your jobs to test for more
> stringent conditions before actually doing the deploy. E.g.:
>
> $ git clean -fdx
> $ mvn clean install
> $ bin/verify-artifacts.sh
> $ mvn deploy
>
> And "verify-artifacts.sh" does whatever further programmatic testing you
> need.
>
> OTOH, in many cases, you don't need a shell script -- often times, you can
> get what you need using Maven plugins like Surefire, Failsafe, and
> Enforcer. If you go that route, it might be enough so that devs running
> "mvn deploy" won't deploy bad stuff to the repo by default (unless they are
> aggressive enough to run e.g. "mvn -DskipTests deploy" which would be
> pretty bold).
>
> Regards,
> Curtis


Whether its Jenkins, or a developer, you've still pushed a release that
could break the build.

This is where you need some isolation available to your workflow.

Stuff breaks - it happens, Fay needs to determine how they want to deal
with it.

Re: [pre-verify over deploy]

[Curtis Rueden <ct...@wisc.edu>]

Hi Fay,

> Could i define a intermediate repository, everytime they deploy,
> jenkins will verify it.

Why not have Jenkins do your deploys? I.e.: make it so that only Jenkins
has deploy permission to your remote repository. So your devs can no longer
run "mvn deploy" from the CLI and expect it to work, but instead just push
to master (or whatever integration branch) and then Jenkins runs the build.

Once Jenkins does your deploys, you can set up your jobs to test for more
stringent conditions before actually doing the deploy. E.g.:

$ git clean -fdx
$ mvn clean install
$ bin/verify-artifacts.sh
$ mvn deploy

And "verify-artifacts.sh" does whatever further programmatic testing you
need.

OTOH, in many cases, you don't need a shell script -- often times, you can
get what you need using Maven plugins like Surefire, Failsafe, and
Enforcer. If you go that route, it might be enough so that devs running
"mvn deploy" won't deploy bad stuff to the repo by default (unless they are
aggressive enough to run e.g. "mvn -DskipTests deploy" which would be
pretty bold).

Regards,
Curtis

On Wed, Oct 29, 2014 at 3:18 AM, Fay Wong <ph...@gmail.com> wrote:

> Many thanks to Barrie.
>
> I think what you have clarified is the normal flow of maven practice.
>
> The "deploy" in the context of my previous post means: our developer invoke
> a "mvn deploy" command to share the output(bytecode) through the repository
> so as to shorten the build time of whole project(as its code base is too
> large). Our goal is modular compiling and packaging.
>
> Currently my pain is our developer would deploy broken bytecode to our dev
> repository and broken others work. Could i define a intermediate
> repository, everytime they deploy, jenkins will verify it. if pass, then
> depoy it into dev repository, otherwise, revert the intermediate repository
> to keep sync with dev repository.
>
> Is there a easier way to achieve this?
>
> 2014-10-29 13:07 GMT+08:00 Barrie Treloar <ba...@gmail.com>:
>
> > On 29 October 2014 14:00, Fay Wong <ph...@gmail.com> wrote:
> >
> > > Hi all,
> > >
> > > Is there any solution to pre-verify the deploy before it actually got
> > into
> > > the repository?
> > >
> > > Take this usecase for example:
> > >
> > > In a team of 40 developer, every developer will deploy their module at
> > any
> > > time, once there's a error,
> > >
> > > the final output software won't work and blocks other developer's flow.
> > >
> > > So is there any pre-verify solution(such as jenkins CI-server) to be
> > > enforced before the deploy overlapped the previous deploy?
> >
> >
> > Not really, this is a process issue.
> >
> > You need to decide what is in a state of flux, and then when people
> should
> > consume it.
> >
> > I'm assuming by "deploy" you mean a released artifact and not a snapshot
> > one.
> > Generally, you should not be deploying your snapshots for consumption by
> > other developers, as snapshots could break at any time and you impact
> > anyone who depends upon them.
> > Instead, when a developer needs a snapshot version they check out the
> code
> > and building it themselves, then when they need to import new changes
> they
> > pull in the changes to the code and rebuild. That way the developer gets
> to
> > choose when they will consume potentially breaking changes.
> >
> > If these are released artifacts then you have lots of choices on how to
> do
> > this.
> > *) By using your version control system and some form of isolation (e.g.
> > branches).
> >    When the new version is released the developer still needs to pull
> those
> > changes in, and if there are breaking changes can revert back to the
> > previous version.
> > *) Have someone in a QA role validate that the artifact works prior to
> > promoting that version in you parent pom.
> >
> > The act of deploying into your Maven Repository is independent from the
> > consumption of that artifact, it shouldn't be breaking peoples build
> until
> > they start using it.
> >
>

Re: [pre-verify over deploy]

[Bernd <ec...@zusammenkunft.net>]

Hello,

Thanks Stephen for that writeup. It is a good read. For my taste it
over-emphasises the moving ground problem. I mean when cooperating with
larger projects and lots of developers you get all kinds of problems, but
beeing affected by breaking changes of updating snapshots - I cant remember
to ever experience that. In fact when SNAPSHOTs change in a severe way it
is most likely that I have waited for it, I manually refreshed the
dependencies and I am actually happy to see the changes as early as
possible (before integrating into a system which isnt working since days
and only my old snapshots hide this from me).

But having said that, I also do enjoy an environment with releasing often.
This allows each team to decide when to pull in which (released) changes,
and this indeed lowers the frequency of broken builds (however it also
encourages developers to wait too long with the integration, if you dont
nudge them with deoendency upgrade reports).

Gruss
Bernd
Am 03.11.2014 10:39 schrieb "Stephen Connolly" <
stephen.alan.connolly@gmail.com>:

> Well I knew I'd written something on that topic... but re-reading I am
> surprised at how much information I managed to cram in there without it
> feeling over dense (for me)
>
> BTW I am of the *never deploy -SNAPSHOTs* camp but I recognise that there
> are other people out there... and I have to interact with them some times
> and that post is helpful to explain things to them!
>
> On 3 November 2014 01:57, Barrie Treloar <ba...@gmail.com> wrote:
>
> > On 29 October 2014 20:18, Stephen Connolly <
> > stephen.alan.connolly@gmail.com>
> > wrote:
> >
> > >
> > >
> >
> http://developer-blog.cloudbees.com/2012/12/should-you-deploy-snapshots.html
> >
> >
> > Thanks for writing that up!
> > I'll remember to point people there instead of having to remember
> > half-baked stuff and type :)
> >
> > This is a useful piece of advice
> > "especially in conjunction with the Versions Maven Plugin
> > <http://mojo.codehaus.org/versions-maven-plugin/lock-snapshots-mojo.html
> >
> > which
> > has goals for “locking” and “unlocking” your -SNAPSHOT dependencies to
> the
> > current timestamp version, thereby removing uncertainty. "
> > It will allow you to live dangerously on shifting sands and then when you
> > get sucked under to go back and lock to a working version.
> > But I still think you are better off avoiding that problem in the first
> > place.
> >
>

Re: [pre-verify over deploy]

[Barrie Treloar <ba...@gmail.com>]

On 3 November 2014 20:07, Stephen Connolly <st...@gmail.com>
wrote:

> Well I knew I'd written something on that topic... but re-reading I am
> surprised at how much information I managed to cram in there without it
> feeling over dense (for me)
>
> BTW I am of the *never deploy -SNAPSHOTs* camp but I recognise that there
> are other people out there... and I have to interact with them some times
> and that post is helpful to explain things to them!
>

I think its important for people to try things, because this stuff is
complicated, and unless you get yours hands dirty it is difficult to
understand and get a feel for why it doesn't work.

After you have been burnt by a dependency being updated from underneath you
- one that you have your own changes in - then you realise that you need to
"build twice" to rebuild the other snapshot to keep going, and that the
other developers haven't gotten their head around the build process and why
things sometimes dont work... It makes life simpler to avoid deploying the
snapshots for developer consumption.

Re: [pre-verify over deploy]

[Stephen Connolly <st...@gmail.com>]

Well I knew I'd written something on that topic... but re-reading I am
surprised at how much information I managed to cram in there without it
feeling over dense (for me)

BTW I am of the *never deploy -SNAPSHOTs* camp but I recognise that there
are other people out there... and I have to interact with them some times
and that post is helpful to explain things to them!

On 3 November 2014 01:57, Barrie Treloar <ba...@gmail.com> wrote:

> On 29 October 2014 20:18, Stephen Connolly <
> stephen.alan.connolly@gmail.com>
> wrote:
>
> >
> >
> http://developer-blog.cloudbees.com/2012/12/should-you-deploy-snapshots.html
>
>
> Thanks for writing that up!
> I'll remember to point people there instead of having to remember
> half-baked stuff and type :)
>
> This is a useful piece of advice
> "especially in conjunction with the Versions Maven Plugin
> <http://mojo.codehaus.org/versions-maven-plugin/lock-snapshots-mojo.html>
> which
> has goals for “locking” and “unlocking” your -SNAPSHOT dependencies to the
> current timestamp version, thereby removing uncertainty. "
> It will allow you to live dangerously on shifting sands and then when you
> get sucked under to go back and lock to a working version.
> But I still think you are better off avoiding that problem in the first
> place.
>

Re: [pre-verify over deploy]

[Barrie Treloar <ba...@gmail.com>]

On 29 October 2014 20:18, Stephen Connolly <st...@gmail.com>
wrote:

>
> http://developer-blog.cloudbees.com/2012/12/should-you-deploy-snapshots.html


Thanks for writing that up!
I'll remember to point people there instead of having to remember
half-baked stuff and type :)

This is a useful piece of advice
"especially in conjunction with the Versions Maven Plugin
<http://mojo.codehaus.org/versions-maven-plugin/lock-snapshots-mojo.html> which
has goals for “locking” and “unlocking” your -SNAPSHOT dependencies to the
current timestamp version, thereby removing uncertainty. "
It will allow you to live dangerously on shifting sands and then when you
get sucked under to go back and lock to a working version.
But I still think you are better off avoiding that problem in the first
place.

Re: [pre-verify over deploy]

[Stephen Connolly <st...@gmail.com>]

http://developer-blog.cloudbees.com/2012/12/should-you-deploy-snapshots.html

On 29 October 2014 08:18, Fay Wong <ph...@gmail.com> wrote:

> Many thanks to Barrie.
>
> I think what you have clarified is the normal flow of maven practice.
>
> The "deploy" in the context of my previous post means: our developer invoke
> a "mvn deploy" command to share the output(bytecode) through the repository
> so as to shorten the build time of whole project(as its code base is too
> large). Our goal is modular compiling and packaging.
>
> Currently my pain is our developer would deploy broken bytecode to our dev
> repository and broken others work. Could i define a intermediate
> repository, everytime they deploy, jenkins will verify it. if pass, then
> depoy it into dev repository, otherwise, revert the intermediate repository
> to keep sync with dev repository.
>
> Is there a easier way to achieve this?
>
> 2014-10-29 13:07 GMT+08:00 Barrie Treloar <ba...@gmail.com>:
>
> > On 29 October 2014 14:00, Fay Wong <ph...@gmail.com> wrote:
> >
> > > Hi all,
> > >
> > > Is there any solution to pre-verify the deploy before it actually got
> > into
> > > the repository?
> > >
> > > Take this usecase for example:
> > >
> > > In a team of 40 developer, every developer will deploy their module at
> > any
> > > time, once there's a error,
> > >
> > > the final output software won't work and blocks other developer's flow.
> > >
> > > So is there any pre-verify solution(such as jenkins CI-server) to be
> > > enforced before the deploy overlapped the previous deploy?
> >
> >
> > Not really, this is a process issue.
> >
> > You need to decide what is in a state of flux, and then when people
> should
> > consume it.
> >
> > I'm assuming by "deploy" you mean a released artifact and not a snapshot
> > one.
> > Generally, you should not be deploying your snapshots for consumption by
> > other developers, as snapshots could break at any time and you impact
> > anyone who depends upon them.
> > Instead, when a developer needs a snapshot version they check out the
> code
> > and building it themselves, then when they need to import new changes
> they
> > pull in the changes to the code and rebuild. That way the developer gets
> to
> > choose when they will consume potentially breaking changes.
> >
> > If these are released artifacts then you have lots of choices on how to
> do
> > this.
> > *) By using your version control system and some form of isolation (e.g.
> > branches).
> >    When the new version is released the developer still needs to pull
> those
> > changes in, and if there are breaking changes can revert back to the
> > previous version.
> > *) Have someone in a QA role validate that the artifact works prior to
> > promoting that version in you parent pom.
> >
> > The act of deploying into your Maven Repository is independent from the
> > consumption of that artifact, it shouldn't be breaking peoples build
> until
> > they start using it.
> >
>

Re: [pre-verify over deploy]

[Ron Wheeler <rw...@artifact-software.com>]

On 29/10/2014 5:19 AM, Barrie Treloar wrote:
> On 29 October 2014 18:48, Fay Wong <ph...@gmail.com> wrote:
>
>> Many thanks to Barrie.
>>
>> I think what you have clarified is the normal flow of maven practice.
>>
>> The "deploy" in the context of my previous post means: our developer invoke
>> a "mvn deploy" command to share the output(bytecode) through the repository
>> so as to shorten the build time of whole project(as its code base is too
>> large). Our goal is modular compiling and packaging.
>>
>> Currently my pain is our developer would deploy broken bytecode to our dev
>> repository and broken others work. Could i define a intermediate
>> repository, everytime they deploy, jenkins will verify it. if pass, then
>> depoy it into dev repository, otherwise, revert the intermediate repository
>> to keep sync with dev repository.
>>
>> Is there a easier way to achieve this?
>>
> There is the stick, or the carrot.
>
> The paid version of Nexus (a Maven Repository Manager) has staging
> repositories, I dont use them, you may be able to get them to do what you
> want.
>
> Either way its a process issue.
> Teach your developers to stop breaking the build.
> Or use one of the options I've suggested.
>
It is really a human engineering problem:
1) Whoever breaks the build buys the first round of beer or has to buy 
pizza for the team on Friday. Works for a small team that socializes 
together.
2) Build Breaker of the month club. Post the picture of the last person 
to break the build. If it is a widespread problem, offer reward each 
quarter to people who do not break the build - day-off, lunch with the 
boss at a good restaurant. Keep a scorecard of who is out and who is 
still in the running.
3)Track build breaking as a performance indicator when doing assessments.
4) If a person consistently (you can define this) breaks the build, take 
away their deploy rights so that they have to find someone to deploy 
their stuff and they will have to prove to that person that it has been 
tested. Hurts the pride.
If no one will deploy their stuff, fire them. The team has lost 
confidence in their ability to do the work.
Or just assign them work that does not affect the build - test data 
creation, testing UI, etc.


Or move to Nexus-Pro.

Ron

-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [pre-verify over deploy]

[Barrie Treloar <ba...@gmail.com>]

On 29 October 2014 18:48, Fay Wong <ph...@gmail.com> wrote:

> Many thanks to Barrie.
>
> I think what you have clarified is the normal flow of maven practice.
>
> The "deploy" in the context of my previous post means: our developer invoke
> a "mvn deploy" command to share the output(bytecode) through the repository
> so as to shorten the build time of whole project(as its code base is too
> large). Our goal is modular compiling and packaging.
>
> Currently my pain is our developer would deploy broken bytecode to our dev
> repository and broken others work. Could i define a intermediate
> repository, everytime they deploy, jenkins will verify it. if pass, then
> depoy it into dev repository, otherwise, revert the intermediate repository
> to keep sync with dev repository.
>
> Is there a easier way to achieve this?
>

There is the stick, or the carrot.

The paid version of Nexus (a Maven Repository Manager) has staging
repositories, I dont use them, you may be able to get them to do what you
want.

Either way its a process issue.
Teach your developers to stop breaking the build.
Or use one of the options I've suggested.

Re: [pre-verify over deploy]

[Fay Wong <ph...@gmail.com>]

Many thanks to Barrie.

I think what you have clarified is the normal flow of maven practice.

The "deploy" in the context of my previous post means: our developer invoke
a "mvn deploy" command to share the output(bytecode) through the repository
so as to shorten the build time of whole project(as its code base is too
large). Our goal is modular compiling and packaging.

Currently my pain is our developer would deploy broken bytecode to our dev
repository and broken others work. Could i define a intermediate
repository, everytime they deploy, jenkins will verify it. if pass, then
depoy it into dev repository, otherwise, revert the intermediate repository
to keep sync with dev repository.

Is there a easier way to achieve this?

2014-10-29 13:07 GMT+08:00 Barrie Treloar <ba...@gmail.com>:

> On 29 October 2014 14:00, Fay Wong <ph...@gmail.com> wrote:
>
> > Hi all,
> >
> > Is there any solution to pre-verify the deploy before it actually got
> into
> > the repository?
> >
> > Take this usecase for example:
> >
> > In a team of 40 developer, every developer will deploy their module at
> any
> > time, once there's a error,
> >
> > the final output software won't work and blocks other developer's flow.
> >
> > So is there any pre-verify solution(such as jenkins CI-server) to be
> > enforced before the deploy overlapped the previous deploy?
>
>
> Not really, this is a process issue.
>
> You need to decide what is in a state of flux, and then when people should
> consume it.
>
> I'm assuming by "deploy" you mean a released artifact and not a snapshot
> one.
> Generally, you should not be deploying your snapshots for consumption by
> other developers, as snapshots could break at any time and you impact
> anyone who depends upon them.
> Instead, when a developer needs a snapshot version they check out the code
> and building it themselves, then when they need to import new changes they
> pull in the changes to the code and rebuild. That way the developer gets to
> choose when they will consume potentially breaking changes.
>
> If these are released artifacts then you have lots of choices on how to do
> this.
> *) By using your version control system and some form of isolation (e.g.
> branches).
>    When the new version is released the developer still needs to pull those
> changes in, and if there are breaking changes can revert back to the
> previous version.
> *) Have someone in a QA role validate that the artifact works prior to
> promoting that version in you parent pom.
>
> The act of deploying into your Maven Repository is independent from the
> consumption of that artifact, it shouldn't be breaking peoples build until
> they start using it.
>

Re: [pre-verify over deploy]

[Barrie Treloar <ba...@gmail.com>]

On 29 October 2014 14:00, Fay Wong <ph...@gmail.com> wrote:

> Hi all,
>
> Is there any solution to pre-verify the deploy before it actually got into
> the repository?
>
> Take this usecase for example:
>
> In a team of 40 developer, every developer will deploy their module at any
> time, once there's a error,
>
> the final output software won't work and blocks other developer's flow.
>
> So is there any pre-verify solution(such as jenkins CI-server) to be
> enforced before the deploy overlapped the previous deploy?


Not really, this is a process issue.

You need to decide what is in a state of flux, and then when people should
consume it.

I'm assuming by "deploy" you mean a released artifact and not a snapshot
one.
Generally, you should not be deploying your snapshots for consumption by
other developers, as snapshots could break at any time and you impact
anyone who depends upon them.
Instead, when a developer needs a snapshot version they check out the code
and building it themselves, then when they need to import new changes they
pull in the changes to the code and rebuild. That way the developer gets to
choose when they will consume potentially breaking changes.

If these are released artifacts then you have lots of choices on how to do
this.
*) By using your version control system and some form of isolation (e.g.
branches).
   When the new version is released the developer still needs to pull those
changes in, and if there are breaking changes can revert back to the
previous version.
*) Have someone in a QA role validate that the artifact works prior to
promoting that version in you parent pom.

The act of deploying into your Maven Repository is independent from the
consumption of that artifact, it shouldn't be breaking peoples build until
they start using it.