10 posts tagged with "Deployment"

There’s a moment every mobile team knows: production has a bug, the fix is ready, and now the question is how to ship safely without waiting for app store review.

Over-the-air (OTA) updates solve that for React Native teams. But shipping quickly is only half the story. The teams that ship often and sleep well are the ones with a repeatable OTA workflow.

This guide rewrites the most important OTA practices for a Source Push workflow.

TL;DR checklist​

• Use separate preview and production deployments
• Gate releases with native compatibility checks
• Know exactly what is OTA-safe vs what requires a new binary
• Use in-app update checks for critical fixes
• Roll out gradually and keep rollback fast

1) Test on preview before publishing to production​

The most reliable default flow is:

1. Publish to a preview deployment
2. Validate with QA/internal users
3. Promote to production

# Step 1: publish to preview
srcpush release-react MyApp-Preview \
  --description "Fix login timeout on Android"

# Step 2: validate on preview build

# Step 3: promote validated release to production
srcpush promote MyApp-Preview Preview Production

Why it works:

• You catch integration issues before customer impact
• QA can validate behavior in a controlled audience
• Teams build confidence and release more frequently

If your organization needs stronger controls (audit/compliance), keep a dedicated staging deployment that mirrors production and only promote the exact validated release artifact.

2) Use native compatibility gates before OTA release​

The biggest OTA risk is publishing JavaScript that depends on native changes not present in installed binaries.

In Source Push workflows, establish a native compatibility gate in CI/CD before every OTA publish:

• Detect native dependency or config changes
• If native surface changed, require a new store build
• If native surface is unchanged, allow OTA release

A practical trigger list for “new binary required”:

• React Native version upgrades
• Native module install/upgrade
• iOS/Android permission changes
• App icon/splash/entitlement updates
• Edits in ios/ or android/ projects (bare workflow)

This single guardrail prevents most production OTA incidents.

3) Be explicit about what OTA can and cannot change​

A simple rule keeps teams aligned:

OTA-safe changes​

• JavaScript logic
• UI/layout/style updates
• Text/copy fixes
• Static assets (images/fonts)

Requires new app build​

• Native SDK/module changes
• Platform permission additions
• Native config/plugin changes
• Any change that requires recompiling iOS/Android binaries

When product, QA, and engineering all use this release decision model, delivery becomes faster and far less risky.

4) Deliver critical fixes faster with in-app update checks​

Default OTA behavior is safe for most releases, but critical fixes often need faster adoption.

For urgent patches, implement controlled in-app update checks so users can fetch and apply updates quickly during active sessions (for example, after login or returning to foreground).

Best practices:

• Check once per session (avoid loops)
• Respect network/connectivity state
• Apply updates at safe UX moments
• Reserve forced reload behavior for truly critical incidents

This gives you speed without degrading startup performance for every user.

5) Roll out gradually and practice rollback​

Never treat OTA like an all-or-nothing deployment.

Use staged rollout:

1. Internal testers
2. Small production cohort
3. Wider audience
4. 100% rollout after confidence signals are healthy

Track:

• Crash-free sessions
• Update adoption rate
• Startup latency
• Error spikes by app version/device/OS

If anything regresses, rollback immediately to the previous stable release.

# Example: promote only after health checks pass
srcpush promote MyApp-Production Candidate Production

The operational goal is simple: time-to-rollback should be measured in minutes, not hours.

Final thoughts​

OTA updates are one of the highest-leverage capabilities in React Native delivery. With Source Push, these five habits create a system that is both fast and safe:

• Preview-first validation
• Native compatibility gating
• Clear OTA boundaries
• Intentional in-app update behavior
• Gradual rollout + instant rollback readiness

If your team adopts these as defaults, you can ship continuously with much lower production risk.

B2B mobile app growth is different from consumer app growth.

Your buyers are not discovering your app from viral posts or random app store browsing. They are evaluating risk, rollout effort, security, and measurable ROI before they commit.

At Source Push, we work with teams shipping React Native apps inside real businesses—operations teams, sales teams, field teams, and internal enterprise platforms. Across these rollouts, the same adoption patterns show up again and again.

Here are five proven strategies we recommend if you want stronger B2B adoption.

1) Optimize onboarding for a fast “Aha!” moment​

Most B2B teams lose potential users in the first session, not because the product is weak, but because the first-run experience is overloaded.

What to do​

• Lead with immediate value, not setup friction.
• Ask users to complete one meaningful action in the first few minutes.
• Delay non-essential forms and configuration until after they’ve seen the benefit.

For example, if your app helps field teams file reports, let users create and submit one report quickly before requesting full profile completion.

How Source Push helps​

Use Source Push to iterate onboarding screens weekly without waiting for app-store release cycles. Small UX improvements compound quickly when you can ship and test faster.

2) Build proof assets that help champions sell internally​

In B2B, one person rarely decides alone. Your internal champion needs materials to convince finance, IT, and leadership.

What to do​

Create a lightweight “proof package” for every serious prospect:

• A short case study with baseline vs. outcome metrics
• A simple ROI calculator tied to real workflow savings
• 2–3 customer quotes from similar industries

This shifts conversations from “Is this tool good?” to “How quickly can we roll this out?”

How Source Push helps​

Because you can deploy improvements continuously, you can connect measurable adoption gains (activation rate, retention, task completion) to specific releases and use those numbers in your case studies.

3) Distribute where decision-makers actually spend time​

B2B adoption comes from relevance and trust, not broad reach.

What to do​

• Focus on channels where your buyers already evaluate tools:
  • LinkedIn
  • Industry newsletters
  • Professional communities (Slack, Discord, niche forums)
• Publish educational content tied to specific job outcomes.
• Show examples by role (e.g., operations manager, sales lead, support manager).

Content like “How logistics teams reduce failed deliveries with mobile workflows” usually performs better than generic product announcements.

How Source Push helps​

When your mobile experience improves quickly, your messaging can stay current. You can promote real product progress and concrete before/after outcomes instead of static promises.

4) Run pilots with clear expansion paths​

Most enterprise customers want evidence in their own environment before a full rollout.

What to do​

Design pilot programs intentionally:

• Start with a defined team size and timeframe
• Align on 2–3 success metrics before kickoff
• Schedule weekly check-ins with the customer sponsor
• Prepare expansion pricing and rollout steps early

A successful pilot should naturally convert into a broader deployment, not restart the sales process.

How Source Push helps​

Pilots expose edge cases fast. With Source Push, you can address blockers immediately during the pilot window, which increases confidence and shortens time-to-expansion.

5) Capture high-intent demand with problem-based SEO​

B2B buyers search by problem, role, and industry context.

What to do​

Target long-tail, intent-rich queries such as:

• “mobile app for warehouse inventory audits”
• “field service inspection app for HVAC teams”
• “React Native app update strategy for enterprise users”

Then create pages and app-store copy that match those intents clearly.

How Source Push helps​

As your team ships targeted improvements for specific industries, you can align landing pages and product messaging to each segment, improving conversion quality—not just traffic volume.

Final takeaway​

B2B adoption improves when you reduce risk and prove value early.

If you apply these five strategies consistently, you’ll create a repeatable growth system:

1. Faster time-to-value in onboarding
2. Stronger business-case materials
3. Better channel-to-audience fit
4. Pilot-led expansion motion
5. Higher-intent acquisition from search

And when you combine that strategy with fast, controlled OTA delivery through Source Push, your team can improve activation and retention continuously instead of waiting on slow release cycles.

If you want, we can publish a follow-up with a 30-day adoption playbook and the exact KPI dashboard template we use for Source Push customers.

Manual mobile releases are slow, error-prone, and hard to scale—especially when your team supports multiple apps, channels, and environments.

In this guide, you’ll build a practical CI/CD pipeline using GitHub Actions + Source Push so OTA updates become predictable, auditable, and fast.

Why automate OTA delivery?​

When releases depend on local machines, teams often face:

• Inconsistent environments
• Credential sprawl
• Missing release history
• Slow rollback and promotion workflows

A GitHub Actions pipeline solves this by centralizing execution and secrets, while Source Push handles channel-based delivery.

What we’re building​

A pipeline with three stages:

1. Validate: run tests/lint checks.
2. Release to Staging: publish OTA update to a staging channel.
3. Promote to Production: manually approve promotion when validation succeeds.

This gives you speed and control.

Prerequisites​

Before you start, make sure you have:

• A React Native project configured for Source Push
• Source Push app/channels created (for example: Staging, Production)
• A CI token stored in GitHub Secrets (for example: SOURCE_PUSH_TOKEN)
• Optional: app name in secrets (SOURCE_PUSH_APP)

Step 1: Add CI secrets in GitHub​

In your GitHub repository, go to Settings → Secrets and variables → Actions, and add:

• SOURCE_PUSH_TOKEN: token for Source Push CLI authentication
• SOURCE_PUSH_APP: Source Push app identifier (optional but recommended)

Keep channel names as workflow inputs or repository variables so they’re easier to change later.

Step 2: Create the GitHub Actions workflow​

Create .github/workflows/mobile-ota.yml:

name: Mobile OTA CI/CD

on:
  workflow_dispatch:
    inputs:
      target_channel:
        description: "Target release channel"
        required: true
        default: "Staging"
      description:
        description: "Release notes"
        required: true
        default: "OTA update from CI"

jobs:
  validate:
    name: Validate
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test -- --passWithNoTests

  release_staging:
    name: Release OTA
    runs-on: ubuntu-latest
    needs: validate
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Install Source Push CLI
        run: npm install -g source-push-cli

      - name: Source Push Login
        run: srcpush login --token "${{ secrets.SOURCE_PUSH_TOKEN }}"

      - name: Release React Native OTA
        run: |
          srcpush release-react "${{ secrets.SOURCE_PUSH_APP }}" \
            --deployment "${{ github.event.inputs.target_channel }}" \
            --description "${{ github.event.inputs.description }}"

  promote_production:
    name: Promote to Production
    runs-on: ubuntu-latest
    needs: release_staging
    if: ${{ github.event.inputs.target_channel == 'Staging' }}
    environment: production
    steps:
      - name: Install Source Push CLI
        run: npm install -g source-push-cli

      - name: Source Push Login
        run: srcpush login --token "${{ secrets.SOURCE_PUSH_TOKEN }}"

      - name: Promote Staging to Production
        run: |
          srcpush promote "${{ secrets.SOURCE_PUSH_APP }}" Staging Production

Step 3: Protect production with environment approvals​

Use GitHub Environments so production promotion requires explicit approval:

1. Go to Settings → Environments → New environment
2. Create production
3. Add required reviewers
4. (Optional) Add environment-scoped secrets

Now your pipeline can auto-release to staging while keeping a human checkpoint for production.

Step 4: Add branch-based automation (optional)​

You can trigger staging releases on main pushes and keep production as manual approval:

on:
  push:
    branches: [main]
  workflow_dispatch:

A common pattern:

• push to main → release to Staging
• Manual approval in production environment → promote to Production

Operational best practices​

To make this reliable at scale:

• Use small, frequent OTA updates
• Include clear release descriptions tied to commit SHA
• Keep rollback commands documented and tested
• Restrict token scope and rotate credentials
• Track adoption/health metrics before production promotion

Fast rollback pattern​

If production metrics degrade, rollback should be one command away:

srcpush rollback MyApp Production

You can also automate rollback by integrating monitoring alerts into a follow-up workflow.

Final thoughts​

CI/CD for mobile OTA updates is less about “more tooling” and more about reducing operational risk.

With GitHub Actions and Source Push, your team gets:

• Repeatable releases
• Better governance
• Faster incident response
• A deploy process that scales as your app portfolio grows

Start with one app and two channels (Staging and Production). Once stable, templatize the workflow and roll it out across every mobile project.

If you read Expo’s recent post about OneSpot automating OTA publishing at massive scale, you already know the core idea: stop deploying app-by-app from a laptop, and turn releases into a system.

This is our version of that same playbook—rebuilt for a Source Push workflow.

The scenario​

We run a white-label React Native platform where every customer has their own branded app:

• Unique app name and icon
• Unique bundle/package identifiers
• Dedicated release channels
• Shared core codebase

That architecture is great for product velocity, but painful for operations when updates are manual.

Without automation, even a tiny fix can mean repeating the same deployment flow hundreds of times.

The bottleneck we had to remove​

Our old OTA flow looked like this:

1. Select one app
2. Update local config manually
3. Run release commands from a developer laptop
4. Validate
5. Repeat for the next app

At 20+ apps, this turns into hours of repetitive operational work and high risk of human error.

The key shift: treat app targeting as data​

Instead of hardcoding per-app settings, we moved every variable into a central app registry (JSON).

Each app record includes:

• Brand name and slug
• iOS bundle ID / Android package
• Source Push app key and channel mapping
• Asset set references
• Runtime version and rollout metadata

Now “deploy this app” is just: load app config from data + run pipeline.

Our Source Push automation architecture​

1) Config generation layer​

A script takes one app ID (or many) and generates runtime config files for that target app set.

2) Release execution layer​

The same script calls Source Push CLI commands non-interactively.

# Example single-app OTA release
srcpush release-react SchoolApp-Production \
  --description "Fix session timeout handling"

# Example promotion flow
srcpush promote SchoolApp-Production Staging Production

3) CI runner (not local machine)​

All releases run in CI (GitHub Actions in our case), not on any engineer’s laptop. That gives us:

• Repeatable execution environment
• Centralized secrets handling
• Full audit trail for every deployment
• Safer rollback and retry behavior

4) Remote trigger interface​

We expose a secure internal endpoint that triggers deployment jobs. From an ops dashboard (or even mobile admin UI), authorized teammates can trigger:

• Publish one app
• Publish a segment (for example, all K-12 customers)
• Promote validated releases across channels

Guardrails that made this reliable​

At this scale, speed without control is dangerous. We added guardrails from day one:

• Channel-based rollout: Internal → Beta → Production
• Automated checks: block promotion on failed health metrics
• Scoped credentials: least privilege for CI tokens
• Deterministic artifacts: generated config committed/traceable per run
• Instant rollback paths: fast channel re-pointing when needed

What changed after implementation​

Faster hotfix velocity​

Critical fixes can be pushed across the fleet in minutes, not hours.

Lower operational load​

Engineering stopped spending release windows on repetitive command execution.

More consistent deployments​

Centralized, scripted runs eliminated machine-specific drift and “works on my laptop” failures.

Better confidence at scale​

Because every release follows the same pipeline, the process is predictable even when fleet size grows.

If you want to replicate this pattern​

Start simple:

1. Build a single source of truth for per-app metadata.
2. Generate app config from data, not manual edits.
3. Run Source Push releases from CI only.
4. Add staged promotion and rollback automation.
5. Add a secure API trigger once core flow is stable.

The big idea is straightforward: OTA at white-label scale is a systems problem, not a terminal command problem.

Once you model deployments as data + automation, shipping to 20 apps can feel almost as simple as shipping to one.

If you loved the idea of shipping smaller OTA updates from the Expo ecosystem, you'll love what this means in a Source Push workflow too.

Today, we’re introducing Bundle Diffing for OTA updates in Source Push scenarios—so you can deliver only what changed, not the entire JavaScript bundle, and reduce update payload size dramatically.

Why this matters​

Traditional OTA updates often send a full bundle, even when you changed only a few files.

That leads to:

• Slower update downloads for end users
• Higher bandwidth and CDN costs
• More friction on unstable or low-bandwidth connections

With bundle diffing, Source Push can publish a compact patch between versions, helping apps update faster while consuming less data.

How Bundle Diffing works in our scenario​

In a Source Push release flow, bundle diffing compares:

1. The user’s currently installed OTA bundle
2. The new bundle generated in your latest release

If Source Push finds a valid baseline, it serves a delta package containing only changed modules and metadata. If no valid baseline exists (for example, first install or cache miss), Source Push safely falls back to the full bundle.

This gives you the best of both worlds:

• Small updates whenever possible
• Reliable full updates when necessary

What teams can expect​

Smaller payloads​

Most real-world releases include minor fixes, content tweaks, or feature flags. Diffing turns those into lightweight updates.

Faster time-to-ready​

Users spend less time waiting for updates to download and apply.

Better global performance​

In regions with slower networks, smaller payloads can meaningfully improve update success rates.

Lower infrastructure cost​

Sending less data per release reduces the total bandwidth footprint of frequent OTA deployments.

Ideal use cases​

Bundle diffing is especially useful if your team:

• Ships OTA updates multiple times per week
• Supports users on constrained networks
• Needs quick hotfix rollouts with minimal payload overhead
• Wants efficient CI/CD-driven React Native release pipelines

Rollout strategy recommendation​

To get the best results, roll out in stages:

1. Start with your internal or beta deployment channel
2. Monitor update success and apply latency
3. Expand gradually to production channels
4. Keep full-bundle fallback enabled for reliability

Example release flow​

# Create and publish an OTA release
srcpush release-react MyApp-Production \
  --description "Fix crash in checkout flow"

# Promote when validated
srcpush promote MyApp-Production Staging Production

When diffing is available for the target baseline, users receive the smaller delta package automatically.

Final thoughts​

Bundle diffing is a simple idea with big impact: ship less, deliver faster.

For Source Push teams, this means every hotfix and iterative release can feel lighter for your users and cheaper for your platform.

If you’re already practicing rapid OTA delivery, bundle diffing is the next step to make that workflow even more efficient.

Source Push can deliver React Native OTA updates in minutes.

That speed is powerful—but in production, the safest teams control exposure just as much as they optimize velocity.

This playbook shows a practical way to run Source Push updates in production: staged rollouts, signal-driven monitoring, and fast recovery when an update underperforms.

Ship small on purpose​

In production, “small” usually means small blast radius.

Instead of pushing a new OTA update to everyone at once, start with a limited cohort (for example internal users, beta deployment, or a small production segment). This gives you real-world signals without exposing your entire user base.

A staged rollout helps you:

• Limit customer impact if something breaks
• Validate behavior on real devices and real network conditions
• Make rollout decisions with production data instead of guesswork

Observe the rollout in real time​

After publishing to a limited audience, focus on three signals first.

1) Adoption and update velocity​

Check whether users are actually receiving and applying the update.

If adoption is lower than expected, common causes include:

• Users not reopening the app frequently
• Deployment targeting that doesn’t match the installed app population
• Runtime/build compatibility mismatches between update and binaries

2) Crashes and fatal errors​

Early crashes are the strongest indicator that a rollout should pause.

Use Source Push telemetry plus your crash tool (Sentry, Firebase Crashlytics, etc.) to correlate update IDs with stack traces, affected sessions, and device segments.

3) Trend quality over point anomalies​

Small cohorts are noisy. Avoid overreacting to a single spike.

Look for directional trends as exposure grows:

• Are crash rates stable, improving, or degrading?
• Are failures concentrated in specific OS versions or device classes?
• Does startup reliability change after update adoption increases?

Expand safely in steps​

When metrics are healthy, increase rollout size gradually.

A simple progression might be:

1. Internal QA
2. 5% production
3. 20% production
4. 50% production
5. 100% production

At each step, keep a short observation window before expanding again.

This gives your team clear decision gates and prevents “silent failures” from instantly becoming global incidents.

Recovery options: revert vs rollback​

When a rollout is still in progress, the fastest move is usually to revert the active rollout.

When an update has already reached most or all users, move to a rollback strategy that routes clients back to the last known-good release.

Use this rule of thumb:

• Revert when exposure is still limited and you want to halt spread immediately
• Rollback when the bad update is already broadly adopted

Plan for state compatibility before shipping​

Rollbacks are only safe if older code can still read state written by newer code.

Before high-risk OTA releases, validate compatibility for:

• Local database schema changes
• Persisted storage keys and value formats
• Feature-flag defaults and migration scripts

If compatibility is not guaranteed, prepare a forward-fix OTA update instead of reverting to older logic.

Example Source Push workflow​

# Publish to staging first
srcpush release-react MyApp-Staging \
  --description "Checkout reliability improvements"

# Promote gradually after validation
srcpush promote MyApp-Staging Staging Production

You can combine this with your CI pipeline to automatically publish to staging, run smoke checks, then require manual approval for production promotion.

Operational checklist​

Before each production OTA release:

• Confirm deployment targeting and runtime compatibility
• Publish to staging and run smoke tests
• Start with limited production exposure
• Monitor adoption, crash rate, and startup health
• Expand in controlled steps
• Keep revert/rollback runbooks ready

Final thoughts​

Shipping fast and shipping safely are not opposites.

With Source Push, you can move quickly and stay in control by introducing updates gradually, watching real signals, and reacting decisively when needed.

That’s the core production habit: small rollouts, clear signals, confident recovery.

Source Push integrates with your existing CI/CD tools to automate OTA releases. A typical pipeline might look like this:

# Build your app
npm run build

# Release to staging
srcpush release MyApp Staging ./build --description "Staging build"

# Promote to production after tests pass
srcpush promote MyApp Staging Production

This workflow ensures your updates are tested and approved before reaching end users.

When you're ready to move from testing to production, Source Push simplifies the process. Make sure to:

1. Use separate Staging and Production deployments
2. Test updates thoroughly in staging
3. Monitor metrics closely after the first production release

Following these steps helps ensure a smooth experience for your users when you switch to OTA updates with Source Push.

Even with thorough testing, issues can slip into production. Source Push provides easy rollback commands so you can revert to a previous release:

srcpush release rollback MyApp Production

You can also configure automatic rollbacks based on crash thresholds or custom metrics, giving your team peace of mind when shipping updates.

Deploying updates to your React Native app requires careful planning and execution. In this guide, we'll explore different deployment strategies available with Source Push and when to use them.

Understanding Deployment Environments​

Source Push supports multiple deployment environments out of the box:

# Create staging and production deployments
srcpush deployment add MyApp Staging
srcpush deployment add MyApp Production

This allows you to test updates before rolling them out to all users.

Staged Rollouts​

Staged rollouts help minimize the impact of potential issues by gradually releasing updates to users:

# Release to 25% of users initially
srcpush release-react MyApp ios --rollout 25

# Once confident, increase to 100%
srcpush deployment history MyApp Production
srcpush rollout MyApp Production v5 100

A/B Testing​

Test different versions of your app with specific user segments:

# Release version A
srcpush release-react MyApp ios -d Production-A

# Release version B
srcpush release-react MyApp ios -d Production-B

Automatic Rollbacks​

Source Push includes automatic rollback protection:

srcpush release-react MyApp ios --rollback-enabled true

This will automatically roll back if an update causes crashes above your defined threshold.

Best Practices​

1. Always Test in Staging

   srcpush release-react MyApp ios -d Staging
   # Verify in staging before promoting
   srcpush promote MyApp Staging Production
   

2. Monitor Update Metrics

   • Track download success rates
   • Monitor crash reports
   • Watch adoption rates

3. Version Targeting

   srcpush release-react MyApp ios --target-binary-version "~1.2.3"
   

4. Emergency Updates

   srcpush release-react MyApp ios --mandatory true
   

CI/CD Integration​

Automate your deployments with our CI/CD integrations:

# GitHub Actions example
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install Source Push CLI
        run: npm install -g @srcpush/code-push-cli
      - name: Release Update
        run: srcpush release-react MyApp ios -d Staging
        env:
          SRCPUSH_TOKEN: ${{ secrets.SRCPUSH_TOKEN }}

Monitoring Deployments​

Keep track of your deployments using our monitoring tools:

# Check deployment history
srcpush deployment history MyApp Production

# View specific deployment details
srcpush deployment info MyApp Production

Conclusion​

Effective deployment strategies are crucial for maintaining app stability and user satisfaction. Source Push provides all the tools you need to implement sophisticated deployment workflows that match your team's needs.

For more detailed information, check out our deployment documentation and CI/CD integration guides.