iOS Continuous Integration With Fastlane and Jenkins
iOS Continuous Integration With Fastlane and Jenkins
Learn about employing continuous integration for iOS mobile app development with Fastlane and Jenkins CI tool, plus Testflight.
Join the DZone community and get the full member experience.Join For Free
Planning to extract out a few microservices from your monolith? Read this free guide to learn the best practice before you get started.
One of the basic pillars of Apiumhub is our premise to the clients to always deliver working software with the highest possible quality levels. In order to do it, we work with Continuous Integration that allows us to have versions of their applications available for them, tested, used and that can be passed to production as quickly as possible. And today we will look more in details on how to do iOS continuous integration with Fastlane and Jenkins.
To carry out this task, we developed through a series of Jenkins plugins a DSL that allows us to have the latest software versions after having passed the integration tests, functional tests and QA tests and that are ready and validated to distribute them when the client requires it. This allows us to have short development cycles with significant value delivery and very fast feedback from end users on any of the new features added to a client application.
Thanks to the experience of several years working with several clients and the great accumulated knowledge, we have decided that it was time to incorporate new platforms with our continuous integration system. In this case, we will discuss how we have added the iOS platform to our system using the Fastlane tool and the Jenkins continuous integration system.
iOS Continuous Integration With Fastlane
Fastlane is a tool for managing Android and iOS continuous integration cycles (packaging and deployment). It was created by Felix Krause and is based on Ruby. The need to create a tool of this style, had its origin in the long, repetitive and convoluted processes of packaging applications for mobile devices first in iOS and then the support to Android was added.
The fundamental basis of Fastlane is that it allows us to create a kind of "scripts" which are called ‘Lanes’ where a series of preprogrammed "commands" called "Actions" are executed. There are a series of actions by default in the tool that allow us to manage different aspects of the life cycle of mobile applications. The actions, as we discussed before, can be grouped into lanes that allow us to create custom scripts according to the needs that we want to cover the life cycle of the application.
Example of a lane:
lane :beta do increment_build_number gym # Build your app testflight # Upload to TestFlight end
This lane is called beta and what it does is: increase the number of the build, do the packaging (generates the iPA) of the application and send it to Testflight.
We are not going to talk more about it and explaining how Fastlane works since all the documentation is very well collected on its web and there are many examples on the internet.
To be able to install Fastlane, we must take some things into account:
1. Have the appropriate version of ruby, for this we will execute the command
ruby -v in a terminal
It is important to control the ruby version because by default OSX works with version 2.0 and this causes many problems to Fastlane so we recommend installing the version management system of Ruby rvm. In case you have problems with the ruby version you can go to tutorials like this or do a quick search on Google (‘update osx ruby version’).
2. Install the xcode tools
Fastlane can be installed through the following:
- Home Brew (
brew cask install fastlane)
- Ruby, like a gem (
sudo gem install -n / usr / local / bin fastlane –verbose)
Once Fastlane is installed on the machine, we have to go to the project folder where we want to add Fastlane and execute the command:
What will create all the dependencies and configure the project to support Fastlane. Once the process is finished, your project should contain a folder called Fastlane and inside there should be 2 important files:
- Appfile: which contains the identifiers of the project and the equipment and the apple id is used to manage the credentials and the connection with iTunes.
- Fastfile: this is where the lane is defined. By default, it usually brings the most common ones that are the lane of beta and release. This file is where all the processes of the life cycle and deploy of the application are configured and where all the management is done.
At Apiumhub, we have two lanes configured, one of which we call build. What it does is pass the tests using the action scan and then use the action gym to package the application. The other lane, we call release. It sends the application to the Apple Store to publish.
lane :build do scan(scheme: "Plannear") gym(scheme: 'Plannear', export_method: 'app-store') end Lane release lane :release do deliver(force: true) end
If the client wants to test their application internally before sending it to Apple, we use another lane called pre-production that sends the application to Testflight and distributes it automatically to all users added as testers.
Once we have the Fastlane tool setup and tested what works in the project, what we do is configure the Jenkins to execute the tasks of the tool automatically (In this example what we have done is configure a local machine of a user as a test machine, but this could be done in the same way with any computer that had OSX installed and correctly configured the Fastlane).
The remote node will be executed through web start. So in the machine where the remote node is executed, we have to install java and the web start tool. In the section "remote root directory" is the folder where the iOS project containing the Fastlane is installed.
The next step is to define our pipeline (it is necessary to have installed the plugin build pipelines) that has the following configuration:
The part that we have to complete in this case is the one that says initial Job, which is where we will tell Jenkins what jobs we want it to execute in its pipeline.
Finally, we come to the most important part of the Jenkins configuration, where we define the job that will be executed on the remote machine, every time the task of the pipeline is launched.
The configuration of the job is fairly standard for Jenkins, where it will be defined that first the GitHub project should be downloaded and then execute the appropriate lane of Fastlane. The configuration would be similar to this:
The most important part, in this case, is the final shell script. The particularity of this script is that it is necessary to correctly configure ruby environment variables so that Fastlane’s remote execution works correctly.
Once we have defined the set of pipeline → task → job we have already automated the whole process and simply by configuring the execution through a schedule in Jenkins we can execute any process of the life cycle of the application automatically.
In our case, we usually define a pipeline for build and one for release and we can follow very quickly the process in Jenkins that would look like this:
This also helps if the client requests it, we can configure a machine in his or her facilities that executes the whole process, because in our case all the Jenkins configurations are saved in a groovy file that can be versioned, which allows a quick deployment in any continuous integration environment with the same characteristics.
Published at DZone with permission of Abel Fernandez . See the original article here.
Opinions expressed by DZone contributors are their own.