www.opendaylight.org opendaylight – “autorelease” tool and process jun 2014 giovanni meo...
Post on 30-Dec-2015
213 Views
Preview:
TRANSCRIPT
www.opendaylight.org
OpenDayLight – “autorelease” tool and process
Jun 2014
Giovanni Meo (gmeo@cisco.com)
1
www.opendaylight.org
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
www.opendaylight.org
[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
www.opendaylight.org
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
www.opendaylight.org
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
www.opendaylight.org
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
www.opendaylight.org
[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
www.opendaylight.org
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
www.opendaylight.org
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
www.opendaylight.org
“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
www.opendaylight.org
Thank you!
11
top related