Continuous Integration with App Center Build for Xamarin Apps
Integrating Xamarin Projects into a Continuous Build Workflow
It is common on software projects for developers to work in parallel. At some point, it is necessary to integrate all of these parallel streams of work into one codebase that makes up the final product. In the early days of software development, this integration was performed at the end of a project, which was a difficult and risky process.
Continuous Integration (CI) avoid such complexities by merging every developer’s changes into the common code base on a continual basis, usually whenever any developers checks in changes to the project’s shared code repository. Each check-in triggers an automated build and runs automated tests to verify that the newly introduced code didn’t break any existing code. In this way, CI surfaces errors and problems immediately and ensures that all team members stay up to date with each others work. This results in a cohesive and stable codebase.
Continuous integration systems have two main parts:
- Version Control – Version Control (VC), also called source control or source code management, consolidates all of a project’s code into a single shared repository and keeps a full history of every change to every file. This repository, often referred to as the mainline or master branch, contains the source code that will ultimately be used to build the production or release version of the app. There are many open source and commercial products for this task, which typically allow teams or individuals to fork a copy of the code into secondary branches where they can make extensive changes or conduct experiments without risk to the master branch. Once changes in a secondary branch are validated, they can then be all together merged back into the master branch.
- Continuous Integration Server – The Continuous Integration Server is responsible for collecting all of a project’s artifacts (source code, images, videos, databases, automated tests, etc.), compiling the app, and running the automated tests. Again, there are many open source and commercial CI server tools.
Developers typically have a working copy of one or more branches on their workstations, where work is initially done. Once an appropriate set of work is complete, the changes are “checked into” or “committed” to the appropriate branch, which propagates them to the working copies of other developers. This is how a team ensures that they’re all working on the same code.
Again, with continuous integration, the act of committing changes causes the CI server to build the project and run automated tests to verify the correctness of the source code. If there are build errors or test failures, a CI server notifies the responsible developer (via email, IM, Twitter, Growl, etc.) so he or she can correct the problem. (CI servers can even refuse the commit if there are failures, which is called a “gated check-in”.)
Continuous Integration Environments
Setting up a continuous integration environment means combining a version control system with a build service. For the latter, the two most common ones are:
- Team Foundation Build is the build system of Visual Studio Team Services and TFS. It is tightly integrated with Visual Studio, which makes it convenient for developers to trigger builds, automatically run tests, and see the results.
- Jenkins is an open-source CI server that with a rich ecosystem of plugins to support all kinds of software development. It runs on Windows and Mac OS X. Jenkins is not integrated with any specific IDE. Instead, it is configured and managed via a web interface. Jenkins CI is also easy to install and configure which makes it appealing to small teams.