http://developer-blog.cloudbees.com/2012/12/should-you-deploy-snapshots.html
On 29 October 2014 08:18, Fay Wong <philip584...@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 <baerr...@gmail.com>: > > > On 29 October 2014 14:00, Fay Wong <philip584...@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. > > >
