Last active
January 1, 2020 19:20
-
-
Save joeboyscout04/a2c99ecc48b1fb6b17ddeb9eb39657c2 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
### Intro | |
This is a proposal of the CI workflow for the client (iOS/Android) apps. It's modeled on a workflow I used when consulting which was a project in a similar setup. The main assumptions which are similar to that project are: | |
- Infrequent, manually-triggered releases to App Store (ie, not a Continuous Delivery) | |
- Frequent beta app distribution | |
- Emphasis on manual testing by external users | |
## Setup | |
### Branches | |
- `master` is the currently released version of the app. This branch will be *protected* and only accessible via PR. | |
- `dev` is the current beta version (release candidate) of the app. This branch will be *protected* and only accessible via PR. | |
- All other branches are to be feature branches. | |
### CI Tooling | |
- The CI tooling with be Github Actions, with Fastlane doing the bulk of the actual work. | |
- Use of Fastlane as much as possible for reusability between CI systems | |
## Proposed Workflows | |
### Build PR | |
This workflow runs whenever there is an update to a PR | |
1. Build the app for testing | |
2. The end | |
### Beta | |
1. Increment the build number (not the marketing version number) | |
2. Create a changelog of all git commits since the last tagged beta release. | |
for app in ['joulebug', 'ikea']: | |
3. Download certs and provisioning profiles using `match` | |
4. Build and export the app for Development | |
5. Upload the build to the Beta service | |
6. Upload dYSMs and clean up the build archive | |
7. Post a slack message that the workflow was successful. | |
end | |
8. Commit the build number bump with a "[ci-skip]" commit message | |
9. Add a Github tag of the version_number+build_number. | |
10. Push the updated version number and tag to the remote. | |
### Release | |
TODO | |
## Development Process | |
### Development on Feature or Bugfix | |
1. Developer creates a feature branch from `Dev`. | |
2. Work on the feature branch to create a new feature, fix bugs, etc. | |
3. Create a PR targeting `dev` to merge the feature. This will invoke the `build-pr` Workflow. | |
4. After successful review, feature branch is merged to `Dev`. This will invoke the `beta` Workflow. | |
### Releasing | |
1. When the release is ready, developer will open a PR from `Dev` to target `master`. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment