Explain the automatic construction and release of Android

In the process of app development and testing, I have done this for a long time: package, upload to the tower, write the update description on the tower and notify the test. Generally, the process of packaging and uploading takes about 2 minutes. In addition, because the project code is confused and bugly is used, it is necessary to transfer the confused mapping.txt to bugly after issuing each version. Day after day, and sometimes when the network is poor, this manual work mode will affect the work efficiency and mood. Therefore, automatic build and release has become a necessary skill.

This article shares my experience in Android automation construction. The tools and websites involved are as follows:

- Gradle - fir.im - Gitlab - gitlab-ci-multi-runner

The content includes: - use gradle to automatically build and publish to fir - use gitlab Ci to automatically build and publish to fir at the time of submission - configure gitlab CI multi runner of docker version on the server - a solution to publish on fir at the same time

Liberating productivity brought by gradle and fir

Build and upload APK to fir

I came into contact with fir.im earlier. At that time, the official had provided a command-line packaging and uploading tool fir cli. But there are two problems I can't stand:

1. It needs to be installed, and because it is written in ruby, it also needs a ruby environment

2. It will build all versions of flavor, although only one will be uploaded in the end (the problem has been solved later)

So, after I found that it provided APIs, I consulted gradle's documentation and wrote a simple fir publishing plug-in - fir publish. This plug-in is very small and light. It does not use additional dependency libraries. Network requests also use the HTTP client API of gradle itself. The usage is as follows: first, add the following dependencies to build.gradle of the root project:

Then add the following configuration at the end of the build.gradle file in the app:

The API token can be obtained by clicking your own account after you log in to fir.

The plug-in adds the following four tasks to your project:

-Fircert obtains the upload Certificate - firicon upload icon, depends on fircert - firapk upload APK, depends on fircert and assemblyrelease (or assemblyflavor release) - firall upload icon and APK, and depends on firicon and firapk

In the above configuration, the update log can be written directly on it, or a separate update log file can be created (recommended). Each time you want to publish, you only need to modify the update log on this file, and then execute the following command to automatically build and publish it to fir:

Note: Windows users do not need to add in front/

In this way, we only need to let testers pay attention to the update dynamics on fir, instead of waiting for the build to be completed before uploading, and then waiting for the upload to be completed before writing the update log.

Upload mapping.txt to bugly during construction

Regarding the problem of automatically uploading mapping.txt to bugly, bugly itself has provided the relevant gradle plug-in bugly. However, it will upload mapping.txt every time the release version is built, and usually we only need it when the final version is packaged for testing, so I modified the configuration:

A new variable is added here. The upload command is executed only when there is a publish attribute. This attribute is brought in during execution. Therefore, the commands we package and publish will further evolve into the following:

Further liberation brought by gitlab Ci

In the above process, in fact, the biggest problem we solved is to combine the three steps of build - release - writing version update log into one step, which eliminates the waiting of the intermediate process, but the result is that we have to manually execute this step every time we need it. Ci class services enable us to start construction when we push the code to the server, so that our whole construction process can be truly automated without human participation.

Since the company uses gitlab, only gitlab CI related content will be discussed here.

Gitlab CI multi runner is used in the new gitlab CI. For its installation, please refer to its official documentation, which will not be repeated here.

It should be noted that when registering after installation, if you want to register as a shared runner (all projects can be used), the address of the first question should be the address of your company's gitlab, and the token of the second question can be seen in the runner configuration of the administrator interface. If you want to register as a private runner, you can see its URL and token in the project settings.

Next, just add a. Gitlab-ci.yml file in the root directory of our project, configure CI in it, and then submit and push it to our gitlab.

Let's take my company project here as an example. The project is developed using git flow process. When it is to be released, a release branch will be created. Therefore, what needs to be released to fir is the code on the release branch and tag. We only need to build and test the code of other branches. In our company's projects, there are development environment, test environment and production environment, respectively corresponding to three product flavors: development, test and official. Only the API addresses are different between them. Therefore, it is OK to build tests using one of these environments.

So the script is as follows:

Here, I define two CI tasks, namely compiletest and publishtofir. Script represents the command executed by the task. Except indicates which branches are not built. When using git flow process, the branches to be released are named release / xxx, so they are represented by regular. Only indicates which branches only the build task is performed on. Type indicates the type of task.

After submitting the configuration and pushing it to gitlab, the CI can be triggered to perform the build tasks we defined. If you successfully configure the email sending service on gitlab, we can not take the initiative to care about the result, because if the construction fails, gitlab will send us an email notification.

If you don't want to use docker to run runner, skip the following section.

If you don't need to publish apks of different flavors on fir at the same time, you don't have to look at the later ones.

Ci runner for more advanced docker version

Although the above uses gitlab CI multi runner to complete automation, it runs on my computer. The memory and CPU occupied during each compilation will have a slight impact on the development, and I need to open a terminal to run the runner after each startup. There is a Ubuntu server within the company, which is specially used for code and project related services. It would be better to deploy our runner to this server.

Docker is installed on this server of the company, and other services run in the form of docker. In that case, I also abide by the rules and deploy runner with docker. Ask the company's technical manager for the administrator account of the internal server, turn over the PDF of docker - from introduction to practice, and then start writing dockerfile and experimenting on your own computer.

After stepping on the Ubuntu version, I can't install jdk8, mount the Android SDK directory, there is no 32-bit dynamic library, which makes the Android SDK unable to execute, and Chinese garbled code, my dockerfile is as follows:

Note: if there is any change in the future, it will be updated on my GitHub project at: https://github.com/msdx/dockerfile/blob/master/gitlab-ci-multi-runner/Dockerfile

Then, execute docker build to create a docker image, and then mount the Android SDK and the readable / writable gradle cache directory when running docker. For other problems, including runner registration, see my project description here: https://github.com/msdx/dockerfile/tree/master/gitlab-ci-multi-runner 。 Due to space reasons, I will not repeat it here.

Here, I package the Android SDK and upload it to the server via SSH. Then I unzip it in the Android SDK of the company's user directory, and create a folder graduserhome in the directory to put the cache of gradle. Finally, the script to start the docker is as follows:

Tips on fir -- multi flavor publishing method

As mentioned earlier, the project API address of our company is divided into multiple environments (development environment, test environment and production environment). Originally, I only need to package the test environment for testers, and the production environment will package itself when it is finally released. However, in the development of this new version, the server staff also hope that I can package the APK of the development environment for him, so that he can test himself sometimes. Because the project is under development and the version changes rapidly, I also want to publish it to fir through automatic construction, and then download it by himself, so as to ensure that he can obtain the latest developed version.

However, it is quite frustrating that the release of multiple environments of the same application is not supported on fir, although this demand was put forward by others a year ago. I asked the customer service. The customer service suggested changing the bundleid (applicationid). Of course, this is impossible, because our application uses many SDKs associated with applicationid, such as Gaode map, wechat sharing and various payments. It is impossible to redeploy a set. Finally, look at an implementation technique shared by others.

First, you need to register a number on fir (of course, you can also ask your colleagues for help), then upload your application, enter the permission control of the application, and invite your large one in. In this way, there are two such applications on your large one, and you can upload new versions of it. Of course, if you use API to upload, you don't need to invite, just fill in different API tokens. So finally, the configuration of fir release in build.gradle of my app is as follows:

Among them, flavor is set through the defined envflavor, and envflavor is set according to the value of the flavor attribute passed in during execution. The corresponding. Gitlab-ci.yml is also modified as follows:

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.