Example CI/CD workflows
Edit this page
Common CI/CD workflows that are useful for your project.
The following workflows are examples of how you can use EAS Workflows to automate your development and release processes. They can help you and your team develop, review each other's PRs, and release changes to your users.
Development builds workflow
Development builds are specialized builds of your project that include Expo's developer tools. These types of builds include all native dependencies inside your project, enabling you to run a production-like build of your project on a simulator, emulator, or a physical device.
2 requirements
2 requirements
1.
Set up your environment
To get started, you'll need to configure your project and devices to build and run development builds. Learn how to set up your environment for development builds with the following guides:
Get your project ready for development builds.
Get your project ready for development builds.
Get your project ready for development builds.
Get your project ready for development builds.
2.
Create build profiles
After you've configured your project and devices, add the following build profiles to your eas.json file.
{
"build": {
"development": {
"developmentClient": true,
"distribution": "internal"
},
"development-simulator": {
"developmentClient": true,
"distribution": "internal",
"ios": {
"simulator": true
}
}
}
}
The following workflow creates a build for each platform and for both physical devices, Android emulators, and iOS simulators. They all will run in parallel.
name: Create development builds
jobs:
android_development_build:
name: Build Android
type: build
params:
platform: android
profile: development
ios_device_development_build:
name: Build iOS device
type: build
params:
platform: ios
profile: development
ios_simulator_development_build:
name: Build iOS simulator
type: build
params:
platform: ios
profile: development-simulator
Run the above workflow with:
-
eas workflow:run .eas/workflows/create-development-builds.yml
Preview updates workflow
Once you've made changes to your project, you can share a preview of your changes with your team by publishing a preview update.
You can access preview updates in the development build UI and through scannable QR codes on the Expo dashboard. When publishing a preview on every commit, your team can review changes without pulling the latest changes and running them locally.
2 requirements
2 requirements
1.
Set up EAS Update
Your project needs to have EAS Update setup to publish preview updates. You can set up your project with:
-
eas update:configure
2.
Create new development builds
After you've configured your project, create new development builds for each platform.
The following workflow publishes a preview update for every commit on every branch.
name: Publish preview update
on:
push:
branches: ['*']
jobs:
publish_preview_update:
name: Publish preview update
type: update
params:
branch: ${{ github.ref_name || 'test' }}
Deploy to production workflow
When you're ready to deliver changes to your users, you can build and submit to the app stores or you can send an over-the-air update. The following workflow detects if you need new builds, and if so, it sends them to the app stores. If new builds are not required, it will send an over-the-air update.
3 requirements
3 requirements
1.
Set up EAS Build
To set up EAS Build, follow this guide:
Get your project ready for EAS Build.
2.
Set up EAS Submit
To set up EAS Submit, follow the Google Play Store and Apple App Store submissions guides:
Get your project ready for Apple App Store submissions.
Get your project ready for Google Play Store submissions.
3.
Set up EAS Update
And finally, you'll need to set up EAS Update, which you can do with:
-
eas update:configure
The following workflow runs on each push to the main
branch and performs the following:
- Takes a hash of the native characteristics of the project using Expo Fingerprint.
- Checks if a build already exists for the fingerprint.
- If a build does not exist, it will build the project and submit it to the app stores.
- If a build exists, it will send an over-the-air update.
name: Deploy to production
on:
push:
branches: ['main']
jobs:
fingerprint:
name: Fingerprint
type: fingerprint
get_android_build:
name: Check for existing android build
needs: [fingerprint]
type: get-build
params:
fingerprint_hash: ${{ needs.fingerprint.outputs.android_fingerprint_hash }}
profile: production
get_ios_build:
name: Check for existing ios build
needs: [fingerprint]
type: get-build
params:
fingerprint_hash: ${{ needs.fingerprint.outputs.ios_fingerprint_hash }}
profile: production
build_android:
name: Build Android
needs: [get_android_build]
if: ${{ !needs.get_android_build.outputs.build_id }}
type: build
params:
platform: android
profile: production
build_ios:
name: Build iOS
needs: [get_ios_build]
if: ${{ !needs.get_ios_build.outputs.build_id }}
type: build
params:
platform: ios
profile: production
submit_android_build:
name: Submit Android Build
needs: [build_android]
type: submit
params:
build_id: ${{ needs.build_android.outputs.build_id }}
submit_ios_build:
name: Submit iOS Build
needs: [build_ios]
type: submit
params:
build_id: ${{ needs.build_ios.outputs.build_id }}
publish_android_update:
name: Publish Android update
needs: [get_android_build]
if: ${{ needs.get_android_build.outputs.build_id }}
type: update
params:
branch: production
platform: android
publish_ios_update:
name: Publish iOS update
needs: [get_ios_build]
if: ${{ needs.get_ios_build.outputs.build_id }}
type: update
params:
branch: production
platform: ios