Continuous integration for creating mobile applications
In today's article we give you an insight into our infrastructure. Why? Because we are proud of it and like to boast about it to the entire world. We will also be pleased if this article becomes an inspiration to others who might now be solving similar problems.
CI at Ackee
The term Continuous Integration (CI) is already domesticated in the IT field. It is a set of tools and processes that accelerate development, test the software and also perform application deployment automatically several times a day. If we want to talk about the development of mobile applications, perhaps the least favorite activity of every developer is sending test build and applications testing in all the available environments. Ackee developers have been relieved from this for several months, and not just they are satisfied with the result, but also testers, project managers and especially clients. A financial saving of tens of thousands of crowns is also a pleasant benefit. How did we accomplish this?
First of all, it is necessary to realize that many developers use a laptop when creating mobile applications, which is effective but still lags compared to a quality desktop computer. So the first thing we need is a Continuous Integration server, which is used for creating websites, as you may have read in the previous article.
As our CI server we use Jenkins, which needed to be configured and for example, Android SDK plugin installed. Then we had to create completely new project templates for both iOS and Android so that they are easy to compile from the command line and resulting binary files and dSYM are easily identifiable. In the next phase, we had to invent different schemes for the developer build, test build and production build so that Jenkins produces the correct file at the right moment.
GIT is behind it all
GIT, or the incoming commit for the selected repository, is at the beginning of all operations. Based on the branch, Jenkins decides which version of the application it is, and determines the appropriate parameters for the build accordingly.
We also use GIT for the versioning of builds. Originally, we wanted to use an internal Jenkins Job Number to identify the specific versions, which would however have resulted in a large number of inconsistencies between the developer, testing and client versions, since each of these versions has its own Jenkins Job. To number the versions, we therefore use the number of commits in the given branch. This technique results in one disadvantage, because such numbered versions usually differ from each other by a number greater than 1. However, this minor shortcoming is absolutely negligible for us and moreover, on the outside it looks like we are much more hard-working J
What does Jenkins work on
At the moment when Jenkins downloads all the source files, it first performs a check and downloads any dependencies that have changed. Then it performs automatic tests with an output in JUnit format that Jenkins can present in clear synoptic charts. If the tests fail, the work ends and the "culprit" gets scolded through our internal chat. Otherwise, the operation continues and the build with the given configuration runs. Jenkins then loads the resulting files to the distribution website for our testers and project manager, who can then send that version directly to the client.
There is no magic behind this, just a lot of little things that nicely fit together and the result is a workflow that does not burden developers, plus it tests each version, distributes it (the client has automatic access to new versions every day, without him having to ask) and especially saves time and money!
P.S. Our distribution infrastructure is also very closely linked to our CI server and the next article will therefore be dedicated to it.
