In the fast-paced world of mobile app development, efficiency and quality are paramount. Swiggy, a leading on-demand convenience platform, has consistently innovated to enhance user experiences and optimize operations. A pivotal step in this journey was transitioning from an in-house CI/CD setup to Bitrise, a renowned CI/CD platform. This shift marked a significant improvement in build times, efficiency, and code quality, making Swiggy’s development process more agile and reliable.
Swiggy’s CI/CD Journey for iOS Apps
Continuous Integration (CI)
Swiggy’s CI process is designed to ensure code sanity and quality. Here are the key components:
- PR Tagging: Each pull request (PR) is tagged with a relevant JIRA ticket to track development tasks.
- GitHub Labels: Labels such as “Review Required,” “QA Completed,” and “Ready to Merge” are added to PRs to streamline the review process.
- Static Code Analysis: SwiftLint is used to enforce Swift guidelines and conventions, maintaining high code standards.
- Release Milestones: Milestones are set to organize and prioritize releases.
Unit Tests
Unit tests are crucial for validating code changes. Here’s how Swiggy integrates them:
- PR Review and Approval: A custom GitHub action workflow ensures that each PR is reviewed by at least two reviewers and approved by the code owner before merging.
- Bitrise Integration: Once approved, the PR is mapped to Bitrise’s Pull Request Trigger Map, triggering unit tests for changed modules via Bitrise pipelines.
- Code Coverage Analysis: An in-house script calculates code coverage from the
.xccoveragefile, providing detailed analysis on GitHub.
Continuous Deployment (CD)
Swiggy supports five build configurations for different use cases:
- Debug (Development): Used for creating development builds to run on iPhones.
- Automation (Development): For automation builds with accessibility identifiers.
- Debug (Distribution) (Ad Hoc): For sharing builds with QA teams via Firebase or Bitrise distribution.
- PreProduction (App Store): A replica of the release build with some security checks disabled, used for internal testing and debugging.
- Release (App Store): The final build with all security checks enabled, published to the App Store.
Custom Build Triggering
To accommodate multiple runtime configurations, Swiggy developed a custom tool to trigger Bitrise builds. This tool allows users to input parameters as environment variables, enhancing flexibility and customization.
Build Workflows and Notifications
Different workflows are executed based on the build type:
- UATWorkflow: Includes custom scripts and parameters for UAT builds.
- SwiggyDeployWorkflow: Generates and uploads IPA files to TestFlight.
- SwiggyBitriseWorkflow: Creates ad hoc distribution IPA files and uploads them to Bitrise and Firebase.
- SwiggyAutomationWorkflow: Generates automation IPA files with accessibility identifiers for test suites.
Slack notifications are sent when builds start and complete, keeping developers informed.
Monitoring and Alerting
Swiggy uses the Bitrise Insights dashboard to monitor key metrics such as credit usage, build count, build time, and failures. Alerts are set up to identify anomalies, ensuring proactive management of the CI/CD pipeline.
Impact
The transition to Bitrise has yielded significant benefits:
- 80% Reduction in Wait Time: Enhanced concurrency has drastically reduced wait times.
- 8–10 Minutes Reduction in Build Time: Powerful remote machines and caching have sped up the build process.
- 60% Improvement in Tech Stack Upgrades: Time spent on upgrading tools like Xcode, Fastlane, and Ruby has decreased.
Conclusion
Swiggy’s commitment to innovation and excellence in mobile app development remains strong. By leveraging Bitrise’s features such as build cache, release management, and integrations, Swiggy aims to further optimize its development process and stay ahead in the evolving mobile app landscape.
Read more such articles from our Newsletter here.
