This session will create sample workflows based on three different case studies.
Solo developer
- One app available on two platforms with most code on the main branch, a few dependencies
- Send to Test flight to friends, manually release app
- Key is simplicity that is reliable and maintainable
- Simple what, where and when
- You start with what version of macOS and Xcode you want
- By default it will build whenever a code is pushed to Main branch
- For solo you may want to build regardless of branch
- Select an action of Archive and target TestFlight and App Store
- Sent Post action to Test Flight – External team and select a group
- Create an archive action for each platform and post action that you’d like
- To add a secondary dependency instead of just swift packages – more information is available- you can create a “Post Clone” Script to do run a python command to include additional items for the build environment.
Medium-sized team
- Team of dev, QA, and PM on a globally distributed. spereate branches by develop with pull requests to merge, using tags to match a release
- Testing both UI and Unit is done
- Multiple TestFlight plans – use cloud to communicate
- Create three workflow
- Pull request
- Whenever a new pull is created tests are to be run
- Add a new start request to select target Branch of Beta and remove the branch start condition
- Create a new Action and select a Test target
- Add multiple devices to cover appropriate mix for simple testing
- With a successful build on this workflow – a developer can deliver their code to the Beta branch
- Beta workflow
- This is to deliver your code the QA team – this will run every time a change is delivered to a pull request
- Start condition of Branch condition to Beta from Main
- Add archive action and select TestFlight (Internal Testing Only)
- Add a Post Action to upload to App Store Connect to the internal testers
- Will also add a test action to ensure you don’t deliver a broken build to the QA team.
- You can add a customer icon via custom scripts so testers know it is a beta build. So you run a “pre-build” script
- Release workflow
- Developer must merge the Beta stream to the Main Branch and add a “release candidate” tag is added
- Steps are basically the same as Beta Workflow – you can duplicate the workflow and then update the start condition. In this case we use “Tag changes” – and add value of “tags beginning with release/“
- Change the Archive change to TestFlight and App Store
- Post action change the Test Flight Internal group and add “Executive Group” also add a second test Flight to external team –
- You can now add a Notify post action to add a notification to Slack
- Pull request
Large team
- This is a very large team, similar to the medium sized team. There is an app that has been around since the beginning of the App Store. There are tons of tests, and many TestFlight testers both internal and external, and they use slack, but they also use CI/CD already using an in-house team developed with limited knowledge.
- They also use Project Management (PM) tool with various dashboards that allows others to vie status
- Migration to Xcode cloud should be done in chunks. To allow a successful migration overtime.
- One is create a workflow that can be released – start here.. leverage flow from above Medium size team. Once it works you can integrate into your process
- Create a workflow for testing – Then migrate your tests, tests may fail more than before, so you can set Xcode cloud to progress with “Not required to pass” you can see the results but it won’t stop from delivering the code. It allows you to fix your tests off your critical path. You can create multiple test plans – migrating reliable plans over time and making them required.
- Create integration to existing processes – finally you look at integration with existing PM system and reporting. Some of the will be similar to prior things, you can create powerful scripts, Xcode cloud APIs, and/or Webhooks there is more about this at Apple’s documentation.