Full PRO release
| 3-4 weeks before the Release
|| Write Release announcement Email (see template), including information on when the Release branches should be there and how to create them.
| 3-5 days before the Release
|| Create Wiki page with Release Order graph, see below
| 1-2 days before Release
|| Write a reminder Email, that all branches must be there, which day which time
| 0 + x
| 0 + xx
|| After Rollout is performed, LSA and BSS are up and running and Modellers have imported the Physics Model, write the Release Email (see template)
Before the Release
Create Wiki Page with Release Graph
On our Releasepage
, create a new Subpage for the upcoming Release.
For creating the release graph, we first checkout the master branches of all involved projects.
To do so, we first edit the checkout reactor accordingly and check if the list of projects needs to be adapted.
gedit /common/usr/lsa/bin/mkws/checkout.reactor.jutta2 &
Then we perform the checkout of the master branche of those projects:
/common/usr/lsa/bin/mkws/checkout.reactor.jutta --ssh --flat -b master -p ~/dev/ws_release_202010/repos/git/
Once all projects are checked out, the graph can be created using:
The graphs will reside in the target folder of the reactor.
Copy the contents of the ReleaseOrderGraph
.dot to the Release Wiki page. It is not yet a working graph, but some tags must be placed before it:
<span class='WYSIWYG_COLOR' style='background-color: #ffff00; color: yellow;'>______</span> = release branch is already created
<span class='WYSIWYG_COLOR' style='background-color: lightgreen; color: lightgreen;'>______</span> = project is released
<span class='WYSIWYG_COLOR' style='background-color: lightgrey; color: lightgrey;'>______</span> = project is obsolete
<graphviz type="svg" style="width:100%;height:auto" inline="true">
If the Wikipage just shows errors, please check for Umlaute / special characters in Release Engineer names. Also check that you copied the above section correctly and placed it before the graph contents.
Performing the Release
Checkout all projects
Clone all projects using the R16 Release branch:
/common/usr/lsa/bin/mkws/checkout.reactor.jutta --ssh --flat -b R16 -p ~/dev/ws_release_202010/repos/git/
You can perform the script many times, it skips already cloned repositories and prints those, that are still missing.
Create missing Release Branches yourself (optional)
If you need to create the Release branch for a project yourself, you can do so by using the normal branching command.
However if you just "switch" to the newly created branch in Eclipse, the remote connection for the Repo will most probably still be missing.
To check, if this is the case, call
To fix this issue, call
Beim Release kommt die Meldung, dass der R16 branch kein remote hat..
git branch --set-upstream-to=origin/R16
JF: test if this problem still occurs, if you perform "pull" on the project once (Maven does a local rollback after pushing the branch)
Release of parents
As the release process for the parents look slightly different, there is an extra Wikipage
for this procedure.
Note that this can also bei done in advance, i.e. even if not all projects have been branched yet.
Release of all other projects
With the reactor, many or even all projects can be released at once. However it can also be beneficial to comment out a bunch of projects, and e.g. release first lower level common-library Projects, than LSA, then applications. This can be achieved by commenting out modules in the reactor pom. To tell Git, that it should ignore changes in this pom during the release process, call
[jfitzek@asl742 cscoap-reactor]$ git update-index --assume-unchanged pom.xml
During the release, you should comment out successful released projects in the reactor pom. If the release fails at some point and you need to restart, they would otherwise fail, since the reactor would try again to release those.
Check the pom.xml for each project
It is necessary to check each pom.xml file before the release.
Follwing pitfalls exist and must be corrected before the release:
- please make sure, that developers and roles are still correct, remove any Umlaute here !!!! e.g. Müller -> Mueller as otherwise the Release Order Graph will not be working
- cleanup dependencies:
- remove direct dependencies that anyway come through others, might be a leftover from a quick bugfix
- remove dependencies, that are commented out, especially those with -SNAPSHOT in the name as they cause problems in the release process
- check that there are no fixed older pro-versions defined, e.g. pointing to 15.0.0 (as only -SNAPSHOTS will be increased to the latest pro release version number). Those should point to the lastest master SNAPSHOT version instead.
In Email die Release preparation steps verlinken, dieses hier eher löschen.(?)
~/dev/ws_rb/repos/git/scripts/mvn/mvn_reactor_release -rv 16.0.0 -dv 16.0.1-SNAPSHOT
Problems during the Release and Recovery
Release cannot be done, "R16 branch has no remote"
If you created the Release branch of a specific project within your release workspace, and just switched to the Release branch in Eclipse, the remote connection to the R16 remote branch is still missing.
To fix this issue, call
git branch --set-upstream-to=origin/R16
Release cannot be performed at all e.g. due to missing dependencies or Javadoc errors
No recovery needed. Just start the release all over again
Release successful, Tag screwed up
While the release seems successful, the file does not exist in Jenkins (typically fails in upstream projects) and the corresponding pom.xml file of the created tag is screwed up, i.e. it contains SNAPSHOT versions. (Cause of this error is currently not known). In this case we need to manually delete the tag, reset in Git history to the point before the release and run the complete release process again.
[jfitzek@asl742 cscoap-common-units-ui]$ git tag -d cscoap-common-units-ui-16.0.0
[jfitzek@asl742 cscoap-common-units-ui]$ git push origin :refs/tags/cscoap-common-units-ui-16.0.0
[jfitzek@asl742 cscoap-common-units-ui]$ git hist -n 5
[jfitzek@asl742 cscoap-common-units-ui]$ git reset --hard deb64b1 (use the commit Id before the release started)
HEAD is now at deb64b1 JF: pom cleanup before release
[jfitzek@asl742 cscoap-common-units-ui]$ git push -f
Release successful, Tag looks correct, no file in Nexus
While the release seems successful, the file does not exist in Nexus (typically fails in upstream projects). (Cause of this error is currently not known).
In this case, we can checkout the tag and just perform mvn deploy to upload it to jenkins:
[jfitzek@asl742 parammodi-app]$ git reset --hard parammodi-app-16.0.0
[jfitzek@asl742 parammodi-app]$ mvn deploy
Release successful, Tag correct, file in Nexus, but site deploy failed
If only the site deploy failed, you can easily repeat it by using
[jfitzek@asl742 bss-patterngroup-config]$ git reset --hard bss-patterngroup-config-16.0.0
[jfitzek@asl742 bss-patterngroup-config]$ mvn site-deploy -Prelease
However if the site deploy failed due to a lack of permissions, than check if you have done the step to rename the old site directory for the old version? If not, please do so now !!! and repeat any site deploys for downstream projects..
Release-Voraussetzungen: altes Site Verzeichnis verschieben
After the Release
Checkin any changes to cscoap-reactor/pom.xml. If you removed the pom.xml temporarily from Git change tracking, than remember to add it first again:
[jfitzek@asl742 cscoap-reactor]$ git update-index --no-assume-unchanged pom.xml
do g+rw for site deploy (so that others can override the site files when re-deploying)
(maven.site.skip evtl. im Release unterstützen) / oder Doku Ordner o+rw setzen ?
wenn von INT gebrancht, sollte das Releasescript auch RC-INT ersetzen können zusätzlich
- 19 Nov 2020</verbatim>