Tech

Building a Robust Mobile DevOps CI/CD Pipeline from Start to Finish

Agmo Engineering

• 5 min read

I still remember the first time I tried to manually build and release a mobile app. It involved zipping code, uploading files to a distribution platform, and hoping the final product worked as expected. It was time-consuming and nerve-racking. That’s when I realized I needed a more efficient system—one that would reduce human error, speed up delivery, and give my team greater confidence in every release. Enter Mobile DevOps CI/CD.

In this article, I’ll walk you through how I set up my Mobile DevOps CI/CD process, sharing the steps I took, the tools I used, and the lessons I learned. This setup ensures that every code change gets tested, reviewed, scanned for security vulnerabilities, built automatically, and—if all checks out—released seamlessly to platforms like App Center or TestFlight.

My Mobile DevOps CI/CD Flow at a Glance

Below is a high-level overview of the flow. Each stage is designed to catch issues early, provide rapid feedback, and let the team focus on innovation rather than repetitive tasks.

  1. Pull Request Created
  2. Unit Testing Coverage & SonarQube
  3. Auto Build
  4. App Audit Scan
  5. PR Reviewing
  6. Fixing (if any step fails)
  7. PR Ready to Merge & Merged
  8. App Release
  9. Build App Release & Upload to App Center/TestFlight
  10. Ticket Tagging
  11. MobSF Scan & Report
  12. Finish

This might look like a lot to set up at first glance, but once it’s in place, you’ll wonder how you ever lived without it!

1. Pull Request Triggers the Pipeline

The CI/CD process kicks off with a Pull Request (PR). It’s not just a trigger for automation—it’s where collaboration, learning, and quality checks come together to keep your code in top shape.

Why PRs Matter

  • Team Collaboration: PRs get everyone involved. Seniors can guide juniors, share feedback, and keep the codebase consistent. It’s like a team huddle before deploying the next big play.
  • Learning in Action: Reviewing code isn’t just for catching mistakes—it’s a chance to learn. Juniors get hands-on experience, spotting patterns, understanding best practices, and even improving their own skills while reviewing others’ work.
  • Bug Prevention: PRs are your first line of defence. They help catch bugs, edge cases, or risky code before it reaches production or even in development. Think of it as your quality control checkpoint—for example, flagging an inefficient algorithm or a missed validation.

When a PR is created, the pipeline takes over:

  1. Automated Tests: These ensure the new code behaves the way it should and doesn’t break anything else.
  2. Build Validations: The app gets built successfully, catching any dependency or configuration issues.

If something fails, developers fix it, push the updates, and re-trigger the process—quick and efficient.

2. Automated Testing with Coverage & SonarQube

Right after a PR is created, the pipeline kicks off unit tests and SonarQube scans to keep your application robust and secure.

  • Unit Tests
    • Why They Matter: They serve as guardrails for your code, ensuring new changes don’t break existing functionality. Failing tests guide developers to either revise the new logic or update the existing tests.
    • Code Coverage: Not all modules need the same coverage. Critical areas often demand higher coverage, while less critical parts can be more flexible.
    • Prevention: Unit tests uncovered hidden issues in legacy code. To keep things stable, avoid changes that could break existing features.

SonarQube acts as a detective, flagging bugs, code smells, and vulnerabilities early—especially those aligned with OWASP’s Top 10 risks—so issues like injection threats are caught before they escalate.

3. The Auto Build Step

Once tests pass, the pipeline attempts to build the application—an essential checkpoint that ensures broken code never sneaks into your main branches. If the build fails, it blocks merging, preventing nasty surprises for the next developer who pulls the latest changes.

We run our builds on a macOS machine rather than relying on default cloud instances. Our customized setup is not only faster but also easier to maintain. We can quickly update Xcode versions, SDKs, or other platform dependencies without waiting on external services. This speed and control save us from extended downtime and help the team stay productive.

4. App Audit Scan for Security

As our department grows, it becomes more challenging to ensure every project meets the same security standards right from the start. That’s why we’ve built in a mandatory audit scan—even for early-stage apps. By catching any vulnerabilities, outdated libraries, or missing configurations upfront, we avoid last-minute firefighting when an app is on the brink of release. It’s a proactive safety net that keeps security at the forefront, preventing those frantic, eleventh-hour fixes that nobody wants to deal with.

5. The Merging & Post-Merge Steps

Once the tests, reviews, pre-build checks, and security audits have all passed, it’s time for the final merge. Think of this as crossing the finish line after a series of thorough checkpoints. By merging only code that’s been fully vetted, we ensure the main branch remains stable for everyone else who pulls from it. After the merge, some teams opt for a quick post-merge build or final verification, confirming that no last-minute surprises crept in.

6. Releasing the App

When it’s time to release, we first check the PR title. If the title follows a specific naming convention, we automatically trigger a new build. Depending on the target branch, the pipeline selects the correct environment (e.g., staging, production) before compiling the app. Once built, we upload the binaries to AppCenter and TestFlight—although we’re preparing to migrate to Firebase Distribution as AppCenter is sunsetting. We currently do not automatically deploy to the Play Store, as we prefer a bit more manual control, but we anticipate adding that step in the future. To keep everyone in sync, we also auto-tag the related tickets (tasks, bugs, or user stories) so developers, project managers, and QAs know exactly which features or fixes went into each release version.

7. Security Scan with MobSF

We include MobSF (Mobile Security Framework) to shine a light on hidden risks that might lurk in third-party libraries or SDKs. It generates a security score and uncovers vulnerabilities you might never spot in your own code—like outdated dependencies or insecure configurations. Think of it as an extra layer of protection, ensuring that no sneaky security flaws make it into production. By catching these issues early, we save ourselves from major headaches down the road and keep our apps more secure for everyone.

Conclusion

Implementing a Mobile DevOps CI/CD pipeline has been a rewarding journey for our team, and it continues to evolve as our projects grow. Along the way, we’ve tackled unique challenges across multiple platforms—Android Native, iOS Native, React Native, and Flutter—each requiring its own tools, configurations, and best practices. Here’s why our efforts have been worth it:

  • Faster Releases: Automated testing, code reviews, and security scans speed up our deployment cycle.
  • Fewer Bugs in Production: Catching errors early reduces costly fixes and prevents unpleasant surprises.
  • Better Collaboration: Pull requests and reviews bring the team closer, fostering mentorship and shared learning.
  • Consistent Security: Mandatory scans ensure every platform follows the same high-security standards.
  • Room to Grow: We still have more enhancements planned—like deeper platform-specific checks and additional release automation—which we’ll share in future updates.

By continuously refining our CI/CD pipeline, we’re building a system that’s robust, secure, and adaptable to the ever-changing landscape of mobile app development. It’s an ongoing journey—and one that keeps our team both challenged and excited about what’s next.

A big well done to everyone who helped build this pipeline. Your collaboration, problem-solving, and dedication have made all the difference.

Tze Yong Chu is the Head of Mobile Department of Agmo Group. With many years of experience at Agmo Group, he has played a pivotal role in delivering innovative mobile application solutions.