Re: [pre-verify over deploy]

2014-10-29 Thread Fay Wong
2014-10-30 6:15 GMT+08:00 Barrie Treloar :

> On 30 October 2014 08:38, Curtis Rueden  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]

2014-10-29 Thread Fay Wong
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 :

> On 29 October 2014 14:00, Fay Wong  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.
>


[pre-verify over deploy]

2014-10-28 Thread Fay Wong
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