What is CI and why do we need it? You as a user develop and come up with a Flutter app on your local environment, making the app fully functional on your environment. But what about other environments? We don't know.
Okay, so imagine, we upload our Flutter app on to GitHub and then clone the same repo on a different machine and run our app there. There are chances that your app might not run/come up with multiple breakages and weak links, especially with Flutter which is cross-platform development. So, how do we make our apps run perfectly in all sorts of environments?
That's where CI/CD comes in.
CI/CD(Continous Integration, Continous Deployment)
CI/CD is used to bridge the gap between development and operation using automation to build, test, and deploy applications. Hence, making our lives easier with simpler workflows. Now there are tons of tools we can use to perform a simple CI/CD where your app is tested in a completely different environment and you can see where the breakage is so that you can simply just go ahead and fix it.
Some best CI/CD tools are:
- Jenkins
- Circle CI
- Azure CI/CD
- Travis CI
- GitLab
- Codemagic
- Team City by Jet Brains
There are very many more tools out there, but the above are some of my favorite tools out there, and I personally prefer Codemagic out of all.
Travis CI
Travis CI is a simple CI/CD tool that is used to build apps hosted on GitHub and Bitbucket just like almost all the other CI/CD tools.
Getting started
- Create a Flutter App and push it to your Git repository.
- Go to Travis CI and log in with GitHub
- Give access to all repositories or only the select ones, depending on the user's wish.
- Now select your Flutter app repo, where you would like to proceed with CI/CD testing.
- Navigate back to your code on your local machine an create a
.travis.yml
file in your project root and add the following code and push it to your git repo.
os:
- linux
sudo: false
addons:
apt:
sources:
- ubuntu-toolchain-r-test
packages:
- libstdc++6
- fonts-droid-fallback
before_script:
- git clone https://github.com/flutter/flutter.git -b beta
- ./flutter/bin/flutter doctor
script:
- ./flutter/bin/flutter test
cache:
directories:
- $HOME/.pub-cache
Now, let's see what exactly your .yml file is doing.
We are choosing our Operating System as Linux and installing packages libstdc++6
and fonts-droid-fallback
because Flutter is dependent on these packages. In our sources, we need to mention ubuntu-toolchain-r-test
to get the correct version of libstdc++6. We have 2 types of scripts to run here, once our environment is set up, one is before_script
and the other is script
. As, the name suggests before_script
is executed before executing the main script, which involves installing of Flutter from GitHub on to the test platform and running flutter doctor
to test if Flutter runs fine. After this your program is run with the command flutter test
and if your project runs without any errors then congrats! It works fine on all environments, but if it fails, you can check your error and fix it on your local machine.
Once Travis CI detects a .travis.yml
file in your repo, it begins the CI as per the .yml
file. Also, anytime you make a new commit to your repo, Travis CI automatically begins another CI test, without you having to manually run it.
It's that easy and simple to use Travis CI and also you can update your build status on your repo by adding the badge from Travis CI on your README file.
Top comments (5)
Thanks for the post! Just starting to automate my packaging with Flutter and this will be very helpful!
Good luck with the automation π
this is only useful for the tests written.
That's right! For builds, you can use Codemagic.
Thanks a lot