In my previous post I discussed what Bitrise is and why we have used it at West Monroe to make it easier to use Continuous Integration when developing mobile apps for our clients. In this post, I will discuss the setup of an “app” and the makeup of the default workflow that each app begins with. To keep things simple, I will use Github as the means to hold my source code.

Create an “app”

After signing up and logging into Bitrise for the first time, you will need to find the button which adds your “app”. On your first login this will be a large purple button in the center of the screen. If it is not, you will find it near the top in green. A picture is below of the

Clicking this link will take you to a page that you will become familiar with, the strength of Bitrise, the setup process. I have to give great credit here, the Bitrise team makes this incredibly easy and straightforward. Literally all you have to do is follow the instructions.

For Github (GH) you have a couple options. You can use Other/Manuel and grab the clone URL yourself OR, you can connect your GH account to Bitrise and instantly have the ability to select the project you want to build; we are going to do the later.

Since you, or at least I assume you do, own your Github account you can use the SSH Key Auto Add (this doesn’t work for all cases). The next step is to specify which branch is your default branch (usually master).

The next part is my favorite. Bitrise analyzes your code and determines what kind of project you are working with and then sets up a reasonably competent workflow for that project type.

As you can see, Bitrise accurately indicated that what I gave it was a Xamarin project and it is now asking me to finish by selecting the central build file and thus generate the project path. Side note: with Xamarin projects you will need to connect your account (Bitrise will walk you through this) as a way to validate your license which is necessary for the builds. Although, this portion does confuse me as since being purchased by Microsoft, the entire idea of licensing no longer exists.

I am going to skip talking about the Webook for now, but needless to say you can have Bitrise do it for you, again, assuming you own the GH account the code is associated with.

Before you start doing builds lets talk

Applications which use Bitrise are organized into “apps”. You can think of this app concept as a generalization covering all aspects of the build for a given project. In terms of ownership, “apps” are owned by the user who creates them. At West Monroe, we have a single user (a builder user) who owns all apps. Select team members have access to this account and are responsible for the initial setup of a new “app”.

Part of this setup process identifies other team members who are admins for that app and thus have the same rights as the owner; with the exception of dictating payment options. Side note: Bitrise just recently launched the concept of organizations. I have not yet had a chance to see how this change will impact how we organized our teams. For now here are the guidelines at West Monroe:

• Unless they are performing active development no external team members are added as build members
• Seniors and above (or those who have a leadership role) are given admin access
• Other team members are given the role of “Developer”
• More often than not QA team members will not get access to the builds since we use HockeyApp to distribute QA builds

Obviously these are the policies which work for West Monroe, your mileage may vary. You will note that we are dependent, with respect to access, on HockeyApp. Truth is, Bitrise does offer steps which enable distribution of builds, but we find that HockeyApp is more suited to this.

The final point is concurrency. One of the big advantages to paying for Bitrise is to enable concurrent builds, that is for builds to run in a non-linear fashion. I cannot emphasize the handicap for mobile shops in not paying for Bitrise. Being able to run only one build at a time when many projects are in flight will quickly have an impact on productivity as the advantages of CI are lost. Consider paying for the service is my recommendations.

Let me run a build

Ok, so now the app is setup and as a cookie for our efforts we get the option to run a build immediately, which you can. This will do a very basic that, in our case, will clone the repo, build it and at the end deploy it for download to Bitrise. For most teams this will suffice for internal testing and evaluation. Let’s talk about these steps. Again I am using Xamarin so your steps will be different if you are targeting native Android or iOS, but the overarching theme will be the same.

Note: These steps are listed on the Workflow tab.

• Activate SSH Key: validates access to the repo via SSH, necessary for the cloning process
• Clone: Clones the repo and stores the code on the virtual machine. Remember virtual machines are only used once and then discarded, thus ensuring a clean environment each time
• Do Anything: This doesn’t do anything important, just illustrates that you can use scripts to carry out operations for which steps do not exist
• Certificate Installer: For iOS projects this ensures your certificates and provisioning profile are on the virtual machine ahead of the builder step which will use them
• Xamarin User Management: Activates and/or validates your Xamarin license
• NuGet Restore: Restores the NuGet packages for the solution: Think CocoaPods on iOS and Gradle on Android, same concept
• Xamarin Builder: Runs a Xamarin build. Interesting side note, on iOS you will have a separate step for archiving, on Xamarin you will not, the Builder tasks does this regardless of what you specify. It is actually a bit annoying when you start wanting your process to JUST check if the code builds. More on that in a future article
• Deploy to Bitrise: Deploys the .ipa and/or .apk to Bitrise for download. I use this a lot for initial setup so I can validate the output before I let clients see it. Talk about that in a future article though.

So, if you run this code right away it should build your application and output the appropriate distributable, though depending on your configuration it may not actually be distributable. I will touch on that more when I start talking about HockeyApp.

However, having to manually start builds is a pain in the ass and totally defeats the purpose of automated builds. So let’s briefly touch on Triggers.

Let’s trigger a build

From the Dashboard you can select your app and then click the Workflow tab, same place you were at when we talked about in the previous section only this time you are going to click “Manage Workflow” which enters you into an edit mode.

There is a lot here and I will cover it in a future article, I promise. For now, I want you to take notice of the Triggers option in the left side navigation, clicking this will bring up (assuming this is still a new app) the screen below:

By default, Bitrise has created a single trigger that will kick off our build whenever any branch is changed. It gets notified when a branch changes via the Webhook you setup earlier (you can set it up now if you like under the Code tab). Right now, you only have one workflow, primary in future articles I will show you how to create new Workflows and how to share parts of a workflow with others.

For now, the important thing is understand that you setup triggers to initiate certain builds when certain branches changes. If you are familiar with git-flow you can see how this makes sense; West Monroe uses git-flow extensively on mobile projects.

• Development changes launch the CI build which checks the code builds and runs unit tests
• QA branch changes initiate a build which is distributed to QA team members for testing
• Stable branch changes initiate a build which is distributed to project stakeholders and is used for demos
• master branch changes initiate a deployment to the relevant production environment including automatic app store submission

So, by now you should have a grasp for how Bitrise is organized and how to setup application using Github (Bitbucket as well since they operate the same). In the next article I would like to discuss the finer points of workflows and best practices I have found when setting things up. The one warning I will give is, CI does not fix a broken process. If you do not have a process that works in front of Bitrise (or any CI tool) you will ultimately not find success; more on that later.