search

mobileappdevhm20 / team-project-team_7

team-project-team_7 created by GitHub Classroom
0 stars 0 forks source link

Add Codemagic as CI/CD Pipeline #22

Closed devtobi closed 4 years ago

devtobi commented 4 years ago

CodeMagic should be used for CI/CD Pipelines

devtobi commented 4 years ago

@mobileappdevhm20/team_7 I did some research on the Codemagic Pipeline now. And my solution would be the following 3 pipelines (workflows):

1) feature*-branches - Only analyzing linter errors and running tests on Android 2) develop-branch - Additional to 1: Debug build for Android platform, Push a pre-release to GitHub releases 3) master-branch - Additional to 1: Release build for Android platform, Push a release to GitHub releases, Signing with a release key.

All pipelines use dependency caching which leads to faster pipeline builds. We could set up the same 3 pipelines for the iOS environment as well, but since we only have 500 build minutes per month (at least in the free version) I personally would not do that.

Flutter has so called Driver Tests which are the equivalent to Integration Tests. We could use those tests in addition to normal Unit/Widget tests. The driver tests could then be run on single devices or a whole AWS device farm. If we use driver tests for which branches should I enable them?

I still have to do some research on the following things and will update this comment once done:

So far what do you think about the following?

  1. Use iOS workflows on top of Android workflows or not? (that means building for iOS or not)
  2. Use driver tests? And if yes on which branches?

UPDATE 23.05.2020: I added automated build versioning to the build process. For each build name in pubspec.yml will be increased by one in patch number (1.0.0 -> 1.0.1) Also the build number will be increased by 1. The version number could then be extracted by a package like "package_info" in order to extract it and e.g. display it in the app.

I also enabled driver tests for develop and master branch and added the required dependencies. Driver tests will be put in a folder called 'test_driver' inside project root. The executed file will be called main.dart (inside test_driver)

I added a custom script for adding git tags equivalent to the current version as well.

UPDATE 24.05.2020 After doing some research on code signing, I decided to only sign with a custom signing key in the master workflow. If a new release is built, some setup environment variables for the keystore and an RSA keypair are used to sign the application properly (I provided a signing key with my name in it for that case). If a debug build is made on the develop branch the standard flutter debug keys will be used and thus the application will not be executable on own devices as far as I know. Debug builds from the CI still can be run on the Android Simulator. I also modified the build.gradle file in order to use the CI environment variables if available for the code signing process. Release builds cannot be signed locally, only in CI for now.

UPDATE 24.05.2020 - 2 After testing out the pipeline I realised that we kind of run into a infinite loop now. In order to deploy Artifacts to GitHub releases, the workflow has to listen on tag creation web hooks in GitHub. But since the workflow itself creates tags 2 workflows get called (master and develop) on top of the already running workflow. I had to disable pushing built artefacts to GitHub on tag creation. The workflows now create Releases in GitHub automatically, but they only have the source code attached to them. Its not a perfect solution, but might be enough for our use-case.

m1n1 commented 4 years ago

I would leave iOS out for now and enable it maybe later. The app first needs to be optimized for iOS and I think builds would be failing right now.

Im onboard with the driver tests.