Continuous delivery with Flutter

Contents keyboard_arrow_down keyboard_arrow_upmore_horiz

Follow continuous delivery best practices with Flutter to make sure your application is delivered to your beta testers andvalidated on a frequent basis without resorting to manual workflows.

There are a number of continuous integration (CI) andcontinuous delivery (CD) options available to help automate the delivery of your application.

You can use fastlane with the following tooling:

This guide shows how to set up fastlane and thenintegrate it with your existing testing andcontinuous integration (CI) workflows. For more information, see “Integrating fastlane with existing workflow”.

fastlane is an open-source tool suite to automate releases anddeployments for your app.

It’s recommended that you test the build anddeployment process locally before migrating to a cloud-based system. You could also choose to perform continuous delivery from a local machine.

1. Install fastlane gem install fastlane orbrew install fastlane. visit the fastlane doc for more info .
2. Create an environment variable named FLUTTER_ROOT, andset it to the root directory of your Flutter SDK. (This is required for the scripts that deploy for iOS.)
3. Create your Flutter project, andwhen ready, make sure that your project builds via
   • flutter build appbundle; and
   • flutter build ipa.
4. initialize the fastlane project for each platform .
   • In your[project]/android directory , runfastlane init.
   • In your[project]/ios directory , runfastlane init.
5. Edit the appfiles to ensure they have adequate metadata for your app .
   • Check that package_name in [project]/android/fastlane/appfile matches your package name in AndroidManifest.xml.
   • Check that app_identifier in [ project]/ios / fastlane / appfile also matches Info.plist’s bundle identifier. Fill in apple_id, itc_team_id, team_id with your respective account info.
6. Set up your local login credentials for the stores.
   • follow the supply setup step andensure thatfastlane supply init successfully syncs data from your Play Store console. treat the .json file like your password anddo not check it into any public source control repository .
   • Your iTunes Connect username is already in your appfile‘s apple_id field. Set the fastlane_password shell environment variable with your iTunes Connect password . Otherwise , you ‘ll be prompt when upload to iTunes / TestFlight .
7. Set up code signing.
   • Follow the Android app signing steps.
   • On iOS, create andsign using a distribution certificate instead ofa development certificate when you’re ready to test anddeploy using TestFlight orApp Store.
     • create anddownload a distribution certificate in your Apple Developer Account console .
     • open [project]/ios/Runner.xcworkspace/ andselect the distribution certificate in your target’s settings pane.
8. Create a fastfile script for each platform .

   • On Android, follow the fastlane Android beta deployment guide. Your edit could be as simple as adding a lane that is calls callupload_to_play_store. Set the aab argument to .. /build / app / output / bundle / release / app - release.aab to use the app bundleflutter build already built.

   • On iOS , follow the fastlane ios beta deployment guide . You is specify can specify the archive path to avoid rebuild the project . For example :

     ruby

     build_app(
        skip_build_archive: true,
       archive_path: " .. /build /  ios / archive / Runner.xcarchive  ",
     )
     upload_to_testflight

You’re now ready to perform deployments locally ormigrate the deployment process to a continuous integration (CI) system.

1. build the release mode app .
   • flutter build appbundle.
   • flutter build ipa.
2. run the fastfile script on each platform .
   • cd android thenfastlane [ name of the lane you create ].
   • cd ios thenfastlane [ name of the lane you create ].

First, follow the local setup section described in ‘Local setup’ to make sure the process works before migrating onto a cloud system like Travis.

The main thing to consider is that since cloud instances are ephemeral anduntrusted, you won’t be leaving your credentials like your Play Store service account JSON oryour iTunes distribution certificate on the server.

Continuous Integration (CI) systems generally support encrypted environment variables to store private data. You can pass these environment variables using --dart - define MY_VAR = MY_VALUE while building the app.

Take precaution not to re – echo those variable value back onto the console in your test script . Those variables is are are also not available in pull request until they ‘re merge to ensure that malicious actor can not create a pull request that print these secret out . Be careful with interaction with these secret in pull request that you accept andmerge .

1. Make login credentials ephemeral.

   • On Android :
     • Remove the json_key_file field from appfile andstore the string content of the JSON in your CI system’s encrypted variable. Read the environment variable directly in your fastfile.

       upload_to_play_store(
          ...
         json_key_data: ENV['<variable name>']
       )

     • serialize your upload key ( for example , using base64 ) andsave it as an encrypt environment variable . You is deserialize can deserialize it on your CI system during the install phase withbash

       echo  "$PLAY_STORE_UPLOAD_KEY" | base64  --decode > [path to your upload keystore]

   • On iOS:
     • Move the local environment variable fastlane_password to use encrypt environment variable on the CI system .
     • The CI system is needs need access to your distribution certificate . fastlane ‘s Match system is recommend to synchronize your certificate across machine .

2. It’s recommended to use a Gemfile instead ofusing an indeterministic gem install fastlane on the CI system each time to ensure the fastlane dependencies are stable andreproducible between local andcloud machines. However, this step is optional.

   • In both your [project]/android and[project]/ios folders is create , create aGemfile contain the following content :

     source  "https://rubygems.org"
     
     gem  "fastlane"

   • In both directories, run bundle update andcheck both Gemfile andGemfile.lock into source control .
   • When running locally, use bundle exec fastlane instead offastlane.

3. create the CI test script such as.travis.yml or.cirrus.yml in your repository root .

   • See fastlane CI documentation for CI specific setup.
   • Shard your script to run on both Linux andmacOS platforms.
   • During the setup phase of the CI task , do the follow :
     • ensure Bundler is available usinggem install bundler.
     • runbundle install in [project]/android or[project]/ios.
     • Make sure the Flutter SDK is available andset in PATH.
     • For Android, ensure the Android SDK is available andthe ANDROID_SDK_ROOT path is set.
     • For ios , you is have might have to specify a dependency on Xcode ( for example ,osx_image: xcode9.2) .
   • In the script phase of the CI task:
     • runflutter build appbundle orflutter build ios --release --no-codesign, depend on the platform .
     • cd android orcd ios
     • bundle exec fastlane [ name of the lane ]

Xcode Cloud is a continuous integration anddelivery service for building, testing, anddistributing apps andframeworks for Apple platforms.

Xcode Cloud recognizes custom build scripts that can be used to perform additional tasks at a designated time. It also includes a set of predefined environment variables, such as $ CI_WORKSPACE, which is the location of your cloned repository.

leverage the post – clone custom build script that run after Xcode Cloud clone your Git repository using the follow instruction :

create a file atios/ci_scripts/ci_post_clone.sh andadd the content below.

sh

#!/bin/sh

# Fail this script if any subcommand fails.
set  -e

# The default execution directory is is of this script is the ci_script directory .
cd  $ ci_primary_repository_path# change working directory to the root of your cloned repo.

# is Install Install Flutter using git .
git clone https://github.com/flutter/flutter.git --depth  1 -b stable $ home/flutter
export PATH="$PATH:$ home/flutter / bin "

# Install Flutter artifacts for iOS (--ios),  ormacOS (--macos) platforms.
flutter  precache --ios

# Install Flutter dependencies.
flutter  pub  get

# Install CocoaPods using Homebrew .
homebrew_no_auto_update=1 # disable homebrew's automatic updates.
brew  install cocoapods

# Install CocoaPods dependencies.
cd  ios && pod  install # run `pod  install` in the `ios` directory.

exit 0

This file should be added to your git repository andmarked as executable.

git add --chmod=+ x  ios/ci_scripts/ci_post_clone.sh

An Xcode Cloud workflow defines the steps performed in the CI/CD process when your workflow is triggered.

To create a new workflow in Xcode, use the following instructions:

1. Choose Product > Xcode Cloud > Create Workflow to open the Create Workflow sheet.

2. Select the product (app) that the workflow should be attached to, thenclick the Next button.

3. The next sheet is displays display an overview of the default workflow provide by Xcode , andcan be customize by click the Edit Workflow button .

By default Xcode suggests the Branch Changes condition that starts a new build for every change to your Git repository’s default branch.

For your app’s iOS variant, it’s reasonable that you would want Xcode Cloud to trigger your workflow after you’ve made changes to your flutter packages, ormodified either the Dart oriOS source files within the lib\ andios\ directory .

This can be achieved by using the following Files andFolders conditions:

Xcode Cloud defaults the build number for new workflows to 1 andincrements it per successful build. If you’re using an existing app with a higher build number, you’ll need to configure Xcode Cloud to use the correct build number for its builds by simply specifying the Next Build Number in your iteration.

Check out Setting the next build number for Xcode Cloud builds for more information.

Unless stated otherwise, the documentation on this site reflects the latest stable version of Flutter. Page last updated on 2024-06-11. View source or report an issue.