1 / 10

Versioning and Automated Weekly Releases

Versioning and Automated Weekly Releases. Current Challenges. There are over 250 bundles carrying different versions in OpenDaylight Automated release process using maven release plugin does not work reliably because of the way current pom files are structured

ahartman
Télécharger la présentation

Versioning and Automated Weekly Releases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Versioning and Automated Weekly Releases

  2. Current Challenges • There are over 250 bundles carrying different versions in OpenDaylight • Automated release process using maven release plugin does not work reliably because of the way current pom files are structured • When it is time to release, lot of time is wasted fixing pom files manually which makes the release very error prone

  3. Current Challenges – Few Examples • Multiple parent pom’s within a given module • For example, mdsal in controller project has 2 parents: sal-parent at version: 1.1-SNAPSHOT and compatibility parent which is also at 1.1-SNAPSHOT. Both of these parents are pointing to another parent which is at 1.4.2-SNAPSHOT. • Bundle versions not derived from the parent • In UserManager pom file, the parent version is defined as 1 .4.2-SNAPSHOT but the bundle version is 0.4.2-SNAPSHOT • Cross project dependencies listed directly in the Bundle POM instead of deriving it from the parent

  4. Proposed Solution - Overview

  5. Proposed Solution • Have only one version per project/git repo • Have only one parent per project unless otherwise necessary • Define a global pom which is common to all the projects participating in simultaneous release • This global pom will maintain the release version which could be $MAJOR.$MINOR-$BUILD_NUMBER • All sub-project’s parents will inherit the global pom file

  6. Proposed Solution • Project dependency versions have to be defined as properties in the parent pom and should not be hardcoded in the module pom’s • Schedule automated weekly release for each project participating in simultaneous release using maven versions plugin + maven release plugin + Jenkins • Use consistent naming convention for git tags for all projects in simultaneous release

  7. Current Maven Dependency tree

  8. Future Maven Dependency tree

  9. Demo

  10. Future Considerations • After the pom files are re-structured and release automation is in place, there is a possibility that pom files can get into similar situation very quickly. • To prevent this from happening, we can have a gerrit pre-commit gate that validates the pom files, if a pom file is part of the commit. • If the pom file does not meet the criteria, jenkins verification build will fail for that particular project

More Related