Awesome

GitHub Action Continous Delivery Setup

This repository demonstrates a continous delivery (CD) setup including a web service, a shared Swift Package, and an iOS App.

Continous Delivery Setup

It is a prerequiesite to have access to a Apple Developer Account that allows TestFlight releases and create a app in App Store Connect that matches the bundle identifier you have defined in the App project.

App Store Connect Access

The TestFlight deployment requires access to the App Store Connect API using an API key. Please follow the Apple instructions to Creating API Keys for the App Store Connect API. The key needs the App Manager access role. Store the following information in the following GitHub secrets:

APPLE_ID: The Apple ID you use to access the App Store Connect API.
APP_STORE_CONNECT_ISSUER_ID: The issuer ID of the App Store Connect API is displayed in the App Store Connect API keys section.
APP_STORE_CONNECT_API_KEY_ID: The key ID of the API key created in the App Store Connect API keys section.
APP_STORE_CONNECT_API_KEY_BASE64: The content of the key created in App Store Connect condensed into a Base64 representation, e.g., using base64 -i AuthKey_ABCDEFGHIJ.p8 | pbcopy.

Apple Xcode Certificate and Provisioning Profile

The GitHub Action imports the Apple certificate and provisioning profile from the GitHub secrets and installs them in a local KeyChain on the GitHub runner instances. Please follow the GitHub instructions to Installing an Apple certificate on macOS runners for Xcode development.

Obtaining the Apple provisioning profile requires you to follow the following steps:

Register the app identifier in the Apple Developer Account Identifiers section using the bundle identifier for your application, e.g., com.schmiedmayer.continousdelivery.
Create an AppStore distribution provisioning profile in the Apple Developer Account Profiles section using the app identifier you have created in the previous step.
Download the provisioning profile and convert it to a Base64 representation as detailed in Installing an Apple certificate on macOS runners for Xcode development and add it as the value for the BUILD_PROVISION_PROFILE_BASE64 secret.

After following the setup steps detailed in Installing an Apple certificate on macOS runners for Xcode development and obtaining the Apple provisioning profile as described above, you should have the following secrets configured in the repository settings:

BUILD_CERTIFICATE_BASE64: The Base64 version of the Apple signing certificate to build your iOS application.
P12_PASSWORD: The password for the Apple signing certificate.
BUILD_PROVISION_PROFILE_BASE64: The Base64 version of the Apple provisioning profile to build your iOS application.
KEYCHAIN_PASSWORD: A password for the keychain that will be created on the runner instance.

Be sure that you update the name of the provisioning profile in the Gymfile and update the app name, bundle identifyer, Xcode project name, paths, and other settings in the fastlane files when modifying the template to your needs!

Swift Package and Fastlane Update ACCESS_TOKEN

The Swift Package and Fastlane Update workflow requires an ACCESS_TOKEN secret: a GitHub Personal Access Token (PAT) allowing write access to the repository. I suggest using a bot account to create the access token. Using the PAT triggers the GitHub Actions in the create PR. The GitHub documentation provides instructions on creating a PAT. The scrop of the token can be limited to the public_repo scope for public repositories or the repo scrope for private repositories as well as the workflow scope.

Removing the token input in the GitHub action workflow results in using the default GITHUB_TOKEN and the GitHub Action bot account that does not trigger any possible merge checks in the newly created PR.

Continous Delivery Workflows

Beta Deployment

The Beta Deployment workflow is triggered when a new commit is added to the main branch.

It first runs the Build and Test workflow to ensure all tests are passing. Once the Build and Test workflow passes, it builds the iOS application so it can be archived and sent to TestFlight for internal beta deployment. Once the Build and Test workflow passes, it also creates a new Docker image of the web service pushed to GitHub Packages using the beta tag.

Build and Test

The Build and Test workflow builds and tests the iOS application, shared Swift package, and web service. It runs all unit and user interface (UI) tests defined in the targets. The iOS application is tested on the iOS simulator on macOS. The shared and web service Swift packages are tested on Linux and macOS as well as in release and debug configuration to demonstrate all possible variations.

Release Deployment

The Release Deployment workflow is triggered when a new tag is added to the repository. It uses the tag to create a new Docker image of the web service pushed to GitHub Packages using the added tag as well as the latest for tagging the Docker image.

SwiftLint

The Swiftlint workflow is triggered by every pull request (PR) and checks if the files found in the diff contain any SwiftLint violations. You can change the SwiftLint configuration in the .swiftlint.yml file found at the root of this repository.

Swift Package and Fastlane Update

The Swift Package and Fastlane Update workflow runs every month to update the Swift Package dependencies in the iOS application, web service, and shared Swift package. The workflow creates a PR that contains all the changes.

Contributing

Contributions to this project are welcome!

License

This project is licensed under the MIT License. See License for more information.