A couple of months ago I had the opportunity to join a new mobile app development team. It has been really fun and interesting, but coming from a web development area, it has been quite challenging as well. One of the first things we focused on was setting up a CI build. We wanted to… Continue reading Continous integration with Xamarin, TeamCity and FAKE – Part 1
A couple of months ago I had the opportunity to join a new mobile app development team.
It has been really fun and interesting, but coming from a web development area, it has been quite challenging as well.
One of the first things we focused on was setting up a CI build. We wanted to create a new version at every check-in which could easily be distributed.
Thus, the overall focus of this series of posts will be setting up a CI build for Android and iOS Xamarin projects with TeamCity and FAKE.
I’ll split up the complete explanation into several blog posts.
Remark: The solution I will describe here is not something I invented myself. This has been a team effort so credits to all the colleagues on the team.
What do we want to achieve?
During development every check-in in source control should create a new package (an IPA or APK file) which users can then install. This will be the alpha version.
When the sprint is finished, we create a new branch in our source control system which will be our beta version from now on.
However, the test users should also be able to test the beta version without losing the alpha version on their phone. This means that the beta version should not overwrite the alpha version.
How can we achieve this?
We need to focus on the bundle ID. Both on Android and iOS the bundle ID mostly contains your company name and project ID.
This will be the ID for our production version but we need to create two other bundle IDs for our alpha and beta version.
This will allow side-by-side installation of the different build versions because the OS actually identifies this as three different apps.
The only downside of this approach is that you will have three apps with the exact same name and icon. This makes it very hard to identify which is the alpha, beta or production version.
One solution is to create a seperate icon for each version. We’ll get back to that later on.
What is the easiest way to quickly switch between these different versions?
The solution we’ve choosen is a combination of different build configurations and MSBuild tasks.
You need to create a build configuration for the alpha version, one for the beta version and one for the store.
The naming of your build configurations is important as you will see later on.
Name your build configuration as follow and create one for AnyCPU, iPhone and iPhoneSimulator.
Make sure to configure each build configuration correctly. You don’t want to enable DEBUG symbols for your AppStore build configuration.
The next step is to determine the bundle ID based on the choosen build configuration.
This can be accomplished with custom MSBuild tasks.
I can’t show you any code but the idea is to create two MSBuild tasks.
One task is responsibly for determing the current build configuration and outputting the correct bundle ID.
The output of this MSBuild task is then used in the second MSBuild tasks which writes the bundle ID to the Info.plist file and/or Android manifest file.
At every compile the MSBuild tasks will now write the correct bundle ID.
In a next post we will use these build configurations in an build script with FAKE so we can setup a TeamCity alpha and beta configuration.
But what about a different icon for each release version?
You can use the same approach by creating an MSBuild task which copies the correct icon from a folder based on the choosen build configuration.
Next upcoming post: Creating a build script with FAKE
Fill in the form below and we’ll get back to you as soon as possible.
Thanks for getting in touch!Oops. You seem to have written your full name in invisible ink. Please enter it so we can read it. Oops. You seem to have written your company in invisible ink. Please enter it so we can read it. It seems your e-mail doesn’t exist. Please enter a real one so we can contact you. Oops. You seem to have written your telephone in invisible ink. Please enter it so we can read it. Sorry, we could not send the enquiry.