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 .xccoverage file, 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.