1 / 9

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

kalkin
Download Presentation

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. Proposed Solution • Create a top level root parent pom that is above all the projects • Move all the common external dependencies, dependency management, versions, plugin management etc to this pom • Have only one parent per project unless otherwise necessary • Separate aggregator pom from the parent and each project defines it’s parent in /parent directory of the project • Project level parent pom is used to override defaults which are otherwise derived from the root parent pom. • All the submodule and interproject dependency versions must be specified as a property in the parent pom.

  4. Proposed Solution • Each project should follow semantic versioning • If for some reason bundle version needs to be different than the project parent version, it can be overridden but specify the version of the bundle as a property in the project parent pom. • With this approach all the properties will be defined only in one pom and will be very easy to inspect if something were to go wrong. • 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

  5. Few examples after restructuring This is how properties section looks like in the project level parent. • <properties> • <openflowjava.version>0.5-SNAPSHOT</openflowjava.version> • <controller.model.version>1.1-SNAPSHOT</controller.model.version> • <sal.api.version>0.8.1-SNAPSHOT</sal.api.version> • <sal.connection.api.version>0.1.2-SNAPSHOT</sal.connection.api.version> • <netconf.connector.version>0.2.5-SNAPSHOT</netconf.connector.version> • <config.manager.version>0.2.5-SNAPSHOT</config.manager.version> • <xtend.version>2.4.3</xtend.version> • <bundle.plugin.version>2.4.0</bundle.plugin.version> • <maven.clean.plugin.version>2.5</maven.clean.plugin.version> • <yang.tools.version>[0.6.0,)</yang.tools.version> • <yang.prototype.version>1.0</yang.prototype.version> • </properties> As shown above, range has been specified for yang.tools.version, which will use the version equal or greater than 0.6.0. Or we can always specify “LATEST” that way during development, we are current always. During the release, it can be changed to a particular release version.

  6. Few examples after restructuring Project level parent inheriting super parent and overriding the version: <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <parent> <groupId>org.opendaylight.odl</groupId> <artifactId>odl-root-parent</artifactId> <version>1.4.3-SNAPSHOT</version> </parent> <modelVersion>4.0.0</modelVersion> <artifactId>yangtools-parent</artifactId> <groupId>org.opendaylight.yangtools</groupId> <version>0.6.2-SNAPSHOT</version> <packaging>pom</packaging>

  7. Few examples after restructuring Project level parent inheriting super parent and inheriting the version from the parent: <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <!--prerequisites> <maven>3.0</maven> </prerequisites>--> <parent> <groupId>org.opendaylight.odl</groupId> <artifactId>odl-root-parent</artifactId> <version>1.4.2-SNAPSHOT</version> </parent> <groupId>org.opendaylight.openflowplugin</groupId> <artifactId>openflowplugin-parent</artifactId> <packaging>pom</packaging>

  8. Using Versions & Release Plugin If we have a pom file specified something like this: <properties> <dependency1.version>1.0-SNAPSHOT</dependency1.version> <dependency2.version>1.1-SNAPSHOT</dependency2.version> </properties> and all modules use that like this: <dependency> <groupId>group</groupId> <artifactId>dependency1</artifactId> <version>${dependency1.version}</version> </dependency> From Jenkins execute • “mvn versions:update-properties” • “mvn release:prepare release:perform –B”

  9. 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