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