Full PRO release

Time schedule

When? What?
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 Release
0 + x Rollout
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 &

</verbatim>

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/

</verbatim>

Once all projects are checked out, the graph can be created using:

cd ~/dev/ws_release_202010/repos/git/cscoap-reactor
./allGraphs

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">

alert 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

TODO 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

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

For 1..n projects, perform the release (comment out others in the reactor pom if needed)

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.

TODO In Email die Release preparation steps verlinken, dieses hier eher löschen.(?)

Release
~/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

alert 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

alert 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

alert 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

alert 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

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

TODO 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

General TODOs

TODO do g+rw for site deploy (so that others can override the site files when re-deploying)

TODO (maven.site.skip evtl. im Release unterstützen) / oder Doku Ordner o+rw setzen ?

TODO wenn von INT gebrancht, sollte das Releasescript auch RC-INT ersetzen können zusätzlich

-- JuttaFitzek - 19 Nov 2020</verbatim>
Topic revision: r3 - 03 Dec 2020, JuttaFitzek
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback