Implementing `sz deploy ios` for Automating iOS App Deployment #695

nilsreichardt · 2023-07-20T11:37:11Z

Description

This pull request introduces a significant enhancement to our deployment pipeline, specifically for the iOS app. It automates various stages of the deployment process, including the retrieval of the next build number, app building, and publication to the App Store or TestFlight.

Key changes include:

Deployment Stages and Flavors: The code defines different stages (stable, alpha) and flavors (prod) for the iOS app deployment. This allows for flexibility in managing various versions of the app.
Command Line Options: Several command-line options have been added to provide necessary parameters for the deployment process. These include API keys, issuer ID, private key, release notes, and the build flavor.
Build Number Automation: The function _getNextBuildNumber is implemented to fetch the latest build number from Google Play and increment it for the next build.
App Building and Publishing: Functions for building the app (_buildApp) and publishing it (_publish) have been implemented. They use the Codemagic CLI tools and require the build number as an argument.
Environment Variables: Sensitive information, such as API keys, are fetched from environment variables, keeping them secure and out of the codebase.

This new implementation greatly simplifies the iOS deployment process, making it more streamlined and less prone to manual errors.

Testing

Tested the command manually by deploying a new version to the alpha group.

Usage

sz deploy ios --help

Nils-MBP-13-M1-4:sz_repo_cli nils$ fvm dart run sz_repo_cli deploy ios --help
Deploys the Sharezone iOS app to the App Store or TestFlight. Automatically bumps the build number and builds the app. Codemagic CLI tools are required.

Usage: pub global run sz_repo_cli deploy ios [arguments]
-h, --help           Print this usage information.
-s, --stage          The stage to deploy to. The "stable" stage is used for App Store releases, the "alpha" stage is used for TestFlight releases.
                     [stable (default), alpha]
    --key-id         The App Store Connect API Key ID used to authenticate. This can be found in the App Store Connect Developer Portal. Learn more at https://developer.apple.com/documentation/appstoreconnectapi/creating_api_keys_for_app_store_connect_api. If the parameter is not provided, the value of the APP_STORE_CONNECT_KEY_IDENTIFIER environment variable will be used. If no value is set, the deployment will fail. Example value: 1234567890
    --issuer-id      The App Store Connect API Key Issuer ID used to authenticate. This can be found in the App Store Connect Developer Portal. Learn more at https://developer.apple.com/documentation/appstoreconnectapi/creating_api_keys_for_app_store_connect_api. If the parameter is not provided, the value of the APP_STORE_CONNECT_ISSUER_ID environment variable will be used. If no value is set, the deployment will fail. Example value: 00000000-0000-0000-0000-000000000000
    --private-key    The App Store Connect API private key used for JWT authentication to communicate with Apple services. This can be found in the App Store Connect Developer Portal. Learn more at https://developer.apple.com/documentation/appstoreconnectapi/creating_api_keys_for_app_store_connect_api. If not provided, the key will be searched from the following directories in sequence for a private key file with the name AuthKey_<key_identifier>.p8: private_keys, ~/private_keys, ~/.private_keys, ~/.appstoreconnect/private_keys, where <key_identifier> is the value of --key-id. If not given, the value will be checked from the environment variable APP_STORE_CONNECT_PRIVATE_KEY. If no value is set, the deployment will fail.
    --whats-new      Release notes either for TestFlight or App Store review submission. Describe what's new in this version of your app, such as new features, improvements, and bug fixes. The string should not exceed 4000 characters. Example usage: --whats-new 'Bug fixes and performance improvements.'
    --flavor         The flavor to build for. Only the "prod" flavor is supported.
                     [prod (default)]

Run "pub global run sz_repo_cli help" to see global options.

docs-page · 2023-07-20T11:37:13Z

To view this pull requests documentation preview, visit the following URL:

docs.page/sharezoneapp/sharezone-app~695

Documentation is deployed and generated using docs.page.

Jonas-Sander · 2023-07-25T20:15:25Z

Gonna review it completely tomorrow (sorry! ;p), but one "bigger" thing I'm not sure about right now is if we should always build the app in the "deploy" command. For me that is a bit unexpected.

I guess there could be the default case that no prod app was built, so it will be build when running the deploy command. In this case if there is already a prod app built then it would be used automatically for deployment?

Or maybe, since this could be complicating it unnecessarily, lets just add a --build-app flag for now? Or we just leave it to always build (current logic). Although what about if the deployment fails because some other flag was wrong and now we have to build the whole app again since we have no choice here? I think that an extra --build-app flag might be the best compromise for now. What do you think?

Ah and for the first approach I don't know how easy it would be to check if an already built app has the prod flavor. An easier approach could also be to just assume it is as implicit knowledge from our side (but which could lead to accidentally uploading a non-prod version). If its easy to check that its prod flavor then I would maybe favor the first approach, otherwise the --build-app (or whatever) approach. Or we could have the first approach with an additional --force-build-app flag.... Ah idk, i'm too tired right now:(

Jonas-Sander · 2023-07-26T08:56:35Z

tools/sz_repo_cli/lib/src/commands/src/deploy_ios_command.dart

+ ..addOption(
+ releaseStageOptionName,
+ abbr: 's',
+ allowed: _iosStages,
+ help:
+ 'The stage to deploy to. The "stable" stage is used for App Store '
+ 'releases, the "alpha" stage is used for TestFlight releases.',
+ defaultsTo: 'stable',
+ )


Random note: For the deploy web command the have the stages [alpha, beta, prod] instead of [alpha, beta, stable]. I guess these should be the same everywhere?

Also can you describe in the help what the stages do exactly and how they are used? From what I gathered "--stage alpha" will need a matching "beta group" in TestFlight called "alpha". Additonally the stage is used in the build process, what will it change there? Is there a change?

Random note: For the deploy web command the have the stages [alpha, beta, prod] instead of [alpha, beta, stable]. I guess these should be the same everywhere?

For now, we don't have an iOS beta track. Web is the only platform with a beta track (which btw we don't use xD).

Also can you describe in the help what the stages do exactly and how they are used? From what I gathered "--stage alpha" will need a matching "beta group" in TestFlight called "alpha". Additonally the stage is used in the build process, what will it change there? Is there a change?

Do you think it's a good idea to describe what the stage parameter changes in the build process / in the app at the help string of the iOS deploy command? I'll also create a PR for sz deploy android and sz deploy macos command. Changing the behavior how --dart-define=DEVELOPEMTENT_STAGE affects the app behavior would require to update the documentation at 5 difference locations (inside the app, at sz deploy ios, sz deploy android, sz deploy web and sz deploy macos).

My current draft of the help text is:

The stage to deploy to. The "stable" stage is used for App Store releases, the "alpha" stage is used for TestFlight releases (publishing to a TestFligh group that matches "alpha" as a group name). Additionally, the stage value is passed to the build command.

It was just confusing for me because for me just reading the argument description I thought it was only for TestFlight which confused me because I saw it was also passed to the build command (I forgot all about stages :D).

So I guess one thing I don't like is that the stage name and the TestFlight beta group names are coupled. In my opinion they should be decoupled so that we could change the stage names and not break anything for TestFlight. Decoupling it would have also helped me to understand that the stage string is not primarily for TestFlight, but our definition of deployment stages. They could be decoupled like in the deploy web-app code (just a simple map should be enough I guess).

Do you think it's a good idea to describe what the stage parameter changes in the build process / in the app at the help string of the iOS deploy command? I'll also create a PR for sz deploy android and sz deploy macos command. Changing the behavior how --dart-define=DEVELOPEMTENT_STAGE affects the app behavior would require to update the documentation at 5 difference locations (inside the app, at sz deploy ios, sz deploy android, sz deploy web and sz deploy macos).

Yeah you're right, a detailed description would be bad.

I like your description. If we decoupled the TestFlight stage name then we could leave the stuff about the beta group out in my opinion.

What about this?

The deployment stage to deploy to. The "stable" stage is used for App Store releases, the "alpha" stage is used for TestFlight releases. The value will be forwarded to the "sz build" command (if a fresh build is necessary).

I'm using now the following the help value for --stage:

"The deployment stage to deploy to. The "stable" stage is used for App Store releases, the "alpha" stage is used for TestFlight releases. The value will be forwarded to the "sz build" command "

I also decoupled the stage and the TestFligh Group names 👍

tools/sz_repo_cli/lib/src/commands/src/deploy_ios_command.dart

nilsreichardt · 2023-07-26T15:06:26Z

Gonna review it completely tomorrow (sorry! ;p), but one "bigger" thing I'm not sure about right now is if we should always build the app in the "deploy" command. For me that is a bit unexpected.

I guess there could be the default case that no prod app was built, so it will be build when running the deploy command. In this case if there is already a prod app built then it would be used automatically for deployment?

Or maybe, since this could be complicating it unnecessarily, lets just add a --build-app flag for now? Or we just leave it to always build (current logic). Although what about if the deployment fails because some other flag was wrong and now we have to build the whole app again since we have no choice here? I think that an extra --build-app flag might be the best compromise for now. What do you think?

Ah and for the first approach I don't know how easy it would be to check if an already built app has the prod flavor. An easier approach could also be to just assume it is as implicit knowledge from our side (but which could lead to accidentally uploading a non-prod version). If its easy to check that its prod flavor then I would maybe favor the first approach, otherwise the --build-app (or whatever) approach. Or we could have the first approach with an additional --force-build-app flag.... Ah idk, i'm too tired right now:(

My main intention for the sz deploy commands is to add a stable.yml CD file to our .github/workflows/ folder to be able to press one button to publish a new stable version.

Technically, it's just copying the alpha.yml file (for Android we would need to use fastlane instead of Firebase Distribution) and make a few changes (publish to App Store instead to TestFlight for iOS). However, to reduce code duplication (long-term goal is also to have a beta.yml), I started to create the sz deploy commands.

For this reason, the sz deploy commands are designed to be executed in our CD pipeline. Because when we have a working CD pipeline, there should be no reason to publish a new version with your local machine.

With this in mind I think having things like --build-app, etc. are a bit overkill because that are things we would (ideally) never use and it would increase the complexity of the code for future scenarios that are not planned. I think the approach "If we actually need these things, we can always add them later" is here the better way.

…698) In #695 I need to work with the attributes of `ProcessResult` but it would be helpful to still use `runProcessSucessfullyOrThrow` since this method checks if the command execution was successful (#695 (comment)).

tools/sz_repo_cli/lib/src/commands/src/deploy_ios_command.dart

Jonas-Sander

LGTM 👍

With this PR we make use of the new `sz deploy ios` command (#695) to remove code duplication.

Add iOS deploy comment

b2385e6

github-actions bot added the sharezone cli label Jul 20, 2023

nilsreichardt added 3 commits July 20, 2023 14:04

Update comments

39de010

Add doc comment

ea97ec9

Add --app-store for isStable

062fb6e

nilsreichardt marked this pull request as ready for review July 20, 2023 17:19

nilsreichardt requested a review from Jonas-Sander as a code owner July 20, 2023 17:19

Jonas-Sander requested changes Jul 26, 2023

View reviewed changes

nilsreichardt added 4 commits July 26, 2023 12:47

Fix method naming for get latest build number

500b9bf

Improve help string for stage.

4bab106

Throw if Codemagic CLI Tools are not installed

21036de

Move order of methods

1dcb4f6

nilsreichardt mentioned this pull request Jul 26, 2023

Add ProcessResult as return type to runProcessSucessfullyOrThrow #698

Merged

nilsreichardt added 3 commits July 26, 2023 13:14

Add comment to --release-type

3067bb6

Add ProcessResult as return type to runProcessSucessfullyOrThrow

e928ed8

Use runProcessSucessfullyOrThrow instead of runProcess

b676c67

nilsreichardt requested a review from Jonas-Sander July 26, 2023 15:06

nilsreichardt added 2 commits July 26, 2023 17:10

Switch iOS order

cbaba86

Improve

8e4e2c7

nilsreichardt added 3 commits July 28, 2023 12:50

Decouple TestFlight group names with stage

3efaca9

Update help text for stage

4382699

Adjust comment

9bffb25

nilsreichardt commented Jul 28, 2023

View reviewed changes

tools/sz_repo_cli/lib/src/commands/src/deploy_ios_command.dart Outdated Show resolved Hide resolved

nilsreichardt added 2 commits July 28, 2023 13:01

Move apple track into own file

e6e695a

Add license header

0e3b400

Jonas-Sander approved these changes Jul 30, 2023

View reviewed changes

nilsreichardt added this pull request to the merge queue Jul 30, 2023

Merged via the queue into main with commit 21e477c Jul 30, 2023
16 checks passed

nilsreichardt deleted the add-ios-deploy-command branch July 30, 2023 19:15

nilsreichardt mentioned this pull request Jul 30, 2023

Use sz deploy ios command in alpha.yml workflow #701

Merged

github-merge-queue bot pushed a commit that referenced this pull request Aug 5, 2023

Use sz deploy ios command in alpha.yml workflow (#701)

ccb15af

With this PR we make use of the new `sz deploy ios` command (#695) to remove code duplication.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implementing `sz deploy ios` for Automating iOS App Deployment #695

Implementing `sz deploy ios` for Automating iOS App Deployment #695

nilsreichardt commented Jul 20, 2023 •

edited

Loading

docs-page bot commented Jul 20, 2023

Jonas-Sander commented Jul 25, 2023 •

edited

Loading

Jonas-Sander Jul 26, 2023

nilsreichardt Jul 26, 2023

Jonas-Sander Jul 26, 2023

nilsreichardt Jul 28, 2023

nilsreichardt commented Jul 26, 2023

Jonas-Sander left a comment

Implementing sz deploy ios for Automating iOS App Deployment #695

Implementing sz deploy ios for Automating iOS App Deployment #695

Conversation

nilsreichardt commented Jul 20, 2023 • edited Loading

Description

Testing

Usage

docs-page bot commented Jul 20, 2023

Jonas-Sander commented Jul 25, 2023 • edited Loading

Jonas-Sander Jul 26, 2023

Choose a reason for hiding this comment

nilsreichardt Jul 26, 2023

Choose a reason for hiding this comment

Jonas-Sander Jul 26, 2023

Choose a reason for hiding this comment

nilsreichardt Jul 28, 2023

Choose a reason for hiding this comment

nilsreichardt commented Jul 26, 2023

Jonas-Sander left a comment

Choose a reason for hiding this comment

Implementing `sz deploy ios` for Automating iOS App Deployment #695

Implementing `sz deploy ios` for Automating iOS App Deployment #695

nilsreichardt commented Jul 20, 2023 •

edited

Loading

Jonas-Sander commented Jul 25, 2023 •

edited

Loading