Release Manager

Overview

The release manager ensures the smooth operation of our standard, monthly release process. Releasing monthly keeps pressure on our deployment team low, as well as manages the cost involved with deploying to the large number of financial institutions we support. This role requires short but critical periods of active time, with longer periods of passive time.

Cadence

With the current size of the team, release manager only comes around once per year for each team member. Typical release cycles will see the release manager role lasting around a week, though it can extend to two if release blockers are found during testing. Release manager is currently a role that is done on a volunteer basis. We track the release manager schedule in Figma.

Responsibilities

Below are the responsibilities for this role. Please see the dedicated sections for each for more detail about everything involved.

Code Freeze

Code freeze is the act of creating the branch we will base the release off of. We have general expectations around the day we expect code freeze to happen, which can be found on the mobile team board in Figma. This date can be pushed if it’s determined we need more time in order to get a feature or critical bug fix into a release.

A good rule of thumb is to try to have code freeze in effect by 5pm Central, however this time can be flexible. The only real requirement to instituting the code freeze is that all outstanding PRs needing to be included in the release are merged. To ensure this happens, post a message directed @ios in #team-ios on the day of code freeze asking which PRs need to be merged before code freeze. Once all PRs in the thread have been merged, you are free to create the release branch.

Once the release branch has been created, you should:

• Post a message indicating code freeze is in effect in #team-ios. Please also remind the team that any PRs needing to be included will need their base branch updated to point at the release branch.
• Remind the team the next iCow meeting will be used to discuss and demonstrate work done that is included in the release.
• Generate TestFlight builds for release testing.
• Post a message to #org-mobile-release-testing indicating TestFlight builds are available, and provide a link to the release epic.

Release Testing

The Product team signs off on a given release after they are satisfied with their findings during testing. This may result in additional PRs to address critical issues. There is no set timeframe on when approval will happen. During the testing phase, you should periodically ask for feedback on the release in #org-mobile-release-testing.

Along with the previous channel, you should keep an eye on anything posted to #org-mobile-release-testing, and monitor the release epic for new issues. It is not your responsibility to personally address each issue that is brought up during testing. You should be facilitating resolution by finding the most appropriate person to work on an issue.

Finalization

Finalizing the release depends on three events:

1. Every ticket in the release epic should be complete or in testing.
2. A message is posted in #team-banno-release-notes indicating we have approval of the customer release notes.
3. A message is posted in #org-mobile-release-testing indicating we have product approval for the release.

Once the above criteria are met, you should immediately begin following the process outlined in Making Banno Mobile App Releases. If you have any questions about whether the criteria have been met or not, please contact your Engineering Manager, or the Director of Mobile Engineering.

The last step is to close the Jira epic for the release. If there are any issues that were not finished as part of the release, those will need to be moved to the next release epic. Ideally, this will not happen, and if there is any uncertainty about what to do, ask in the #team-ios Slack channel.