Bitrise and Fastlane: Mobile App CI Pipeline at Vivid Seats
In the past year at Vivid Seats, we have increased our emphasis on quality and reliability across the entire Vivid Seats engineering organization. This has meant, among other things, ramping up our efforts to comprehensively test any code we write as well as investing in the tools we need to be successful. While our back-end and web services teams have fairly well-defined workflows for continuously testing and integrating changes using a self-hosted Jenkins environment, we had a difficult time making that solution work well for our native iOS and Android apps.
We began this effort with Jenkins configured to use a Mac Mini as a build slave to run unit and UI tests prior to release for both the iOS and Android platforms. However, we were still performing most of the release process manually. We also realized that in order to do the things we wanted to do, such as building and testing any code changes pushed to feature branches, and eventually incorporating test suite runs on multiple iOS/Android operating systems concurrently, resource scalability was quickly becoming a problem. Additionally, as mobile developers, we really didn’t want to be in the business of maintaining a Mac server farm.
So, we started to evaluate alternatives: hosted Continuous Integration/Continuous Deployment (CI/CD) services. The three platforms we evaluated were Circle CI, Travis CI, and Bitrise. Following the evaluation period, we chose Bitrise due to its mobile-centric focus, scalable pricing model, and performance.
The modularity of Bitrise’s step/workflow system was attractive, though what became even more crucial was its integration with and similarities to Fastlane, which we also started using around this time. Fastlane uses the concept of lanes, which are workflow steps designed to accomplish a particular task or set of tasks related to building and deploying applications. Lanes can be run from other lanes interchangeably, as a particular workflow requires.
While Bitrise is by no means unique in regard to Fastlane support, we found it pretty easy to get set up and running and definitely appreciated being able to run the same workflow steps locally as what Bitrise was doing in the cloud.
Using this combination of Fastlane and Bitrise, we’ve honed a set of workflows that does pretty much everything for us automatically. The tool set is even capable of initiating new releases and submitting those releases to the App Store or Play Store for review.
The general workflow I’ll outline here is specific to our iOS environment, but our Android release process is almost identical.
The Development Cycle
Once the code pertaining to a new feature or bug fix is complete and ready for developer review, the team member who implemented the changes opens a pull request on GitHub.
This triggers a build on Bitrise that uses our staging deployment lane, and does the following:
- Runs code quality static analysis to detect any violations of our custom quality rule set
- Builds the project and runs unit and UI tests on a staging build of our application
- Uploads a staging/adhoc build to Fabric for internal testing and distribution
Bitrise reports its build status in the open GitHub pull request and this blocks any merges into our stage branch until successful.
Only after the pull request is unblocked, is code reviewed and approved by at least one member of the appropriate dev team and is manually verified by a member of the QA team, it can be merged into the stage branch. Stage is our default branch and is considered to be always in a releasable state.
Releases
Once all the feature and bug fix implementations that make up a planned release have been merged into stage, a member of the dev or QA teams initiates the release process. This is done using a release preparation lane run locally that accepts the desired version number of the release. Bitrise then does the rest until it’s time to submit the app for review.
Our release preparation and deployment workflows on Bitrise do the following:
- Creates a release branch in our repository and opens a pull request to merge the contents of that branch into master.
- Once the release branch pull request is open, the release deployment workflow is triggered and starts building for App Store deployment.
- Runs smoke tests in parallel with the deployment builds. As the product of this step is an application binary that will be publicly distributed, we take the extra step of running smoke tests on live data, since prior to this point all test suite runs have been performed using mocked data.
- Creates a staging/adhoc build to match the release candidate’s version number and deploys it to Fabric.
- Creates and pushes a production build to App Store Connect for processing. Since the App Store metadata from version to version doesn’t change much, if at all, we’ve specified all the required release information in Fastlane metadata files and therefore we don’t have to manually edit it except to call out new features and significant changes in the user interface.
When the release candidate is done processing and is available on TestFlight, we give it a manual once-over just to make sure everything checks out. If it does, then at this point we submit the app for review and wait for approval.
Post-Release
After the app is reviewed and approved for release in the App Store, we release it and then merge the release branch into master.
This triggers our production release workflow on Bitrise, which:
- Constructs a changelog from the git commits included in the release
- Creates a tag for the release version
- Creates a GitHub release using that tag and the contents of the changelog as its description
- Opens a pull request to merge the contents of the release back into stage
Once the contents of the release are merged back into stage, the process is complete and development continues until it’s time to prepare the next release.
Was this information helpful?
We hope sharing the details of how we’ve leveraged Bitrise and Fastlane to save ourselves time and resources is helpful to others.
Additionally, we are actively hiring for several roles on our engineering team. If you’re interested to learn more about open positions, check out our careers page at vividseats.com/careers for more information.
