Geekly Articles each Day
📜 ⬆️ ⬇️

How to move from BuddyBuild to GitLab CI in 4 hours



Prehistory


A year and a half ago, the iOS FunCorp team moved to a new service for a simple CI organization in iOS and Android projects.

Before that, we used CI on Bamboo, but there were a lot of problems with it, so we completely abandoned it and switched to BuddyBuild.
')
It worked so simply that you could not even know what CI is and how to upload the application in the AppStore, but calmly deal with code, tests and product development.
But times have changed, and BuddhuBuild is not the same, so we began to search for alternatives.
In this article we will talk about the new solution that our team has chosen, and give a few scripts for organizing CI on our own.

Just means good


In BuddyBuild, we were attracted by simplicity. First you need to take a few steps:

  1. Log in with GitHub / GitLab / BitBucket.
  2. Specify the repository with the project.
  3. Give service account and distribution-certificate.
  4. Wait until “magic happens” on the service side.

And right after that, you can get tests and artifacts on all branches, customize build rules using a clear UI, quickly switch between XCode versions and release in AppStore / TestFlight directly from the service.

When we started working with BuddyBuild, it could be used for free, but after a few months it was over. Now the starting package costs $ 79 per month. For ourselves, we chose a plan with three competitive assemblies for $ 279.

BuddyBuild worked well, but it did not last long.

With the growing popularity of the service, as well as the increase in the amount of code in iFunny, the build time increased from a stable 20 minutes to tests and an artifact assembly to 70 minutes.

We tried to find a solution for caching by means of the service, but nothing worthy was found in simple settings.

Meanwhile, the service was bought by Apple, and we made the final decision to abandon it.

CI / CD requirements


Based on previous experience with CI, we had several requirements for the new system.

  1. It should quickly deploy the agents and build environment with the minimum number of visits to the agents UI.
  2. Update Xcode without logging into the agent UI and having the ability to switch between multiple versions.
  3. Integrate with the system pull requests.
  4. Use a minimum of third-party dependencies for assembly and unloading in the AppStore.
  5. Have the ability to customize and customize build steps for different branches.
  6. Run the assembly of the artifact only by a button from the UI.

Gitlab ci


Together with the decision to abandon BuddyBuild, the idea was to migrate from GitHub to GitLab, and it already has a built-in CI / CD system, that is, we have the necessary integration with merge requests.

Installing the working environment on the agent


First of all, you need to enable the ability to access the agent via SSH using Screen Sharing. This is done in the Sharing settings:



Now, to connect to the CI agent, we can use the terminal and the SSH client:

ssh user@local.ip

After a successful SSH connection, you must disable the use of the password for the sudo command. It may seem like it is insecure, but given that all agents are available only within the local network, for better automation we disable the password for sudo. For this:

 sudo visudo

A standard Vim editor will open, in which you need to change the line:

 %admin ALL = (ALL) ALL

on line

 %admin ALL = (ALL) NOPASSWD: ALL

Many iOS developers do not like to dig into the console and rarely use Vim, so keep step-by-step instructions on how to change these lines:

  1. Press i, enter insert mode.
  2. Arrows find the desired string and change it.
  3. Next esc.
  4. Enter: w to save.
  5. Enter: q to exit visudo.

First of all, on each agent, we need the Homebrew package manager, which can be installed with the following command:

 sudo echo | ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

The echo command is used here to prevent the confirmation of the installation.
After that, you can set the required minimum dependencies from Homebrew. Here is what we chose:


Now you can install Xcode by running the following commands in sequence:

 export FASTLANE_USER="your@account.todevapple" export FASTLANE_PASSWORD="yourpasswordtoaccont" xcversion install 9.2

You can not export, but then the Apple ID and password will be requested during the installation process.

After these simple steps, the agent is ready to collect most of the iOS projects.

Agent registration


In order for the project to be seen by your agent on Gitlab CI, you need to install it and register it.

This can also be done using SSH and the command line on the agent:
First, download and install the agent:

 curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64

We give the right to perform:

 chmod +x /usr/local/bin/gitlab-runner

Install gitlab-runner as a service and run it:

 gitlab-runner install gitlab-runner start

Now you need to register the runner to CI, this is done by the command:

 gitlab-runner register -n --url CI_URL --registration-token TOKEN --tag-list fastlane,cocoapods,osx_10-13,xcode_9-2 --executor shell

This is a command that should be explained in detail.
CI_URL and TOKEN can be taken in the project settings on GitLab:
Settings -> CI / CD -> Runners -> Setup block of a specific Runner manually
--tag-list : specifies the tags that we will need further when setting up the project itself.

They can also be changed, for example, depending on which versions of Xcode are installed on the agent or what type of tasks we plan to perform on it.
--executor shell : specify that the agent must perform actions on the command line.

In order to avoid problems with CocoaPods, you also need to run the following commands:

 echo 'export LC_ALL="en_US.UTF-8"' >> ~/.bash_profile echo 'export LANG=en_US.UTF-8' >> ~/.bash_profile

It is necessary that when installing the pods there were no errors with the encoding.
After successful registration of the agent, it can be seen in the settings.
Settings -> CI / CD -> Runners



Project Setup


It remains to configure the Xcode project to work with GitLab CI.

It is quite simple to do this: you need to put a .gitlab-ci.yml file with a description in the root of the project.

After this file is added to the repository, the CI system will start executing the commands specified in it.

An example of our yml file:

 stages: - test - archive before_script: - git submodule init - git submodule update --recursive - pod install --repo-update archive_project: stage: archive script: - fastlane match appstore - xcodebuild -workspace iFunny.xcworkspace -scheme iFunny archive -archivePath build/iFunny.xcarchive | xcpretty only: - master - triggers - web artifacts: paths: - build/iFunny.xcarchive tags: - xcode_9-2 - osx_10-13 - cocoapods - fastlane test_project: stage: test script: - xcodebuild test -workspace iFunny.xcworkspace -scheme iFunny -destination 'platform=iOS Simulator,name=iPhone 7,OS=11.2' | xcpretty tags: - xcode_9-2 - osx_10-13 - cocoapods - fastlane

The yml format for GitLab CI is fairly well described here .

So that you can easily use the sample file, I will describe the main points that we use:


In the script we indicate all the instructions that need to be executed:

 fastlane match appstore

To synchronize certificates, fastlane has a good match command (for more information about using match, see the fastlane website ).

The main command to run the archive build:

 xcodebuild -workspace Project.xcworkspace -scheme ProjectScheme archive -archivePath build/Project.xcarchive | xcpretty

Project.xcworkspace - file with workspace.
ProjectScheme - scheme with the main target.
build / Project.xcarchive is the path where the working artifact will be assembled. Further, this path is used in artifacts: it indicates the CI, from where you need to pick up the archive.

In the block only , we indicate that this work should be done only on the master branch or when launched from the web, that is, when launched by the Run Pipeline button in CI / CD.

tags are those tags that must be assigned to the agent in order for it to run this work. Now they completely repeat what we indicated when registering an agent.
Next in the file is a description of the test_project .

From the interesting here - the test run line:

 xcodebuild test -workspace Project.xcworkspace -scheme ProjectScheme -destination 'platform=iOS Simulator,name=iPhone 7,OS=11.2' | xcpretty

In the -destination setting, we specify the simulator that is exactly available on the agents.

You can view the list of available devices on the agent via the SSH command:

 instruments -s list

After the .gitlab-ci.yml file has been configured , you can add it to the repository and the tests will be run automatically in the branch containing the file.

Conclusion


To set up the entire GitLab bundle and the embedded CI / CD system, we spent about half a working day, which is slightly more than 20 minutes spent setting up BuddyBuild.
But what we got from the move:


For our team, GitLab CI is a temporary solution, now we are preparing to move to Jenkins, in which we will add even more automation to the project.

Perhaps the experience described in the article will allow readers to move to GitLab CI in less than 4 hours.

And to make it easier to do, here are a couple of scripts with the commands described in the article:

Source: https://habr.com/ru/post/353930/

More articles:


All Articles