Release Manager Job Description

The release manager is responsible for facilitating the successful execution of the Simultaneous Release Plan and coordinating with participating projects to deliver the Simultaneous Release Artifacts to the Technical Steering Committee for review and approval. 
The release manager participates in the following:
 - Track cross-project activities and action items including Weather, Autorelease, Integration, Test, Documentation, etc.
 - Follow up and verify completion of per project requirements according to the Simultaneous Release Schedule for Milestones, RC, SR dates.
 - Communicate community-wide release related topics including schedule, requirements, blockers, etc.
 - Run release sync meetings and inform relevant parties of issues, red flags, potential breakages.

[WIP] Release Manager's Workflow & Expectations

Monitor that ODL autorelease (AR) build is working, looking at the build history and notify the PTL's on Autorelease failures. The release manager does not need to debug issues on the infra and project issues. 
The Release Manager needs to triage the issue and follow up PTLs and the community to get the issue resolved. Given that we have multiple streams and ongoing releases it would be good to keep track of the build
before an upcoming release to ensure that AR builds are passing.

Identify the RC (release candidate) - This is where we start looking at the blocking issues and then we get a go/no-go from all the projects.

Once we have a RC, the process requires sending an email to the release mailing list asking the project team to verify the failed tests and update the tracking spreadsheet on the release readiness. 
For each major release, we have a separate spreadsheet CSIT results and separate tabs for each release

At one point we decide that one build will be the RC0 which represents the rehearsal to get all the projects into a single distribution. After the code freeze, we have time to stable

  • RC1 is where we want to lock the branch
  • RC2 is when we start the go/no-go process  

Things we need to track as the release manager:

  • Blocking bugs - JIRA severity
  • Weather items - breaks in the ODL which are scheduled and should be handled.
  • Tracking the check points - only 3 checkpoints which are init, mid and final. 
  • Auto release builds - for all the builds we are working on

Update the tracking spreadsheets with the CSIT test results and notifify the build status.

Update the release page with New releases and check points: https://wiki.opendaylight.org/view/Release_Dashboard

  • No labels

4 Comments

  1. Daniel De La Rosa

    Hello Anil Belurand Casey Cain


    This looks great and pretty much according to what i've been trying to accomplish with the help of our team.. couple of comments though:


    1. "notify the PTL's on Autorelease failures" This is done automatically right? 
    2. "The release manager does not need to debug issues on the infra and project issues. 
      The Release Manager needs to triage the issue and follow up PTLs and the community to get the issue resolved"       So i need to triage but not debug project issues? I think i can do some initial log analysis but not full troubleshooting 
    3. Also i think we have been using only one RC, so it seems that RC0, RC1 and RC2 are not needed anymore...
    4. Release dashboard doesnt exist anymore.. and my understanding is that we are not going to use it.. 


    I'm assuming that i can just edit this page so it reflects what is being done today right? 


    Let me add Jamo Luhrsenand Thanh Ha (zxiiro)for any additional comments.. 






    1. Thanh Ha (zxiiro)

      Sounds about right.

      Autorelease failures are automatically reported to the release mailing list and the project specific dev mailing list so the release manager's job is to make sure autorelease failures are being handled by someone if there isn't expedient updates.

      I wouldn't expect the release manager to do the actual troubleshooting apart from making sure it's a real issue and not just some intermittent thing (like maybe the infra didn't work so build didn't actually go through).


  2. Jamo Luhrsen

    I agree with Thanh Ha (zxiiro) that the release manager does not need to debug autorelease failures, just make sure the projects are actually fixing them
    when they occur. A lot of the time, the failures are sporadic and do not happen and get ignored. There's never been a good way to figure those out
    and they just get ignored. That's just an FYI, I guess.

    I would remove all the wording around "Simultaneous Release". That's old and not the process we use anymore. Now it's the "Managed Release"
    and "Self Managed Release" concepts.

    yep, remove the RC0, RC1 stuff. We usually just take the most recent passed AR build and run with it.

    The checkpoint bullet is not correct. it's not initial, mid and final. the list is here: https://docs.opendaylight.org/en/latest/release-process/release-schedule.html

  3. Daniel De La Rosa

    Abhijit Kumbhare and Casey Cain  this document has everything that we need for release management. I'll work on some edits but it will be good if someone can be nominated from each of the companies in ODL