Fledge: A CI/CD Tool For Flutter

Maurice McCabe
Zero Equals False
Published in
8 min readJan 29, 2019

--

Managing an app, after it is first ready for release, is like fighting a dragon that gets stronger every time you attack it. It’s really just the beginning of a list of repetitive tasks that keeps getting longer and longer.

Development environments are not suited to managing these tasks. Developers are therefore forced to step outside of their familiar environment to tackle this growing list of tasks.

Don’t go out there alone!

Here be dragons!

Outside of the safe, familiar confines of the development environment, exists a dangerous and unpredictable world. You don’t want to find yourself out there unprepared! … (hang in there for the good news below 🤓👍)

There are many common set-up and repetitive tasks involved in delivering a mobile app. Every developer goes thru some variation of a core set of tasks. It’s almost like a rite of passage.

No matter if you are a native or hybrid developer, we all have to create screenshots, deal with signing, upload to one, or the other, or both, Apple and Google stores and navigate each store’s respective beta testing and release tracks… And that’s like the minimum number of tasks.

For the more adventurous, there are tasks related to unit tests, integration tests, regression testing, beta testing, A/B tests, monitoring/analytics… the list goes on.

Then there are tasks related to new features, bug fixing, repeated uploads to beta testers and releases to users, and version control of the resulting source code.

It’s like a snake eating it’s own tail!

Then there are the native platform-specific versions of these tasks (which is especially relevant to native developers).

Add to that the fact that each of these tasks often cascade into other tasks and inter-relate in sometimes unanticipated ways.

Before you know it, the tasks look endless.

There’s no avoiding it.

Throw me a pipeline!

As these tasks accumulate, the obvious option is to organize these tasks into a cascading pipeline of tasks. The idea is that if you automate the task once and plug it into a pipeline, you shouldn’t have to worry about it again. When the code changes a new pipeline is created and all the tasks run automatically. Great!

What’s in a pipeline?

Since new pipelines are created frequently, an important responsibility of pipelines is to be consistent and reproducible. For example, a pipeline should be able to instantiate the exact build environment and ideally a collection of either real or emulated devices. It should deal with signing… automatically. It should have automated, and secure, access to the Google and Apple stores to fire-off beta tests and releases. The build artifact used in beta testing should be the same artifact that is delivered to the users… exactly the same artifact . Finally, the delivered app should be traceable back to the version of the source code that gave rise to the updated app.

What’s a good CI/CD solution for Flutter?

Automating these core tasks in a pipeline has many obvious advantages. But building a CICD (Continuous Integration/Continuous Delivery) solution that works out-of-the-box, to meet the needs of all possible apps, may be a bit of a stretch.

Some build-server vendors can attempt to automate some of the tasks, which is well and good. But eventually you have to bite-the-bullet and automate in a vendor-independent way. Hence tools like Fastlane.

With that in mind, a somewhat simplified approach to CICD can be a good fit for Flutter.

Fledge: A simplified CICD tool for Flutter

Wikimedia Commons

Introducing Fledge — a simplified CICD tool for Flutter!

Fledge creates and manages your pipelines for Flutter apps, so you don’t have to. It takes care of the core tasks involved in getting the product of your latest code into users hands… and then some,… automatically.

To make it easy to get started with automation, Fledge implements two simple workflows. The beta workflow and the release workflow.

These workflows can be customized and new workflows can be created as required.

What’s the big idea?

The idea behind Fledge is simple:

  1. A code-change should automatically make it to the user with as few manually-gated steps as necessary.
  2. It should be easy to plug your app into Fledge.
    Fortunately, because builds and tests work cross-platform and a Flutter project includes all the unit and integration tests, adding a Flutter project to Fledge is easy.
  3. Fledge should ideally work with most build servers, in-cloud and in-house (Travis, Cirrus, GitLab, Jenkins, etc…). Currently Travis and in-house GitLab build servers are supported.
  4. It should be easy to add new tasks, like running a new integration test, or auto-generating screenshots, etc…
  5. And finally, it should be customizable (for those apps that need it).
    You can use the Fledge-delivered Fastlane files for customization. (Fledge is a convenience layer between you and some smart Fastlane files, auto-installed by Fledge, that were designed for the workflows implemented by Fledge).

How does it work?

Here’s how it works:

  1. There are two managed branches: master and dev.
    The master branch is the final repository for all code and is managed by Fledge. You never have to touch the master branch. The dev branch is where code get’s checked-in (from other branches, pull requests, or directly to the dev branch).
  2. There is a command for adding the app to Fledge.
    The fledge config command simply copies the selected build server’s (Travis, Cirrus, GitLab, Jenkins, etc…) pre-configured config file and the Fastlane files from the Fledge package to the app’s project.
  3. There is a simple command for managing each CICD workflow.
    A. The fledge beta command starts a new pipeline.
    It tags the source code in the remote repo, triggers the build server to build and sign the apps, and releases the build artifacts to your beta testers (since we all do beta testing… right?) via both store consoles. You can start as many beta pipelines’s as you want… until you have a successful beta and are ready for release.
    B. The fledge release command releases the build artifacts.
    It merges the tagged source from the dev branch to the master branch in the remote repo. This triggers the build server to promote the build artifacts from the latest (successful) beta-test to release in both stores.

That’s it!

Automated!

On a day-to-day basis, the only occasion you need to step outside your development environment is to fire-off a simple Fledge command to either start beta-testing, or to release the latest (successful) beta build-artifacts to users. You don’t even need to go to the Google or Apple store consoles (… unless you want to manage beta testers, etc…). It’s completely automated!

While running, Fledge manages details about each pipeline behind the scenes. For example, Fledge ensures the version name and build number are embedded in each build artifact. This enables tracing-back from any version of the app running on any device to the corresponding version of the source code (see below for details).

Fledge documentation

As with any mobile app, there are several one-time setup tasks (most of which you have to do anyway… even without a CICD tool).

To avoid having to gather together all the bits and pieces of information required to deliver a Flutter app, the Fledge project has created complete documentation to walk you thru all the setup tasks for the more common scenarios.

Click to view documentation!

Let’s see it in action!

You can find the source code of a working example of an app, delivered by a Fledge pipeline, to both the Apple and Google stores here:

You can find sample logs for a fledge beta command here, and a fledge release command here.

Next, download the Fledge demo app onto your iOS or android device:

Click to go to App Store
Click to go to Play Store

and select the ‘About’ feature by touching the app title ‘GitErDone’:

An app auto-delivered, from source code to android users, by Fledge!
An app auto-delivered, from source code to iOS users, by Fledge!

It shows the ‘App Version’ and ‘Build Number’ for this particular installation of the app on your particular device. Using these values we can trace-back to the exact related source code and pipeline:

  1. The App Version is the git tag. You can find the version of the source code tagged with ‘0.0.22’ here.
  2. The Build Number is the pipeline number used to build this version of the app. You can find pipeline #54 here.
Pipeline #54 (click for live version!)

As a bonus, the version name and build number are the same on both iOS and android apps!

As an additional bonus, you don’t need to develop Flutter on a Mac. Fledge builds and signs your app for both iOS and android. So you get builds on a Mac thrown in for free! (For those curious, see the first job in pipeline #54 above for details of a working example of an iOS build on a Mac with signing.)

How do I get it?

You can find Fledge, together with documentation and source code, in the Dart package repository. Complete instructions are provided to walk you thru the one-time setup steps, for a new or existing app, and how to run pipelines:

A companion package is also available, with source code, for auto-generating screenshots (see related article):

Conclusion

Establishing a CICD solution for mobile projects is an obvious choice. The automation of repetitive and increasingly numerous tasks is a huge advantage to any programmer. Fledge provides a reliable and secure CICD solution tailored to your Flutter projects that takes care of these tasks.

Finally…

Let me know if you have any questions or comments about Fledge and how you can use it to automate your Flutter project, below or on GitHub or Twitter.

If you think this article is interesting, you can find more related articles here.

--

--