OpenDayLight – “autorelease” tool and process

1. OpenDayLight – “autorelease” tool and process Jun 2014 Giovanni Meo (gmeo@cisco.com)

2. What’s “autorelease” in a nutshell? • It’s a process that tries to streamline the release process we have for ODL • A Tool that implement the streamlined process

3. Why we need a better release process? [Note] Well this is only for the record, for who has not been releasing Hydrogen, else this slide is superfluous  • ODL is comprised of several projects, which creates bundles to be used by other projects in ODL itself as well outside. • A given project FOO consumes artifacts from another project BAZ, hence this create a project dependency • When releasing FOO, you cannot do it so till the BAZ project has created released artifacts. • This project relation is done manually via a set of jenkins job for each project. Owner of project FOO would kickstarted the release project only after BAZ was released.

4. Why we need a better release process? [2] • FOO project needs to update manually or via versions-maven-plugin to released version of the artifacts and kick in the release process for FOO. • Overall the issues can be summarized as: • Too much manual processing • Requires all the projects stakeholder to be online during the release because of privileges permissions • Repetitive and error prone and tiring too. • Imagine repeating this for sealing artifacts weekly.

5. Analysis of the release process issues • Two categories of issues: • Maven release process out of the box is complex and require access to external GIT and maven repo • versions-maven-plugin didn’t perform reliably version changes

6. release-plugin issues • Maven release-plugin has two phases: • release:prepare • release:perform • First phase change the artifacts from –SNAPSHOT to released version, and perform a commit, then change from released version to the next –SNAPSHOT version and perfom a second commit. Then push to central repo the tag for the released version • Second phase expects the tag in first phase to be visible in the repository • This push of commits and tags, requires the process to be done by a jenkins job with appropriate privileges

7. release-plugin issues mitigation • [Solution1] Restrict release-plugin to only perform the –SNAPSHOT -> RELEASE -> -SNAPSHOT+1 changes, leave it out the deployment of the tags and the artifacts. • [Next problem] If we let release-plugin to change version without any caution, we would have version clashes in different runs. • [Solution 2] Make sure the versions generated are marked so to be unique, by adding a build identifier formatted as: major.[minor.[micro]]-v{year}{month}{day}{hour}{min}{sec}_{git short SHA} • NOTE: solution 2 is to be used only for weekly releases, for major releases we still need to create versions without the timestamping, but the clash will not happen because among major release will make sure to bump the next dev version.

8. release-plugin solutions and version model for a given bundle Versioning based on semantic versioning Or in general based on component rules master 1.0.0 0.5.0 0.4.1 1.0.0 0.4.0 0.4.0 Version on major branches 0.5.0-v20140606122009_fe56690 0.4.0-v20140530102009_8eb0607 On stable branches, just use the same numbering of the Master when was cloned, these branches are supposed to be for stability Version on weekly releases Or on stable hydrogen On stable branches, just use the same numbering of the Master when was cloned, these branches are supposed to be for stability helium 1.0.0-v20150106122009_7ee66a8 uranium

9. Versions-maven-plugin issues/resolution • Couldn’t replace versions specified with a variable • Was not changing versions of the parent pom • Was not changing versions of pluginManagement and dependencies to plugin in that section • Was searching for newer artifacts in all the released repositories, but to control in case of multiple branches is necessary to have a filtering mechanism on the repo

10. How auto-release impacts projects? • “autorelease” requires little work from project owners (mostly bugfixes), once at regime, the different projects would see a gerrit patch that would try to change the inter-project dependencies from –SNAPSHOT to the weekly released versions. Project owners can decide to ignore or can merge it or can rework such that some dependencies are left to be –SNAPSHOT some other releases. • The gist is that each project knows how often its dependencies shall change or no, so it’s up to the project owner to make that call. • From a stability point of view will be better to remove –SNAPSHOT across projects. But this is a recommendation.

11. Thank you!