I cheated. I wanted to have a snappy title, so if you are expecting me to bash fastlane I have to disappoint you. Fastlane is not the road to hell, quite the opposite…
is a command line wrapper for a number of scripts that help you automate your build. It allows you to build and deploy your mobile app. It integrates into your team communication or task management systems and you can even record screenshots from your ui tests
shouldn’t I just write all those scripts myself? I know gradle? Fastlane is stable, easy to use, it performs well and is easy to extend. But most of all, it is already there! You can spend your time doing sth cool.
point more clear I would like to take you on a journey into the past I started my first job in 2011 as an android developer. I was their one man android army. After a couple of month of programming we were able to push our app to market. I loved my job but I dreaded releases one of the reasons was that we had a waterfall process and our QA team only checked the app directly before the release. So when I was done with my tasks, I would push my changes and I would manually start a build on our ci server server. It was still ant and terribly slow. The whole thing took about 15 minutes. when I started the build, it would be the first time that I would build the current state of the app with proguard, sometimes the app would not compile because I messed up proguard config, sometimes the build failed for other reasons and I would have to fix the issue and start over again waiting for next 15 minutes on a friday 8 p.m. When I had the artifact I would im the QA team send them the link to the artifact. They would test for about 30 min and they would always find some defects, some small behaviour that was never specified. remember this is 2011, my first job, no separation of concerns, so no junit tests, and there was no robolectric yet Anyway I would have to fix the issue and start the 15 min build again. send the link of the artifact again and yes I also managed to send the wrong link once or twice. But when I did get the green light I would upload the apk and finally press submit, but … this sometimes also failed because I might have forgotten to update apps versioncode in the Manifest
should have tried to create an artifact before releases. Thats like the first rule of continuous delivery, make sure that you can release your master branch at any time
never tested before release next tests, if I had written and run more tests if the qa team had tested the app more frequently then the number of defects found before release would have been much lower
distribution app was never tested before release if had something like hockey or google alpha back then it would have bee much easier to distribute the app to the qa team or to my boss
distribution do everything manually app was never tested before release if you noticed I did everything by hand, updating the version code, trigger the release build, send the link to the qa team, this is a bad idea because
distribution human error app was never tested before release do everything manually human error, to quote Bill Murray People are stupid, people eat blood sausage, it is normal that sometimes mistakes happen, and this is especially true if you are tired and want to go home
called lanes in which you perform certain actions, so in my situation I could have created a lane development, that would be triggered after every commit create a release artifact and run all my test. I would create another lane for beta deployment and one more lane to upload the app to google play
package_name "your.package.name" true, to setup fastlane You would, need to add configuration into a file called APPFILE. There you would specify the package name of your app and the location of your Google credentials
do end end But the heart of fastlane resides in a file called FAST FILE. Fastlane is written in ruby and uses ruby syntax. In the Fastfile you define the platform of your app and specify the lanes
"clean assembleRelease test android”) supply end In order to upload the app to google play we just add the supply action, now we can call fastlane release from command line or better start it with one click from within your ci so you have a one click deployment
a large number of built in actions for source control, deployment and communication. You can also install plugins, actions created by other fastlane users, Lets look at some examples
supply( track: ‘rollout’, rollout: 0.1 ) end also integrates crashlytics, hockey, testflight, installr, … you can do the same for beta or staged rollout
assembleRelease test android”) supply slack({ message: ‘Version1.2 is out’, channel: announcements }) end if you want to send a message with slack for every build there is an action for that
assembleRelease test android”) supply twitter( message: “We just released Version 0.1.1212. http://awesomeapp.com/download” )' end also integrates hip chat, telegram, mailgun, chatwork, … or you can tweet to notify your users of a new version of your app
error do |lane, exception| end remember you will usually run this from your ci so might be a good idea to send a message when a build is complete or it fails
the metadata for your app, you should not need to manually copy and paste the release notes for all the languages that you localize your app in. When you initialize fastlane it will download the existing store entry and will update it with every supply command including that versions release notes
Screengrab.screenshot(“screenshot name"); } you said something about screenshots but my favorite features of fastlane is that you can automatically create screenshots of the current state of your app. To take a screenshot you call the screengrab library from your espresso tests and then …
said something about screenshots call the screengrab action from fastlane. fastlane will now start your ui tests on a headless emulator and take screenshots at the locations you specified
comes with a large number of predefined actions and there are hundreds of plugins written by other fastlane users, but if you are still missing that one tool that saves your day, you can write your own plugins
type fastlane new_action and fastlane will generate a ruby file for you that contains all of the necessary boilerplate code. And if you think that your action is something that every developer should have, you can submit it, to make your plugin available to other users
new version is available: update_fastlane fastlane_version "2.61.0" default_platform :android platform :android do before_all do sh("echo no | avdmanager create avd --force -n headless -k \'system-images;android-23;google_apis;x86\'") sh("emulator -avd headless -no-skin -no-audio -no-window > /dev/null 2>&1 &") end desc "New commit on master" lane :develop do skip_docs increment_version_code( gradle_file_path: "app/build.gradle" ) gradle(task: "clean assembleRelease test connectedAndroidTest") commit_android_version_bump(gradle_file_folder:"app") push_to_git_remote end desc "Deploy a new alpha version to Google Play" lane :alpha do supply( track: 'alpha', apk_paths: "app/build/outputs/apk/release/app-release.apk" ) end desc "Release a new version" lane :release do screengrab( clear_previous_screenshots: true, app_apk_path: "app/build/outputs/apk/debug/app-debug.apk", tests_apk_path: "app/build/outputs/apk/androidTest/debug/app-debug-androidTest.apk" ) supply( track: 'production', apk_paths: "app/build/outputs/apk/release/app-release.apk" ) end after_all do |lane| sh("avdmanager delete avd -n headless") end error do |lane, exception| sh("git reset --hard origin/master") end end
said in the beginning fastlane is ready to use. In fact one of my iOS colleagues joked about me being invited to droidcon to speak about fastlane because it is so common in the iOS world.