www.opendaylight.org opendaylight – “autorelease” tool and process jun 2014 giovanni meo...

www.opendaylight.org

OpenDayLight – “autorelease” tool and process

Jun 2014

Giovanni Meo ([email protected])

1


It’s a process that tries to streamline the release process we have for ODL

A Tool that implement the streamlined process

What’s “autorelease” in a nutshell?

2


[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 dependencyWhen 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.

Why we need a better release process?

3


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.

Why we need a better release process? [2]

4


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

Analysis of the release process issues

5


Maven release-plugin has two phases:

1. release:prepare

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

release-plugin issues

6


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

release-plugin issues mitigation

7


release-plugin solutions and version model for a given bundle

8

master

hydrogen

helium

uranium

0.4.0

0.4.0

0.4.1 0.5.0 1.0.0

1.0.0

Versioning based on semantic versioningOr in general based on component rules

On stable branches, just use the same numbering of the Master when was cloned, these branches are supposed to be for stability

On stable branches, just use the same numbering of the Master when was cloned, these branches are supposed to be for stability

0.4.0-v20140530102009_8eb0607 0.5.0-v20140606122009_fe56690

Version on major branches

Version on weekly releasesOr on stable

1.0.0-v20150106122009_7ee66a8


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

Versions-maven-plugin issues/resolution

9


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

How auto-release impacts projects?

10


Thank you!

11

www.opendaylight.org opendaylight – “autorelease” tool and process jun 2014 giovanni meo...

Documents