On Fri, Sep 25, 2015 at 10:53 AM, Bernd <e...@zusammenkunft.net> wrote:
> Hello Ben, > > 2015-09-23 0:28 GMT+02:00 Ben Podgursky <bpodgur...@gmail.com>: > > > +1 for aggressive SNAPSHOT use > > > > Our setup. YMMV: > > > > ... > > > > > - All developers have all code checked out in intellij, source linked > > - If you push changes to a library, you update all downstream usages. No > > exceptions. Since you have all source in intellij, this usually isn't > > hard. > > > > How do you deal with changes to multiple projects (as you suggest) when > you do not use a mono repository? When one commit kicks off Jenkins it > might as well not yet see the "fixed" snapshot dependency. Do you use > atomic commits or a monorepo or do you trigger jenkin builds only by time? > > We encourage devs to do non-breaking migrations when possible -- deprecate, switch usages, and then remove the old methods. When that's not practical, we just push everything at once. Since projects and builds are small and short (almost all < 10 min), we just live with a broken build for a couple minutes while upstream deploys run. But it's the responsibility of the dev making the changes to make sure everything is converging cleanly or revert the changes. > BTW: just my few cents, we added Gerrit to the mix, so we can have > pre-commit builds. But those only run the tests for the modified project, > they do not integrate. The normal CI jobs are triggert when submitting the > change (but typically no downstream projekt gets the snapshots as we have > them locked on releases. Once you do the release and add the dependency to > the BOM (or less often to dependend projects) another integration build > triggers a while pipeline (producing ultimatively a new installation media > which gets automatically integration tested). > > Gruss > Bernd >
