Skip to main content
CI/CD Pipelines

Module Overview

Estimated Time: 5 hours | Difficulty: Advanced | Prerequisites: Testing, Deployment modules
Continuous Integration and Continuous Deployment (CI/CD) are essential for maintaining code quality and delivering updates efficiently. For React Native specifically, CI/CD is more complex than typical web projects because you are building for two platforms (iOS and Android), each with its own build system, code signing requirements, and store submission process. The payoff is enormous: a well-configured pipeline means every pull request is automatically linted, type-checked, and tested; builds are reproducible across team members; and releasing an update goes from a 2-hour manual process to a single button click. This module covers setting up automated pipelines using GitHub Actions and EAS Build. What You’ll Learn:
  • GitHub Actions workflows
  • EAS Build integration
  • Automated testing pipelines
  • Code signing automation
  • Release management
  • Multi-environment deployments

CI/CD Architecture


GitHub Actions Setup

GitHub Actions is the most popular CI/CD platform for React Native projects because it offers macOS runners (required for iOS builds), generous free-tier minutes, and tight integration with your repository. The workflow files live in .github/workflows/ and run automatically on push, pull request, or release events.

Basic Workflow Structure

Complete CI/CD Workflow


EAS Build Integration

EAS (Expo Application Services) Build is Expo’s cloud build service. The key advantage: it handles native build complexity (Xcode, Gradle, code signing, provisioning profiles) on remote servers, so your team does not need macOS machines or Android SDK installations to produce production builds. Think of it as “Vercel for mobile apps.” The trade-off is cost (cloud build minutes are not free at scale) and less control over the native build environment. For most teams, especially those using Expo, EAS Build dramatically reduces the operational burden of mobile CI/CD.

EAS Configuration

EAS Build Workflow


Fastlane Integration

Fastlane is a Ruby-based automation tool that wraps the painful parts of iOS and Android deployment: code signing, screenshot generation, metadata management, and store submission. Even if you use EAS Build for the build step, Fastlane is often still useful for the submission step, especially for teams with complex App Store Connect or Google Play Console workflows.

Fastfile Configuration


Environment Management

Production apps need at least three environments: development (local testing), staging (QA testing against a staging API), and production (real users). Each environment uses different API URLs, analytics keys, feature flags, and possibly different app icons and names (so testers can have both the staging and production builds installed simultaneously). The challenge in React Native is that environment variables need to flow into both the JavaScript bundle and the native build configuration. The workflow below shows how to create environment-specific .env files and pass them through GitHub Actions environment contexts.

Environment-Specific Builds

Secrets Management


Automated Version Management


Monitoring & Notifications

Slack Notifications


CI/CD Platform Comparison

Choosing a CI/CD platform for React Native involves a constraint that web teams do not face: iOS builds require macOS runners. This single requirement eliminates many cheap or self-hosted options and makes cost planning more important. Decision framework:
  1. Using Expo and want simplicity? EAS Build. It handles code signing, provisioning profiles, and native build toolchains. You trade flexibility for dramatically reduced configuration.
  2. Need full native control? GitHub Actions + Fastlane. You manage everything but can customize every step. Best for bare React Native or heavily customized Expo projects.
  3. Budget-constrained? Codemagic’s free tier is the most generous for mobile. Alternatively, self-host Linux runners for Android (free) and use cloud macOS only for iOS.
  4. Enterprise with compliance requirements? Azure DevOps or self-hosted GitHub runners. You keep build artifacts and secrets within your network.

EAS Build vs. Self-Managed Builds

This is the most consequential CI/CD decision for Expo teams. Here is a detailed comparison: My recommendation: Start with EAS Build. When (and if) you hit its limitations — needing custom native build steps, running builds inside your VPN, or exceeding cost thresholds — migrate to self-managed. Most teams never hit those limits.

Edge Cases and Common Failures

iOS Code Signing in CI

This is the single most common CI/CD failure for React Native teams. Code signing involves four pieces that must all align: the signing certificate (.p12), the provisioning profile, the Apple Team ID, and the bundle identifier. If any one is expired, mismatched, or missing, the build fails with a cryptic Xcode error. Common failure scenarios: Prevention strategy: Use Fastlane Match, which stores certs and profiles in a private Git repo or cloud storage (S3, GCS). When certs rotate, update once in Match, and all CI pipelines pick up the change automatically.

Android Keystore Loss

If you lose your Android upload keystore, you cannot publish updates to your existing Play Store listing. Google introduced Play App Signing to mitigate this (Google holds the actual signing key; you hold an upload key), but many teams set up their app before this existed or opted out. Prevention: Store your keystore file in a secure, versioned location (encrypted S3 bucket, 1Password vault). Never rely solely on a CI/CD secret — if the CI provider has an outage, you need to be able to sign locally.

Build Flakiness from Dependency Caching

Stale caches cause the most insidious CI failures: a build that worked yesterday fails today with a “module not found” error, even though no code changed. This happens when a transitive dependency publishes a new version that is incompatible with your lockfile’s resolution, and the cache serves a mix of old and new packages.

GitHub Actions macOS Runner Cost Surprise

GitHub charges macOS minutes at a 10x multiplier. A 20-minute iOS build consumes 200 minutes of your 2,000-minute free allocation. Teams building iOS on every PR exhaust their free tier in a week. Mitigation strategies:
  • Run iOS builds only on pushes to main or develop, not on every PR
  • Use paths filters to skip builds when only docs or config changed
  • Use EAS Build for iOS (runs on Expo’s infrastructure, not your GitHub minutes)
  • Cache aggressively to reduce build time (every minute saved is 10x more valuable on macOS)

Best Practices

Cache Dependencies

Cache node_modules, CocoaPods, and Gradle to speed up builds

Parallel Jobs

Run independent jobs in parallel to reduce total pipeline time

Fail Fast

Run quick checks (lint, typecheck) before expensive builds

Secure Secrets

Use environment-specific secrets and rotate regularly

Pipeline Optimization Checklist


Next Steps

Module 41: App Store Deployment

Learn the complete process of deploying to iOS App Store and Google Play Store