I have always believed that in the world of procedures, all repetitive, streamlined work can be handed over to automation to complete.

The same is true in mobile development: writing code is just one part of our development process, but we also need to compile, package, upload, deploy, manage libraries, version control and other non-coding chores, and these tedious and repetitive tasks take up precious time.

So in the world of engineers full of lazy people, there are always people trying to make changes, so these lazy people are happy to build many wonderful wheels, not only convenient for themselves, but also help others, and make the world a better place.

Today, I’m going to introduce you to one of those wheels: Fastlane, a Github Star project with over 10,000 stars and over 1,500 forks to date.

Promotion and application of Fastlane in our team

What do you say? Does that sound awesome? But before we get down to business, I’d like to briefly share with you some of the things that our mobile team has learned about continuous testing and continuous delivery.

As we all know, with the popularity of smart phones in recent years, mobile terminals not only have to carry out more business scenarios, but also have to cope with changing business requirements. This requires our mobile team to be able to quickly respond to change and iterate quickly. The question then is how to increase speed without sacrificing quality, which I think needs to be based on high-quality continuous testing and continuous delivery system.

But rise time is short, the mobile terminal itself in terms of maturity also wanting, can bring tools are much rarer, with the increase of depth of business scope, iteration can speed up, such as the certificate management, packaging, upload, publish such repeated and there is no technical content of the work gradually take up all the time, this criticism within the team.

So our architecture team has been looking for such a tool, a solution, since the beginning of last year to completely free the hands of engineers.

At the beginning, we tried to use Jenkins+Fir to build a set of continuous testing environment, and the process is shown as follows:

To tell the truth, the effect can be, at least in a certain period of time to meet our requirements, but Jenkins itself is only a general CI process management system, such as ITC itself does not provide bag and Meta content management, signature, certificate management, and so on and business scenarios in the combination of mobile terminal, and configuration of the process is very complicated.

Late last year, by chance, we discovered Fastlane on Github, saw the Readme and decided to give it a try. In fact, at the beginning, we only used Fastlane to solve the problem of certificate synchronization and ITC uploading within iOS team. However, as we studied further, we found that Fastlane can do more, so we gradually applied it to more scenarios on iOS, such as: Release of proprietary Pod, static check of code, UIAutomation test, etc., then extend to Android platform, complete a series of tasks such as release of proprietary AAR, Monkey test, etc. Fastlane has now become an integral part of our work.

In addition, Fastlane itself can be well integrated with Jenkins, Circle and other mainstream CI systems, and because the main CI processes are managed and executed by Fastlane, the complexity of these system configurations is fundamentally reduced.

Introduction of Fastlane

Having said that, we return to today’s protagonist, first of all, a brief introduction: Fastlane is a set of automation tools and frameworks written in Ruby language. Each tool corresponds to a Ruby script, which is used to perform a specific task. The Fastlane core framework allows users to combine different tools organically and flexibly in the form of similar configuration files. Thus forming a complete automated process.

So far, Fastlane’s toolset contains more than 170 widgets, covering packaging, signing, testing, deployment, distribution, library management, and more.

Description about these tools and use can look here: docs. The fastlane. Tools/actions/Act…

If these tools still don’t fit your needs, it’s ok. Thanks to Fastlane’s powerful Action and Plugin mechanisms, if you happen to know some Ruby development, you can easily write the tools you want.

In fact, about half of the tools are officially produced. The rest are contributed by members of the Github community, one of which I was fortunate enough to contribute. (It is recommended that mobile developers learn a scripting language, such as Ruby.)

Like Cocoapods, Fastlane can be installed through RubyGems. If you have a Ruby environment on your computer, just run the following command to complete the installation:

gem install fastlane
Copy the code

Common scenarios and pain points for continuous testing and delivery of mobile clients

Fastlane can do a lot of things on its own, but one of the most important things it can do is embed it seamlessly into a continuous testing and continuous delivery system.

To help you understand, let me take iOS as an example and give you a few common scenarios we encounter in mobile development:

Scenario 1 When an iterative development test is completed and the server is online, we will use Testflight for online follow-up testing. The following process is generally performed:

  1. Run the Git Pull command to Pull the latest code locally
  2. Pod Install installs the latest dependency libraries
  3. Add Build Version in Xcode
  4. Click Archive in Xcode to compile and package
  5. Choose to export an IPA file in iOS AppStore mode
  6. Upload IPA to ITC using Application Loader (TestFlight)
  7. Then wait for the ITC Process to complete, log in and select the previous Build to run the TestFlight test
  8. Since the version number has changed, you need to Commit and Push the code

If there is a problem with the online test, repeat the above 8 steps after the repair. In fact, the students who have done this should have experienced that it takes about 30 minutes if it is smooth. If you forget to add the Build Version once, the previous work will be in vain. In the early days of our team, as the automation system had not yet been established, one of our colleagues was in charge of this. During the two days of online testing, he could do nothing but package and upload the test.

Scenario 2 With the development of the business and the increase of the product line, we need to split the APP into several basic components and business components for cross-app use and easy management and maintenance (this is another big issue, which will not be discussed here). Each component is managed by a private Pod, and Pod releases and updates become part of our daily work. For these PODS, the general principles within our team are: The person in charge of Pod is called the library management internally, and this matter is shared by each library management. The process of the library management releasing a Pod is as follows:

  1. Increases the version number in Podspec
  2. Run the pod lib lint command for library validation
  3. Git Commit code
  4. Git Push code to the remote end
  5. Type a Git Tag
  6. Push the Tag to the remote end
  7. Issue the pod repo push command to publish the library to a private repository

If there are only two or three libraries and the update frequency of the library is low, it is fine to do it manually each time. But as the number of libraries increases, especially if the top level libraries are dependent on the bottom level libraries, upgrading a library becomes much more important than it really is, and the process can be quite painful to do manually.

At this point, I’m sure that those of you who have done this, should be able to relate to this.

So let’s take a look at how Fastlane can be used for both of these scenarios.

In fact, it is not difficult to say, first under the project implementation:

fastlane init
Copy the code

Then follow the configuration guide, fill in the App and ITC information, Fastlane will create a Fastlane directory in the project directory, which contains all the configuration related to this project, all you need to do is to configure the above process in the Fastlane directory in the Fastfile.

Fastfile for scenario 1 (HipChat can be ignored) :

desc 'Deploy a new version to the App Store' lane :do_deliver_app do |options| ENV["FASTLANE_PASSWORD"] = options[:itc_password] project = options[:project] scheme = options[:scheme] version = options[:version] build = options[:build] || Time.now.strftime('%Y%m%d%H%M') output_directory = options[:output_directory] output_name = options[:output_name] hipchat(message: "Start deilver app #{project} at version #{version}") hipchat(message: "Git pull") git_pull hipchat(message: "Pod install") cocoapods hipchat(message: "Update build number to #{build} and building ipa") update_build_number(version: build, plist: "#{project}/Info.plist") gym(scheme: options[:scheme], clean: true, output_directory: output_directory, output_name: output_name) hipchat(message: 'deliver to itunesconnect') deliver(force: false, skip_screenshots: true, skip_metadata: true) hipchat(message: "Upload #{project} to itunesconnect successfully!" ) git_add(path: '.') git_commit(path: '.', message: "update build number to #{build} and upload to itunesconnect") git_pull git_push(branch: "test") endCopy the code

Fastfile for Scenario 2 (HipChat can be ignored) :

desc "Release new private pod version" lane :do_release_lib do |options| target_version = options[:version] project = options[:project] path = "#{project}.podspec" hipchat(message: "Start release pod #{project} at version #{target_version}") git_pull ensure_git_branch pod_lib_lint(verbose: true, allow_warnings: true, sources: SOURCES, use_bundle_exec: true, fail_fast: True) version_bump_podspec(path: path, version_number: target_version) # Update podspec git_commit_all(message: "Bump version to #{target_version}") Push_to_git_remote # Push tag pod_push(path: path, repo: "GMSpecs", allow_warnings: True, sources: sources) # Submit to CocoaPods hipchat(message: "Release pod #{project} Successfully! ) endCopy the code

For Fastlane configuration, there are more detailed descriptions in the official documentation:

Docs. Fastlane. Tools/getting – sta…

Once the script is configured, the rest is a breeze. For scenario 1, we can use the terminal to execute the following command in the project directory:

Fastlane do_deliver_app project:Gengmei scheme:Gengmei-AppStore version:6.3.0 build:201609011530...Copy the code

Similarly, for scenario 2, we can use the terminal to execute the following command in the project directory:

Fastlane do_release_lib project: GMUtil version: 0.1.4Copy the code

Any complex process, basically a command all done, is not very convenient.

In addition, in order to make Fastlane commands more stupid and visual, we developed a system named Jaguar, which is suitable for continuous testing and publishing on mobile terminals, based on the Fastlane kernel and using the Ruby on Rails framework. Jaguar itself connects with Gitlab, Sentry, Jira, HipChat, Maven and other internal systems to form a complete automation system.

For most automated processes, Jaguar automatically triggers them through various timed tasks or Webhooks; For the few things that need to be done manually, engineers can do them at the touch of a button.

Here’s a screenshot of Jaguar:

A brief review of the experience of using Fastlane and trampling pits

After using Fastlane for a long time, my deepest feeling is that Fastlane really frees engineers from all kinds of boring repetitive labor and process work that they have to do and focuses on the business or architecture itself, which greatly improves the overall development efficiency, testing efficiency, and operation and maintenance efficiency.

There are a few things to do with Fastlane:

Since Fastlane itself is updated frequently, about once every 1-2 weeks, it is recommended to read the Release Notes of these updates carefully if the latest versions have not been upgraded, otherwise some strange bugs may appear, such as: When 1.87 is upgraded to 1.88, if the following two lines are not added to Fastfile:

ENV['FASTLANE_EXPERIMENTAL_TRANSPORTER_AVOID_SHELL_SCRIPT'] = '1'
ENV['SPACESHIP_LOGIN_ENCODING_IDENTITY'] = '1'
Copy the code

So, when ITC was uploaded, an error was reported and the cause could not be seen from the error, eventually the cause was found in the Issue on Github after some trouble: Spaceship added a small feature which caused the Bug.

In addition, if you encounter problems with Fastlane, you are advised to directly issue on Github. Fastlane authors and community engineers will respond quickly and help you solve the problem enthusiastically. Of course, when you ask questions, you should try to describe clearly. A screenshot of this screenshot.

Think outside the box. Fastlane isn’t just for mobile

Although Fastlane was built for mobile, if we use our imagination, we can also sort out the back-end, front-end continuous integration and continuous delivery processes and give them to Fastlane to manage as well (of course we need to customize some plugins or actions).

For example, our team is currently planning to integrate the PC UI automation testing process first:

  1. Run Git Pull to Pull the latest code
  2. Install Requirements using PIP
  3. Confuse compressed front-end Javascript with CSS
  4. Restarting The Django Service
  5. Use Selenium to perform UI automation tests
  6. Collect test results and email them to QA team

The corresponding Fastfile is as follows (shorthand, not really used yet) :

desc "Do automation test for pc web"
lane :automation_test_pc do |options|
  git_pull
  pip_install
  gulp_build
  restart_django
  selenium_test
end
Copy the code

In this way, the continuous integration and delivery of the client, front end and back end within a team can be unified deployment, unified management, unified maintenance, so as to meet the team’s needs for automation as far as possible in the infrastructure, why not?

conclusion

This post just gives you a taste of Fastlane for example: How to customize Action, Plugin, how to use in Android platform details, how to apply in automated testing scenarios, as well as some advanced Fastlane usage, I will make corresponding collation in the following period of time, forming an article for your reference.

Due to my limited level, it is inevitable that there will be mistakes and omissions. I also welcome students to correct me. If you have better cases on the use of Fastlane, you are also welcome to exchange and share.

Finally, attach a Fastfile script that our team is using and some custom Actions: github.com/thierryxing…

In addition, Fastlane also provides some examples of foreign teams: github.com/fastlane/ex…