Release Planning

Universal Release Basics

Regardless of the application to be released is a mobile application or a web application, there are a few universal basics that must be done in order to ensure a smooth release:

• Coordinate and confirm the release schedule with the client and engineering teams.
• Never release on a Friday unless the client makes a special request.
• If a client happens to request that the team releases on a Friday - the Product Manager must communicate in writing to the client that Nimble will not provide any support over the weekend.
• Perform Quality Assurance — it is of the utmost importance that the Product Manager continuously performs QA not only during the development lifecycle but also before any release. This is to ensure that no glaring issues make it into a production release. At the bare minimum test the happy path.
• Once the Product Manager has approved the version to be released they must coordinate with the client so that the client can perform their own QA. If the client gives their approval, the Product Manager needs to capture it via email.
• Once the client has approved the release version the Product Manager can give the engineering team the green light to deploy.
• Create release notes.
• Perform post-release QA. Perform a sanity check on the newly updated web application. If during this phase any issues are discovered, the Product Manager must inform the client and then make a decision as to whether they will revert the deployment or not.
• If all is well, inform the client the release was successful and send the release notes.

Release Types and Cadence

Several different types of releases occur during the lifecycle of a project. It is essential to understand every kind of release and when to use them. It is equally vital for the client to understand the release process. Here are the three types of releases performed at Nimble:

• Sprint Release - Sprint releases summarize the work delivered during the sprint period. After a sprint ends on a Friday, the following Monday, release builds are created and submitted to TestFlight and Google Play Beta track. Although they are not publicly available in either Apple App Store or Google Play, the team can invite people to get a sneak peek to give early product feedback. This process is repeated at the end of each sprint until the application has been deemed ready for Public Release. An application might have many sprint releases before reaching a state of readiness for when it can be released publicly.

• Public Release - When an application is released publicly, all subsequent updates and releases will now be considered Public Releases opposed to Sprint Releases. The client typically schedules the cadence of a Public Release following a period of QA and review. However, at Nimble, the team strongly recommends releasing early and often after the end of a sprint.

• Patch Release - This is a rarely used release that is done in order to address an urgent issue discovered following a Public Release.

The team uses Semantic Versioning with all releases. For example, if the team was to do a Patch Release after publicly releasing version 1.0.0. The Patch Release would be formatted as such: 1.0.1. While on the other hand, if they were doing a major Public Release, the format would be 2.0.0.

Releasing Mobile Applications

The process of releasing a mobile application requires the Product Manager to upload the release build, interface with app reviewers, and perform the release. Mobile applications are more about preparing the release for the review process and ensuring that they have all the necessary material lined up and coordinated so that the build passes its review.

Planning With the Client

After a project has been kicked off, it is essential to establish which party will be responsible for mobile releases. To facilitate a smooth release, the team must establish the following with the client:

• Identify ownership and responsibility
  • Who will be responsible for releases, and whether it will be a cooperative effort?
  • Who will be responsible for generating screenshots and marketing materials?
  • Who will be authoring release notes and other content, such as the “About” section?
  • Who will be responsible for managing and uploading in-app purchases?
  • Who will submit builds to each platform for review?
  • Who will interface with Apple or Google in the event of a rejection?
• Letting the client know that Apple’s Review Process can take upwards of 7 days. For most apps, it is 24 hours. The review of a brand new app often takes a bit longer.

Alternatively, it is completely acceptable if the client wants Nimble to handle all aspects of the release process.

Identifying Potential Blockers

It is not uncommon for Apple or Google to reject a submission based on a specific feature that violates their rules. When working with a client on a potential feature, the team must identify any requirement that could lead to rejection. If uncertain, double-checking Apple’s App Store review guidelines and/or Google’s Developer Content Policy will clear up any doubt.

If the client proposes a feature that might result in a rejected submission, the best way to proceed is to warn them and offer an alternate solution. If an alternate solution cannot be reached, it might be worth revisiting the initial requirements with the client. However, If the client cannot change their requirements, the team will “warn and commit”, which means giving the client a written warning that what they are proposing could delay their app from being released while committing to work on what they suggested.

Submission Checklist

Although a 100% guarantee cannot be provided that a build will not be rejected by Apple or Google, there are a few things that Product Managers can do on their side to ensure that the likelihood of rejection is lower. Therefore, it is the responsibility of the Product Manager to ensure that the submission has met all the prerequisites and the proper review material has been provided. Failing to do so will increase the risk of delays.

• Double check to ensure that all required marketing materials are supported in all languages.
  • The “About” section
  • Release notes or “What’s new”
  • App information
  • Screenshots
    • Be sure to check with Apple and Google frequently, as their screenshot specifications change often.
• Provide working sign-in credentials. If login requires an OTP, then a working email must be provided.
• If there are any IP restrictions, whitelist the US (Apple reviewers are located in the US).
• Provide video and screenshots for the demo.
• Double-check if the API is production-ready.
• Do a regression test on the build submitted.
• Double-check app permissions. In-app requests to access user data such as Location, Calendar, Contacts, Microphone, and Photo permissions are very common. However, if a permission is prompted it must be tied to a feature — Apple is notorious for rejecting applications that have unnecessary permission prompts. There are a few preventative measures that both Product and Engineering can take:
  • With Android, Engineering teams can do two things: perform a reverse read of the manifest or use Use APKanalyzer to get a list of the current permissions.
  • For iOS and Android builds, the Product Manager can check the application manually by going to phone settings > application > permissions

Releasing the Build

Once the application has been approved, it is up to the Product Manager to commence with the release.

• Double-check the production API for readiness.
• Coordinate and communicate with the client if there is a specific time they want to release.

Staged Rollouts & Rolling Back a Release

On both App Store Connect and Google Play Console there exists an option to do a phased rollout. With a phased rollout, the update reaches only a percentage of users, which will increase over time. Some of the advantages of doing a phased rollout are:

• Gauge how customers react to an update and respond accordingly.
• Target specific countries.
• If something unexpected occurs, the release can be halted, only impacting a percentage of app users.

When the Product Manager elects to use a Phased Rollout for iOS, App Store Connect predetermines the percentage of users who will receive the app based on the following chart:

With Google Play Console, the person releasing the app can manually select the percentage they want rolled out.

In the event an app is published with a catastrophic flaw, it is possible to roll back to a previous version. Unfortunately, this is not a built-in feature on App Store Connect or Google Play Console, however, it is quite straight forward to fix on both platforms.

• Halt rollout of the current version (only if it is a phased rollout).
• Grab the same build of the previously released version and assign it a version number higher than the current release.
• If Force Upgrade is available, execute it so that users can upgrade to the bug free version.

Before committing to rolling back to a previous version, please assess the impact of the issue and weigh the consequences of not releasing new features in order to accomodate a bug. Maybe the problem can be mitigated with a simple hotfix. Regardless of the decision, the Product Manager needs to assess the situation and present the client with options. Please note that on both platforms, the new version will have to go through the same release process all over again.

Post-Release

• Be cognizant of the propagation period (let the client know that full propagation takes a few hours for each platform).
• If an app has a force upgrade feature, do not initiate it until propogation has fully completed.
• Download the app and do a regression test. The last thing any Product Manager wants is for the client discover a bug before they do. Nor do they want users reporting an issue that impacts user experience. Bugs and crashes are sometimes unavoidable and part of the product lifecycle; however, the Product Manager must strive to reduce them as much as possible and to catch them early when they happen.

Platform-Specific Behavior

Both Apple and Google have their own specific nuances that are platform-specific. These actions may not be relevant to all releases, but they are good to know.

• App Store Connect allows Release Managers to alter marketing content and screenshots after they have submitted for review and only if Apple has not yet started the review process.
• Although Apple’s review process can be lengthy compared to that of Android, Apple does offer an expedited review in the event of a crisis. When requesting an expedited review, it is required to list the reason and give a thorough explanation. Use this feature sparingly and only in an emergency or when the business has a pressing need. Apple may reject the request if asked too frequently.

Releasing Web Applications

Unlike mobile applications, a web application does not need to submit to rigorous review processes, rather, it can be deployed at any time by the engineering team. Because of this, the Product Manager’s involvement is more concerned with ensuring that the web application to be released has been properly tested and is ready for production. Additionally, the Product Manager needs to plan and coordinate releases with the Engineering team and the client.

API Releases

Releasing an API needs to be carefully planned to ensure that there are no disturbances to the web and mobile applications’ user experience that are supported by the API. A few things to keep in mind to ensure a smooth release:

• Planning for future features — as a rule of thumb, the API should be releasing support for new features ahead of the web and mobile applications, this is to ensure that there are no blockers during web and mobile application feature implementation. Keeping this schedule is important to stay on track.
• When releasing an API that contains updates to existing features on a web or mobile application, it is important to coordinate with the web and mobile engineering teams to ensure that current features are not impacted. For example, suppose the API team updated the URL for a specific endpoint — Product Managers would not want to release this to production without first planning and coordinating with the other engineering teams so that they can accommodate for the new path URL.
• If the API has breaking changes that will cause older devices or web browsers to be incompatible, it is a good practice to use API Versioning to ensure that any changes will not cause issues for frontend platforms in production.
• It is also generally a good idea to push API changes to production first before updating frontend platforms. This is so that if a frontend platform relies on a new API once it has been updated, the API is already available.
• After the API has been released, the Product Manager needs to double-check all production applications for any issues that might be a result of the new API release.