Intro to JENKIN CI: Continuous Integration of Xamarin Mobile Projects
Sampath
May 26, 2015
Continuous Integration is a software engineering practice in which an automated build compiles and optionally tests an application when code is added or updated by developers. It is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. By integrating regularly, one can detect errors quickly, and locate them more easily. By using CI, teams can deal with the integration problems immediately, which results in a well-integrated and stable codebase.
There are two parts to the traditional continuous integration system:
• Source Code Management System – The Source Code Management System (SCM) consolidates all of the code into a single repository. This single repository is often referred to as the mainline or the master copy and is considered to be the basic or true version of the source code that will be used to build the application.
• Continuous Integration Server – The Continuous Integration Server is responsible for collecting all of the artifacts necessary for compiling a project – source code, images, videos, databases, automated tests, etc., and compiling the application and running the automated tests.
How CI works
Once the changes are committed, CI server will compile the project, setup the necessary environments for the project to work, and then, optionally, run automated tests to verify the correctness of the source code. If code cannot compile or the automated tests fail, then some kind of notification is usually sent out to developers so that they may correct the problem. Common types of notifications include, but are limited to, the following:
• E-mail messages
• Text messages
• Twitter broadcasts
• Growl notifications
• Instant Messenger
The following diagram illustrates this process:
Jenkins is an award-winning application that monitors executions of repeated jobs, such as building a software project or jobs run by time-based job schedulers. Among those things, current Jenkins focuses on the following two jobs:
• Building/testing software projects continuously. Jenkins provides an easy-to-use so-called continuous integration system, making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build. The automated, continuous build increases the productivity.
• Monitoring executions of externally-run jobs.
The ideal build server is a stand-alone computer dedicated to the sole purpose of building and possibly testing the application. A dedicated computer ensures that artifacts that might be required for other roles (such as that of a web server) do not contaminate the build. For example, if the build server is also acting as a web server, the web server may require a conflicting version of some common. Because of this conflict the web server may not function properly or Jenkins may create builds that do not work when deployed to users.
The build server for Xamarin mobile apps is set up very much like a developer’s workstation. It has a user account in which Jenkins, Xamarin Studio, and Xamarin.iOS and Xamarin.Android will be installed. All of the code signing certificates, provisioning profiles, and key stores must be installed as well.
NOTE: iOS applications can only be built and signed on a computer running Mac OS X.
The following diagram illustrates all of these elements on a typical Jenkins build server:
