Skip to content

Latest commit

 

History

History
290 lines (219 loc) · 31.7 KB

ReleaseProcess.md

File metadata and controls

290 lines (219 loc) · 31.7 KB

Release process

Release engineer as a role

The release engineer responsibilities are, but not limited to:

  1. Own the entire release process (step-by-step).
  2. Provide visibility of the release, at all stages, to the wider audience (e.g. squad, tribe and iOS chapter lead) by:
    1. Tagging in the release Slack channel, anyone (Engineers, PMs, QAs) that is relevant to the release and to the issues that are raised during the release cycle.
    2. Adding in the release channel a daily note with the status of the release (QA and bug fixing progress).
  3. Collaborate with QA by:
    1. Providing visibility to potential blockers to the wider audience.
    2. Escalating abnormal influx of bugs, so the release, as a whole, can be reassessed.
  4. Making sure they can dedicate enough time for the release. In case this is not possible (due to other squad commitments), please inform the iOS chapter lead.
  5. General bug fixing for minor regressions and tasks, that are not related to significant changes made by squads for their own features. For more complex ones:
    1. Delegate the bug to the relevant squad/person.
    2. If the bug is too complex to be fixed within the release window, please toggle off the feature and inform the Product Manager.
  6. Bugs that aren't owned by any squad should be fixed by the release engineers. The support engineer(s) can help if additional help is needed.

The objective is to ship the release build as soon as possible whilst maintaining the quality bar and addressing every bug raised by QA.

When dealing with a particularly complicated bug (one that would require a rather significant effort to address) the release engineer should speak with Release Manager.
The bug's corresponding feature should be disabled altogether using its feature switch (if applicable). Such a bug would subsequently be handled by its respective squad.

Release duties have priority over regular squad duties. Please inform your squad of your unavailability before starting to work in the release with at least a sprint's notice. As with every other week, twenty percent of your work hours overall are to be allocated towards making the release a reality.

There are usually two release engineers working at any given time. It goes without saying that both engineers need to work together and that constant feedback is vital.

Release step-by-step

Phase 1: Pre-release considerations

  1. To help expedite the release, any required feature flag changes should be done prior to the 2am cut-off on the Friday. If these are missed, a concession can be made so that the changes will be allowed to be made during the Friday. However, this should not be a regular occurrence as it requires intervention from the assigned release engineers to create new builds.
  2. The TestRail milestone should be created before its release is cut

Phase 2: Initiation

It starts at the end of the sprint (typically when the new sprint starts on Monday)

  1. Release branch is cut automatically on last Friday of the sprint during nightly builds. It will create and push release branch, create a release Slack channel, submit a new AppCenter build, and run UI tests.

    • if, for any reason, the automatic cut didn't work, it can be triggered manually with /stevenson release_cutoff target:Babylon version:4.1.0 from #ios-build channel
    • If you're releasing another app (e.g. Telus), they typically go through the release process only after the main Babylon app has been signed off by QA.
      • You should create the new branch from either
        • the corresponding Babylon release branch that was recently already QA'd and signed off (e.g. release/babylon/4.1.0)
        • or the corresponding Babylon release tag that was already released (e.g. babylon/4.1.0) if the release branch hasn't been merged yet
      • Name your new branch using the same release/{appname}/{version} convention (e.g. release/telus/4.1.0)
      • To do this, run /stevenson release_cutoff branch:release/babylon/4.1.0 version:4.1.0 target:Telus (Note: branch parameter is for the branch or release tag)
      • (you need to specify both the branch and the version so that the script don't bump the version to 4.2.0 by default when cutting the branch)
    If for some reason you need to do this process manually instead of using the lane, you can follow these manual steps
    1. Create the release branch (e.g. release/babylon/4.1.0) from develop and publish it
    2. Create a release channel on Slack (e.g. ios_release_4_1_0)
    3. Create a PR (e.g. [CRP-XXX] Babylon Release 4.1.0), assign the release engineers, and add the WIP label
    4. Trigger the App Center build from that branch using its command (e.g. /appcenter Babylon branch:release/babylon/4.1.0) in #ios-build.
    5. Trigger the full UI automation run by issuing the command /stevenson ui_tests branch:release/babylon/4.1.0 in #ios-build.
    6. Run CRP /crp ios release/babylon/4.1.0 in #ios-launchpad, then edit the PR ticket title to update the [CRP-XXX] with the actual CRP ticket number created by this command. If the bot returns errors, you can find more info about them in the CRP Bot documentation.

  2. Join the Slack channel e.g. ios_release_4_1_0) to discuss anything related to this release.

  3. Review UI test failures and, if necessary, tag the squads responsible for the failing lanes.

  4. Bump the release version by triggering the Slack command (e.g. /testflight Babylon version:4.1.0) in #ios-build (you can run the command every time you want to upload a new build).

    • This creates a TestFlight build (try to make one as early as possible so that you can catch issues like missing/expired certificates or profiles and any other production build errors early).

  5. Create a new version in AppStoreConnect (login using your own account) / My Apps

    1. Navigate to the app you want to create a new version for
    2. On the sidebar click the + button next to the iOS App header
    3. Input the new version number.

During this stage, the release manager has the following tasks:

  1. Ensure the CRP ticket is up-to-date
    • The CRP ticket is created automatically for iOS during release cutoff (see details here)
    • But they need to ensure all tickets have had their Fix Version field updated as expected (see the CRP report)
    • They also need to manually complete the CRP ticket with some additional information (clinical risk, etc)
  2. Ask the #ios-launchpad channel for the expected release notes from each squad if they are releasing anything

Phase 3: Test and fix bugs

It starts after the App Center build has been delivered and it can take several cycles

  1. Testers will then begin their work against the build that was just created.
  2. Any hotfix should target the develop branch first, then cherry-picked to the release branch.
  3. The cherry-pick PRs need to be reviewed by the relevant squad or platform QA & one of the release engineers assigned to the release. This is to ensure visibility of the changes and the correct builds are available for validation.
    • Bear in mind that two approvals from other engineers is not enough in this particular case.
    • The issue for the hotfix has to visible on the release JIRA board. To ensure this, set the release number in the Fix version field in the hotfix's JIRA ticket.

Phase 4: Submit TestFlight builds to App Store Connect

It starts after all opened issues had been addressed and can take several cycles until QA's approval

  1. Trigger a new release build in the #ios-build channel (e.g. /testflight Babylon version:4.1.0)
  2. Obtain the release notes from the Product Manager and update them in the AppStoreConnect.
    • Babylon (UK): Be aware that the release notes have 2 localised versions: English UK (which contains references to the NHS) and another English (Australian by August/2019) for the other territories (the rest of the world). Paste the release notes on both if just one is provided in the #ios-launchpad.
    • Other apps: make sure you provide the release notes for all appropriate locales
  3. Enable the new release version in TestFlight on AppStoreConnect.
    • ❗️NOTE: Remember to submit compliance info for that build
    • If you are asked about "Export Compliance Information" check what to do here
  4. Perform a quick exploratory test on the TestFlight build to make sure everything looks okay. (e.g. verifying that DigitalTwin Assets are visible and are not dropped due to Git LFS issues)
  5. By now, QA should have been notified that there is a new version in TestFlight.

Phase 5: Submit for release in App Store Connect

It starts after QA has signed off a particular build and can take several cycles until Apple's approval

This process is now automated using the submit_for_review lane. Just trigger the lane from the #ios-build channel using /stevenson fastlane submit_for_review target:<target> build:<testflight_build>.

If for some reason you need to do this process manually instead of using the lane, you can follow these manual steps
  1. Make sure Manually release this version is selected in Version Release.
  2. Select Use phased release
  3. Select build to submit for review
  4. If you are asked about "Advertising Identifier (IDFA)" check what to do here

Phase 6: Closure

It starts after the app is accepted by Apple and final internal approval

Most of the steps for this phase have been automated using the finish_release lane.

  1. Press Release this version in App Store Connect

  2. Trigger the lane from the #ios-build channel using /stevenson fastlane finish_release target:<target>.

    If for some reason you need to do this process manually instead of using the lane, you can follow these manual steps
    1. Create a tag named {appname}/{version} (e.g. babylon/4.1.0) on the release commit and create a GitHub release for that new tag
      • Make sure you create separate tags (and GitHub releases) for each app released on the AppStore (eg. Babylon 4.1.0 and Telus 4.1.0 would each have their own babylon/4.1.0 and telus/4.1.0 tags)
      • Set the body of the GitHub release to the content of the Release Notes for the app
      • Attach the zipped xcarchive as an artefact to the GitHub release (if you're using the automated release command, you can find the *.xcarchive.zip in the Artifacts top section in the CI build).

  3. Merge release branch back to develop:

    • Open the Release PR (PR from release branch targeting develop) which has been automatically created.
    • Resolve the conflicts (if any).
    • In case there are changes other than updates to app and build versions after merging the changes from develop, the release engineer should assign as reviewers all the engineers who worked on those changes and remove the ones automatically assigned. In current workflow every change integrated to release branch is supposed to be go into develop soon after, so there shouldn't be any changes. Any differences might be a result of resolving conflicts, or a hotfix PR not being merged previously to develop.
    • Set the Merge label once all the required reviewers have approved it.

  4. Update this document if any steps during the release process have changed.

Hotfix Release

Phase 1: Initiation

The hotfix is cut from the latest stable/hotfix release tag (e.g. 4.1.1 from 4.1.0, or 4.1.2 from 4.1.1).

⚠️ NOTE: Only run the automated process if the previous release has been finished. In order to run the CRP, the GitHub Release needs to exist (and not just the git tag), otherwise it will include previous, released tickets.

  1. Trigger manually with /stevenson release_cutoff target:Babylon version:4.1.1 branch:babylon/4.1.0 from #ios-build channel

    • ⚠️ Note: branch: is using the name of the release tag, not the release branch, to ensure we cut from the point where the last release was pushed to the store and tagged.
    If for some reason you need to do this process manually instead of using the lane, you can follow these manual steps
    1. Create the hotfix release branch (e.g. release/babylon/4.1.1) from the last released tag and publish it
    2. Create a release channel on Slack (e.g. ios_release_4_1_1)
    3. Create a PR (e.g. [CRP-XXX] Babylon Release 4.1.1), assign the release engineers, and add the WIP label
    4. Trigger the App Center build from that branch using its command (e.g. /appcenter Babylon branch:release/babylon/4.1.1) in #ios-build.
    5. Trigger the full UI automation run by issuing the command /stevenson ui_tests branch:release/babylon/4.1.1 in #ios-build.
    6. Run CRP /crp ios release/babylon/4.1.1 in #ios-launchpad
      • ⚠️ NOTE: Only run the CRP after the previous release has been finished. In order to run the CRP, the GitHub release/tab need to exist, otherwise it will include unrelated tickets.

  2. Join the Slack channel (e.g. ios_release_4_1_1) to discuss anything related to this release.

  3. Bump the release version by triggering the Slack command (e.g. /testflight Babylon version:4.1.1) in #ios-build (you can run the command every time you want to upload a new build).

    • This creates a TestFlight build (try to make one as early as possible so that you can catch issues like missing/expired certificates or profiles and any other production build errors early).

  4. Create a new version in AppStoreConnect (login using your own account) / My Apps

  5. On the sidebar click + Version or Platform and select iOS.

  6. Input the new version number.

  • Note: this can be only done after the previous release has been completed

During this stage, the release manager has the following tasks:

  1. Ensure the CRP ticket is up-to-date
    • The CRP ticket is created automatically for iOS during release cutoff (see details here)
    • But they need to ensure all tickets have had their Fix Version field updated as expected (see the CRP report)
    • They also need to manually complete the CRP ticket with some additional information (clinical risk, etc)
  2. Ask the #ios-launchpad channel for the expected release notes from each squad if they are releasing anything.

The rest of the phases are the same as in the regular release.

SDK Release

At the moment SDK release is handled by the SDK squad itself. As a release engineer you don't have to worry about this section.

  1. Cut a release branch for the SDK from the app release branch, using the release/sdk/{version} naming convention (eg. release/sdk/0.5.0)
  2. The Release Manager should then create a CRP ticket by triggering its command (eg. /crp ios branch:release/sdk/0.5.0) in Slack
  3. By now, our bot created PR with the name SDK x.x.x [ci skip]- assign yourself there and update the SDK changelog SDK/CHANGELOG.md to add the release version and date on the branch mentioned in this PR.
    • this document will be distributed alongside the SDK and used to document changes to SDK consumers, so the list of changes here could be worded differently from the CHANGELOG used in the CRP ticket if necessary
  4. Trigger the App Center build from that branch using its command (eg. /fastlane distribute_sdk version:0.5.0 branch:release/sdk/0.5.0) in #ios-build.
  5. Update the Sample app to point to the latest SDK release and ensure it still compiles

US release process

For the most part, the US and Ascension flavors follow the same release process as the UK.

Branching

US release cycles are aligned with the UK's, and we currently work off of the UK release branches. However, the version numbers do not align across apps. For example, UK 4.15.0 corresponded with US 2.2.0. But we do follow the same pattern, incrementing the minor version with each new release unless instructed otherwise. Release builds generated in the #ios-build channel must specify the branch and the version number.

Examples:

  • /testflight BabylonUS branch:release/babylon/4.15.0 version:2.2.0
  • /appcenter Ascension branch:release/babylon/4.15.0 version:1.5.0

QA Distribution

  • Generate a TestFlight build
  • After the TestFlight build has processed (typically takes 1-3 hours), distribute it to the QA test group.
    • Note: The first TestFlight build with a new version number will need to be approved by Apple, which can take a day or two. That's why it's ideal to submit on Friday. The builds will typically be approved by Monday. After that, any new build with the same version number should be approved automatically.
  • Generate an App Center build

Update tickets in the release board.

App Store Submission

In the developer portal, create a new iOS version and update marketing content based on tickets in the release board. Monitor the current US and/or Ascension release channel for QA signoff (these channels are kept private). Once QA has signed off, submit to the App Store using the TestFlight build that was approved by QA.

App Store Rejections

If the app is rejected for not meeting the App Store guidelines, we have internal documentation available that contains responses to certain guideline failures. This should be updated everytime an app fails one of the guidelines. If an app has previously been rejected, then you should be able to re-use the previous message (It's worth checking with the release manager that the response does answer Apples questions though). Link to the document here

Closure

Tag the commit that the release build was generated from (e.g. babylonus/2.2.0, ascension/1.5.0). The release commit may not be the latest commit on the release branch because the UK is working off the same branch, fixing bugs (and mostly UI tests).

Release calendar

Note: Starting 4.18.0, we are no longer keeping track of the release effort in this App Release calendar section.

History of tracked effort for versions up to 4.17.0

App Release calendar

The release process starts when the first build is provided to QA and ends when Apple has approved the app. Effort to release should be broken down by:

  1. Automated QA effort (e.g. 5h)
  2. Manual QA effort (e.g. 3h)
  3. Delta between the jira ticket being open and marked as done or wont fix, for Engineering effort. (e.g. UA-8289: 1h30). Consider only tickets that were raised during the release period, checking that their creation dates were after the release branch cut.
    • We have agreed to stop collecting time spent on tickets from engineers, so there is no need to record it.
  4. Total effort
Version Release Engineer(s) QA effort Engineering effort Total effort Cut-off date Release date
4.17.0 Julien Ducret, Yuri Karabatov Manual: 24h 30m N/A Total 24h 30m 14.02.2020 26.02.2020
4.16.0 Joao Pereira, Witold Skibniewski Manual: 23h 30m CNSMR-3413: 2h
REFER-138: 2h
CE-1139: 30m
CNSMR-3416: 2h
TC-65: 20h
NRX-1223: 30m
IOSP-553: 1.5h
CE-1136: 4h
CE-1038: 2h
COREUS-4237: 1h
AV-1466: 1h
AV-1456: 1h		 Total 37h 30m 31.01.2020 10.02.2020
4.15.0 Adam Borek, Giorgos Tsiapaliokas Manual: 23h 30m MS-857: 5m
MS-838: 2h
SDK-457: 6h
SDK-461: 2h
PAR-495: 10m
MON-5871: 8h
MON-5871: 2h
MON-5968: 1h
APPTS-2507: 3h
TK-412: 30m
IOSP-539: 15m
CE-1101: 1h
CE-1059: 3h
AV-1398: 4h
AV-1436: 4h
AV-1437: 1h		 Total 61h 30 m 17.01.2020 27.01.2020
4.14.1 James Birtwell, Adrian Sliwa Manual: 2h [REFER-133] - 6 : Total: 8h 18.01.2020 20.01.2020
4.14.0 James Birtwell, Adrian Sliwa Manual: 28h [COREUS-3072] - 6
[NRX-1168] - 0.5
[MS-761] - 6.5
[IOSP-518] - 10min
[CNSMR-3317] - 16
[CNSMR-3174] 0.5
[COREUS-3639] - 2
[AV-1409] - 1
[CE-1047] - 2
[CE-1054] - 6
[NRX-1167] - 6
[CNSMR-3353] - 2
[IOSP-528]
[PRSCR-1613] - 3		 Total: 85h 40min + ?? 09.01.2020 17.01.2020
4.13.0 Michal Kwiecien, Viorel Mihalache Manual: 26h MS-741: 1h
MS-742: 1h
APPTS-2296: 1.5h
APPTS-2288: 1.5h
TK-324: 1h
TK-325: 1h
CE-1011: 5h
NRX-1158: 1h
CNSMR-3275: 1h
PRSCR-1551 : 5h
PRSCR-1545: 0.5h
IDP-516 : 5h
 Total: 46h 06.12.2019 16.12.2019
4.12.0 Konrad Muchowicz, Danilo Aliberti Manual: 24.5h IOSP-396: 0.5
MS-635: 0.25h
CNSMR-3209, AV-1287, AV-1336, CNSMR-3210, AV-1304: 3h
CNSMR-3204: 3h
CNSMR-3212, PRSCR-1515: 3h
GW-1149, PAR-418: 13h
CNSMR-3205: 3h
APPTS-2169, CE-976: 10h
MON-5776, MON-5768: 2.5h
MS-611: 4h
IDP-471: 1h
CE-922: 3h
TK-271: 1h
APPTS-2208: 2h
PAT-444: 2.5h
IOSP-432: 1h
 Total: 52.75h 22.11.2019 3.12.2019
4.10.0 Ilya Puchka, Yasuhiro Inami Manual: 23.5h MS-353: 3h
COREUS-2191: 8h
MON-5641: 10h
TK-132: 0.5h
APPTS-1941, APPTS-2030, APPTS-2037: 30h
PRSCR-1435: 1h
AV-1228: 9h
GW-1028: 0.5h
NRX-1023: 10h
CNSMR-3119: 8h
CE-869: 8h
MS-412: 1.5h
MS-388: 1.5h
MS-427: 6h
GW-915: 8h
CNSMR-3120: 5h
IOSP-253: 2h
IOSP-275: 2h		 Total: 137.5 25.10.2019 4.11.2019
4.9.1 Michael Brown, Yuri Karabatov Manual: 1h AV-1225: 1h Total: 2h 22.10.2019 24.10.2019
4.9.0 Michael Brown, Yuri Karabatov Manual: 26h IOSP-200: 10m
GW-990: 2h
MS-304: 2h
MON-5545: 30m
AV-1181: 1h
TES-481: 30m
CE-846: 1h
IOSP-15: 3h
MS-315: 30m
IOSP-221: 10m
IOSP-209: 4h
PRSCR-1405: 30m
IOSP-233: 30m		 Total: 41h 50m 14.10.2019 22.10.2019
4.8.0 Giorgos Tsiapaliokas, Ben Henshall Manual: 23h 00m MS-204: 60m
MS-247: 15m
MS-262: 30m
MS-259: 5m
MON-5431: 2h
CNSMR-3029: 10m
CE-795: 10m
CE-799: 10m
GW-888: 15m
GW-957: 15m
APPTS-1752: 6h
GW-952: 8h
AV-1154: 1h		 Total: 19h 53m 30.09.2019 7.10.2019
4.7.0 Joshua Simmons, Adrian Śliwa Manual: 21h 55m AV-1098: 15m
AV-1103: 30m
GW-865: 1h
GW-914: 1h
GW-927: 1h
GW-938: 1h
GW-913: 12h
CNSMR-2899: 1m
TES-409: 30m
APPTS-1637: 1h
CNSMR-2881: 45m
MON-5337: 15m
CNSMR-2901: 30m		 Total: 41h 41m 16.09.2019 23.09.2019
4.6.1 Anders Ha,
Michał Kwiecień		 Manual: 1h 15m APPTS-1646: 12h Total: 13h 15m 09.09.2019 12.09.2019
4.6.0 Anders Ha,
Michał Kwiecień		 Manual: 24h 10m MN-705: 1h
MS-99: 1h
CNSMR-2772: 1h
MS-98: 3h
MS-102: 1h
GW-805: 1h
AV-1023: 0.5h
CNSMR-2782: 1h
MS-111: 2h
CNSMR-2784: 2h
GW-878: 1h
CNSMR-2787: 2h
CNSMR-2788: 1h
MS-103: 0.5h
PRSCR-1328: 3h
PRSCR-1333: 0.5h
CNSMR-2808: 0.5h
CE-683: 2h
AV-1041: 1h
CNSMR-2563: 0.5h
CNSMR-2813: 0.5h
CNSMR-2814: 0.5h
CNSMR-2824: 0.5h
CNSMR-2480: 32h		 Total: 83h 10m 02.09.2019 10.09.2019
4.5.0 Chitra Kotwani
Joao Pereira		 Automated

Parallel: 1h 47m
Serial: 8h 58m

Manual: 14h 21m		 AV-886: 1h
CE-615: 1h
CE-617: 5h
NRX-831: .5h
CNSMR-2530: 1h
CNSMR-2543: 4h
CNSMR-2628: 1h
CNSMR-2629: 8h
CNSMR-2631: 4h
CNSMR-2634: 2h
CNSMR-2635: 2h
CNSMR-2636: 4h
CNSMR-2639:.5h
CNSMR-2640: 4h
CNSMR-2641:.5h
CNSMR-2649:.5h
CNSMR-2655:.5h
CNSMR-2668: 1.5h
CNSMR-2670: 1h
CNSMR-2673:.5h
CNSMR-2676: 1h
CNSMR-2682: 6h
CNSMR-2684: 1h
CNSMR-2685: 2h
CNSMR-2687:.5h
CNSMR-2694: 1.5h
CNSMR-2696: 4h
MON-5082: 3h		 Total: 90h 36m 19.08.2019 28.08.2019
4.4.0 Danilo Aliberti
Sergey Shulga		 Automated: Parallel execution: 1 hour 28 minutes
Serial execution: 10 hours 15 minutes

Manual: 22 Hours 45 Minutes		 CNSMR-2521: 5days,
NRX-790: backend issue not resolved,
CNSMR-2515: 19 hours,
AV-910: 2days,
CNSMR-2509: 1day,
CNSMR-2506: 1day, 5hours,
CNSMR-2503: 1day, 1hour 10minutes,
CNSMR-2502: 6days and an hour,
CNSMR-2506: 1day, 5hours		 Total: 18d 7h 10m 05.08.2019 12.08.2019
4.3.0 Julien Ducret
Diego Petrucci		 Automated

Parallel execution: 1h 54min Serial execution: 8h 41min

Manual: 24h 50min		 CE-517: 30min
CNSMR-2143: 2days
CNSMR-2395: 0.5day
CNSMR-2333: 30min
CNSMR-2334: 30min
MON-4916: 30min
MON-4916: 30min
MON-4964: 30min
CE-512: 3hrs
CNSMR-2363: 1hr 30min
CNSMR-2338: 30min
CNSMR-2337: 60min
 Total: 44h 01m 22.07.2019 30.07.2019
4.2.0 Viorel Mihalache
Joshua Simmons		 Automated: 8h 41min
Manual: 24h 30min		 AV-852: 3h
CNSMR-2173: 2h
NRX-724: 30min
CNSMR-2147: 8h
NCSMR-2167: 30min
NRX-720: 30min
CNSMR-2164: 30min
CNSMR-2162: 30min
AV-843: 30min
 Total: 49h 11m 08.07.2019 15.07.2019
4.1.0 Martin Nygren
Adam Borek		 Automated: 8h 57min
Manual: 24h 15min		 NRX-686 and NRX-687: 8h
CNSMR-1947: 1.5h
CNSMR-1952: 2h
Other release duties: 9.5h		 Total: 54h25m 24.06.2019 01.07.2019
4.0.1 Ilya Puchka Automated: -
Manual: 1h 30min		 GW-668: 16h Total: 17h30m 20.06.2019 21.06.2019
4.0.0 Anders Ha
Ilya Puchka		 Automated: 8h 21m
Manual: 37h 00min		 AV-519: 17h
NRX-649: 2h
AV-677: 3h
CNSMR-1811: 1h
AV-704: 1.5h
AV-701: 16h
AV-737: 1.5h
AV-736: 2.5h
Total: 90h 10.06.2019 18.06.2019
3.17.0 Witold Skibniewski
Viorel Mihalache Oprea		 Automated: 8h 15m
Manual: 26h 45min		 CNSMR-1690: 1h Total: 36h 28.05.2019 30.05.2019
3.16.0 David Rodrigues
Ben Henshall		 Automated: 6h 50m
Manual: 19h 35min		 CNSMR-1556: 2h30m
CNSMR-1537: 3h
CNSMR-1525: 1h
CNSMR-1438: 1h
CNSMR-1437: 2h
CNSMR-1555: 1h
CNSMR-1540: 4h		 Total: 40h55m 13.05.2019 16.05.2019
3.15.0 Sergey Shulga
Joao Pereira
Michael Brown		 Automated: 7h 37m
Manual: 24h 15 min		 CNSMR-1449: 1h
CNSMR-1443: 12h
CNSMR-1381: 2h
CNSMR-1438: 30min
CNSMR-1430: 30min
CNSMR-1413: 20min
CNSMR-1412: 20min
CNSMR-1375: 20min
CNSMR-1391: 15min		 Total: 49h07m 29.04.2019 07.05.2019
3.14.0 Giorgos Tsiapaliokas
Yasuhiro Inami		 Automated: 07h28m
Manual: 24h10m		 NRX-506: 2h
NRX-495: 30m
NRX-501: 30m
CNSMR-1323: 30m		 Total: 35h08m 15.04.2019 23.04.2019
3.13.0 Anders Ha
Viorel Mihalache		 Automated: 07h
Manual: 19h		 CNSMR-1183: 3h
CNSMR-1181: 2h		 Total: 31h 1.04.2019 4.04.2019
3.12.0 Ben Henshall
Danilo Aliberti		 Automated: 07h16m
Manual: 22h		 MON-4225: 3h Total: 32h16m 18.03.2019 21.03.2019
3.11.0 Adam Borek
Ilya Puchka		 Automated: 07h17m
Manual: 19h30m		 CNSMR-894: 6h
CNSMR-913: 2h
CE-262: 2h
CE-261: 2h
Expired certificates: 3h		 Total: 41h47m 04.03.2019 11.03.2019
3.10.0 Martin Nygren, Witold Skibniewski Automated: 07h30m
Manual: 28h
 CNSMR-814: 30m Total: 36h00m 18.02.2019 21.02.2019
3.9.1 Michael Brown Automated: 04h00m
Manual: 14h
 CNSMR-705: - 30m
AV-312: - 30m		 Total: 19h00m 11.02.2019 13.02.2019
3.9.0 Michael Brown, Giorgos Tsiapaliokas Automated: 07h25m
Manual: 24h
 CNSMR-680: - 2h
 Total: 33h25m 04.02.2019 08.02.2019
3.8.0 Sergey Shulga, Diego Petrucci Automated: 07h30m
Manual: 33h
 CE-125: - 2h
CNSMR-538: 1h
AV-243: 1h
CNSMR-556: 2h
NRX-229: 1h
NRX-232: - 1h
CNSMR-554: 1h
NRX-229: 5h
NRX-232: 3h
Total: 57h30m 21.01.2019 24.01.2019
3.7.0 Ben Henshall, David Rodrigues Automated: 06h58m
Manual: 32h
 MON-3855: 2h
MON-3857: 1h
AV-207: 1h
NRX-190: 3h
CNSMR-493: 3h
CNSMR-477: 3h
 Total: 2d3h58mh
3.6.0 Viorel Mihalache, Ilya Puchka Automated: 06h50m
Manual: 32h
CNSMR-388: 2h
CNSMR-397: 1h
CE-146: 2h
NRX-150: 8h
CNSMR-404: 1h
NRX-149: 4h
UA-8329: 3h
UA-8431: 1h
CNMSR-365: 1h
CNSMR-324: 2h
CNSMR-340: 3h
CE-124: 2h
 Total: 2d20h50min
3.5.0 Wagner Truppel Automated: 06h47
Manual: 28h
 CNSMR-82: 1h39m
 Total: 1d12h26m
3.4.0 Martin Nygren Automated: 06h40
Manual: 32h
 UA-8385: 2h
UA8381: 4h
UA-8375 6h
UA-8374 2h
UA-8362 1h
UA-8369 2h
UA-8372 1h
MON-3631 2h
MON-3634 14h
UA-8359 13h
 Total: 3d9h40min
3.3.0 David Rodrigues Automated: 09h40
Manual: 14h
 UA-8268: 1h
UA-8269: 1h30
UA-8252: 5h
 Total: 1d7h10min
3.2.0 Danilo Aliberti Automated: 12h53
Manual: 10h
 UA-8166: 4h
UA-8149: 2d
UA-8187: 3h
 Total: 3d6h

SDK Release calendar

Version Associated App Version Release Engineer(s) Engineering effort Total effort Cut-off date Release date
1.0.0 4.8.0 Giorgos Tsiapaliokas
Ben Henshall		 Nothing outside of release notes / running release command 🕺 0h 07.10.2019 07.10.2019
0.7.0 3.16.0 David Rodrigues
Ben Henshall		 CNSMR-1589: 3h (Involved a lot of waiting due to dependency on DevOps)
Expired GitHub token issue: 2h		 4h30m 17.05.2019 21.05.2019

Post-mortem

If the release did not go as expected, request a meeting with the iOS team so that the reasons for this failure are analyzed and addressed in order to minimize similar problems in the future.