Implementation purpose: Optimize the development – test – release process

Current situation: After iOS development, manually Build to QA, QA raised a bug during the process, and manually perform Biuld again after development and repair. After release, synchronization between the release version and the test version cannot be guaranteed. Therefore, this scheme is proposed to optimize the process.

Phase 1 Optimization expectation: iOS automatically Build to dandelion internal test platform, and generate production environment IPA to TestFlight at the same time, with the same Build version number. After QA students download and verify the test environment on dandelion platform, they will verify the official environment through TestFlight App. After passing the test, the operating students will directly launch the system.

Second stage optimization expectation: IPA test, formal IPA unified cloud management. After verification, fastlane publishes to App Store Connect.

Why two stages?

  1. Currently developed, QA staff, you have ZI limits.
  2. Dandelion platform is a paid professional version, which theoretically has no traffic limit and rich functions (password extraction, wechat notification, browser download and installation do not need ITunes synchronization). Operation students can directly extract QA-verified IPA in App Store Connect for operation. It not only saves extra learning time of Application Loader, but also avoids risks caused by transmission tools such as wechat and Dingding. (Forwarding error, IPA cracked and injected)

Selection of thinking

After researching some automation tools, I chose Fastlane + Jenkins, both of which can be used alone or in combination.

Fastlane is lightweight, easy to configure, and fast to use. It provides many useful tools and intuitive scripts that allow you to do various custom processes without touching many system details. It supports both iOS/ MacOS and Android platforms. You can do most of this by interacting directly with XCode via commandLine.

Jenkins is an automated tool with a web UI, which allows you to use the GUI to set tasks, such as project parameters, as well as perform scheduling, such as daily scheduled tasks. Powerful, git support, and historical version of the save (collaborative cloud). QA can switch freely between branches and versions.

solution

Fastlane was used as a transition tool to establish a new standard process, and Jenkins was added when conditions were ripe. The combination maximizes the fastlane build speed and Jenkins version control benefits.

Why not just Jenkins?

  1. In daily use, Jenkins makes people feel relaxed and happy with the large number of plug-ins and rich functions. However, because of this, in the cooperation with Xcode, the maintenance and update time of each plug-in can not be controlled, so it will cause the failure of the version transition period. Problem scenario: When adapting to xcode 10 SDK, the plug-in stays in Xcode 9 after update, and the automation function is damaged. Apart from the plug-in, Jenkins does not have the ability to upload directly, which means that both formal IPA and test IPA will be directly exposed to various non-professional transmission tools and the desktop and wastebasket of relevant staff. The risks are self-evident.
  2. To get the most out of Jenkins, some of the cloud features and local metrics need to be configured and tested over time.

Technical details related to the first stage

Xcode aspects

In the compiler, the new environment and Configuration items are added through Preprocessing + Configuration to separate API and package name (bundle name, bundle name + Beta).

Fastlane aspects

To save readers time, the fastlane installation and configuration are not covered in this article. When the test workflow is executed on the console, an IPA for the production environment is automatically generated and submitted to App Store Connect.

Note: As of the issue of this paper, the first stage has been prepared.

The second stage related technical details

To save the reader time, the installation and configuration of Jenkins will not be described here.

  1. Build the trigger, here we choosePoll SCM, and then fill in the schedule description in the box belowH/10 * * * *, which means that it is pulled from the repository every 10 minutes, and if there are new commits, the project is built.
  2. Write the shell file with the Fastlane command that was executed on the previous console.

The deeper features will be improved with testing.