Loading…
This event has ended. Create your own event on Sched.
View analytic
Wednesday, September 28 • 2:00pm - 2:55pm
Vision of a Future Ideal Integration (build) Architecture to Never Have Any Build Failures - Michael Vorburger, Red Hat

Sign up or log in to save this to your schedule and see who's attending!

We kick off a number of sometimes fairly long running build jobs on each change (verify, distribution, validate), yet we cannot always reliably detect mechanical build failing problems such as e.g. what happened inhttps://git.opendaylight.org/gerrit/#/c/43594/ (a parent pom.xml change which broke the build of downstream projects depending on it - despite getting a Verified+1 Build Successful from jenkins-releng), or Checkstyle rule changes which need a manual process to gauge build impacts (why can we not just raise any kind of proposed change and see ALL impacts on Gerrit, automatically?), and probably other kind of changes (please edit this and insert specific examples of other limitation you have run into?).

One possible solution to this problem could be to move away from continuously integrating all ODL projects every day (by way of Maven's SNAPSHOT concept) and move to completely stable fixed release artefacts; see various emails on the lists re. "Fast and/or Phased", e.g. https://lists.opendaylight.org/pipermail/discuss/2016-July/006751.html. One of the risks of that kind of approach is typically that projects will start to lag behind, and while stable in the present, have to eat the cost of adapting to changes in the future when they upgrade?

Another possible solution to this problem could be to look more seriously at enforcing API baseline contracts kind of tools (OSGi-based for ODL; but there are others too) - but IMHO it's very hard or impossible to cover things like pom.xml changes or Checkstyle rules with the existing tools in that space, which are typically focused on Java API changes. This kind of stuff is probably still relevant for automated API compatibility checks across releases, but may not be the right answer for fast in-development change management.

Could another solution for this area be to simply continuously integrate the *entire* ODL caboodle for *every* change - but still do this so fast that it's viable in practice? Imagine you would be guaranteed to always see all build failure impacts incl. broken Maven, compilation, tests etc. of any change on all dependant downstream projects (which are on opendaylight.org; external projects should use release and not SNAPSHOT artifacts, and if they do use SNAPSHOT there is little we can do about them). 

To even dream about this, the only realistic path is probably that a build of a Change on Jenkins would have to be able to re-build incrementally only what changed and what that change impacts - incl. autom. taking dependencies impacts into account! What would need to happen to make this possible?

This is intended to be a high level "let's dream" vision type of session. In the initial discussion we should not let ourselves be held back with "that's not possible with Maven" kind of limitations, but establish an ideal goal, and then back-track to what would have to be done to achieve that goal. If that's another build technology (Gradle.org? BuckBuild.com? Even more exotic fruits?), no harm in dreaming about it together for the first half of the discussion. In the second half, we could try to break down what this would mean in practice if together we were to do anything about it, and who would like to fund what portions of such an effort.

Speakers
MV

Michael Vorburger

Michael, see http://www.vorburger.ch & links, is a passionate open source hacker with a background in model driven development, and has spoken at a number of tech. conferences in the past. His hobbies include building educational Minecraft server platforms. He joined Red Hat in April 2016 from Banking ISV Temenos, where he was the Product Manager for Eclipse related products.


Wednesday September 28, 2016 2:00pm - 2:55pm
Room 403

Attendees (9)