Speaking of automated packaging, I believe you are in contact, in the daily development especially in the case of multi-branch parallel development, automated packaging is particularly important, most of the time, we play and composition of bag packaging is generally, but development on the development branch, if adopt manual packaging, we need to cut branches repeatedly, not only affects the work efficiency, It also breaks our development thinking, whereas in the case of large projects xcode takes a long time to indexing each time.

Even for many small single-branch development projects, the advantages of automatic packaging are self-evident, because manual packaging can basically be said to do nothing, you need to wait step by step for the mechanization of archive, export and other steps. With automated packaging, you can continue your development at the click of a button. Therefore, automatic packaging is imperative.

This paper mainly records my exploration in the automatic packaging arrangement of the company, and the advantages and disadvantages of each platform and the pit stepped in the configuration process.

When it comes to continuous integration of iOS, Jenkins comes to mind first. Here, I would like to introduce some advantages and disadvantages of the Mac OS Server(Server for short) platform adopted by our company.

Compared with Jenkins, Server has three advantages:

  1. Compared with Jenkins’ complicated configuration, the Server configuration is simple, and the whole process can be basically the next step.
  2. Start building projects directly using Xcode without having to log in to a web page;
  3. Integration is quite high, no special requirements, basic can not write scripts, just need to configure a PList file that can be packaged.

Although Server is not as popular as Jenkins, there are many articles on the Internet. Moreover, as mentioned in advantage 1 above, Server configuration is really simple. In the case of complete certificates and description files, it is basically always click the next step.

Here are some aspects to pay attention to:

As shown in the figure above, the various Settings of bot are shown in the figure above. One bot corresponds to an independent workspace. If you know Jenkins, BOT can be compared to one of Jenkins’ projects.

If you don’t have a special need for packaging, check Archive, select the corresponding Scheme, Configuration, and specify a plist file. Triggers Triggers does not need to write any code to print the package.

The general structure of the plist file mentioned above looks like this:

This plist file corresponds to a series of parameters, we do not need to write, manually type a package, you can export the file. By the way, after the Server is configured and connected to the Server, any machine can upload the PList file. The Server copies the uploaded PList file to the current Bot working directory.

After the Server is configured, even Windows computers can be logged in via IP or from a visa, https://192.168.0.xxx/xcode/lastest or https://xxxdemac-mini.local/xcode/bots/latest, after landing will show the following interface, click the integration, You can start integrating, but it seems like you can only integrate, not configure, but given Apple’s inertia, it’s understandable that you want to build your own ecosystem.

Some configuration considerations for Jenkins:

Here are some of the pits I stepped on during the configuration process:

  1. Java-jar Jenkins. War — httpPort=8082;
  2. Git permissions need to tell Jenkins the private key, not the public key on Git: cat ~/.ssh/id_rsa;

Next, other users through the browser to http://192.168.0.xxx:8082 directly, through the account password, you can configure and build the project.

Jenkins advantages over Mac OS Server:

  1. The same LAN can be logged in, logged in can configure their own projects
  2. It seems possible to build tasks in parallel

When using Mac OS Server for packaging, it only starts one XcodeBuild process, no matter how many packaging tasks are performed

However, Jenkins has a more convenient way to package: Jenkins opens the token and does not require a user name login to package:

This didn’t work after the build project was set up, because Jenkins felt it wasn’t secure enough to do anything with the token. System Administration -> Global Security Configuration -> Check Allow Anonymous read Access

We can then use the command to pack:

The curl http://10.24.113.24:8082/job/notification_extension_test/build\? token\=123\&cause\=testBuild
Copy the code
parameter annotation
notification_extension_test The project name
token Token set above
cause This parameter is optional

It seems possible to deploy the packaging task on a specific machine with a single server:

Some summary about Server and Jenkins:

  1. If it is only the packaging of iOS terminal, Server is fully enough, and the operation is close to our usual development style, although the web page can not be configured, but for most companies, packaging configuration is the development of doing, rather than testing;
  2. For small projects on iOS side, there are not many branches, so more bots can be directly built to avoid handwritten scripts.
  3. If multiple servers are on the same server, Jenkins has a huge advantage. If a company has enough computers to serve as distributed packaging servers, packaging efficiency will increase even further.

A brief introduction to Fastlane and packaging scripts

When it comes to automated packaging, we have to talk about the very popular Fastlane. If Server and Jenkins are in the same dimension, both are packaging platforms, then Fastlane should be compared with shell scripts, or we can say, Fastlane encapsulates a layer on the basis of shell. Compared with script packaging, FASTlane has the following advantages after a short experience:

  1. Avoid tedious path stitching, copying, etc
  2. Modify the project configuration file to prevent the modification of the configuration file from being submitted to the remote branch during debugging, which may cause packaging failure

Let’s take a quick look at fastlane’s packaging code:

This is basically a wrapper around the previous Server’s exportPlist file, just to execute

Fastlane adhocMyApp version:100000 // 100000 is the version number transmittedCopy the code

I intentionally changed the Distribution Provisioning Profile to enterprise

The Provisioning Profile and teamID for each configuration have all been changed

Let’s look at the terminal and see what Fastlane does

And indeed, just like the picture above, make everything AdHoc. After modifying the configuration, the packaged core script is also executed:

Xcodebuild archive-workspace${work_space} -scheme ${scheme} -configuration ${configurationRelease} -archivePath ${archivePath}xcodebuild-exportarchive-archivepath${archivePath} -exportPath ${exportPath} -exportOptionsPlist ${exportOptionsPlist}

Copy the code

The parameters of the above script are also basically known by name. In the script, ${work_space} and so on represent the value of a variable. Here are the paths or strings corresponding to each configuration.

After the above script, an. Ipa file is generated in the specified exportPath path. We usually copy the IPA and dSYM files to the specified folder for testing, followed by a script to handle the tedious path. The script itself is not difficult, but it should be careful, and the test takes a certain amount of time, if you use Fastlane can avoid this annoyance.

conclusion

This article is mainly a collation after sharing among the team, not a particularly detailed tutorial, but just some attempts of the current automatic packaging and some problems encountered in the process and some thoughts of my own, if there is something wrong, please kindly comment.