Thank you DevUp

I have had the great fortune to be selected to speak at St. Louis Days of .NET (now called DevUp) 4x in a row. I am always impressed by the organization of the event and the staff; plus who doesnt love getting a few days at a casino.

This year I gave one normal talk, my UI Testing with Xamarin talk and a new workshop which focused on Xamarin.Android. For the most part, the UI Testing talk went as expected. I feel like its beginning to lose its luster and I always feel like I come off as preachy during it; its hard not to when talking about testing. Nevertheless I do get positive comments and it does engage the audience, so thats good. However, I think this will be the last event I use it at, I am moving more towards development and DevOp centric topics, especially as my experience with Bitrise and HockeyApp grows.

As for the Xamarin.Android workshop, it was a classic case of being too greedy. I am very grateful the audience hung in there and a few even got it working. But, in the end, I was upset that I didnt take into account actually running the code on Windows as well as there being people who were unfamiliar with mobile programming in general. Overall, I made it work and it seemed well receive. Next time I give it, I will try for something smaller then a Spotify preview player.

As I prepare to head back to Chicago tomorrow, I reflect that it was one of my best conference experiences in some time and a great way to close out the year. I look forward to unveiling the updated version of my Xamarin.Forms Intro talk at Codemash in January.

An Amazing Month

Normally I do not like to use this blog to talk about my personal life but I wanted to talk about the month of September because of its significance. The month was very trying and stressful at work, our team took on a mobile project that involved us rewriting a mobile application in 1.5 months that a previous team took 1yr to write. I am happy to report that we did succeed thanks to the heroic efforts of ever member of the team. We have now entered a period of hardening the application.

In addition to this, I am proud to say that on September 7, 2016 I proposed to my girlfriend of 3yrs at the same User Group we had our first “date”. Yes, you heard that right, I proposed to my girlfriend at a User Group (the WMP office specifically). She laughed and cried and said yes, and it was the unique proposal she always dreamed of; definitely found a good one.

Later in the month, I received another surprise, I was selected to present on Xamarin.Forms at Codemash. Codemash, for those who do not know, has become one of the largest conferences in the US and being selected is extremely difficult; this was my 5th attempt. I am very honored by this charge and am going to be spending the time ahead of the event making sure I prepare fully for this experience.

I also, learned that I was promoted to the elite PAM level at West Monroe. PAM stands for Principal, Architect, and Manager; essentially the three paths the general consultant path divides into; you pick based on your preferences. For me, I am going to he Principal route, basically a Tech Lead and Tech expert. After my experiences at Centare which made me wonder if I had lost a step to have the success at West Monroe was gratifying and inspiring. I really cant thank WMP enough for the chance to be successful. I would also be amiss if I didn’t thank the great people I have gotten to work with; this promotion is a much a reflection of them as it is of me.

Then on the final day in September (ok Oct 1) I was informed I had become a Microsoft MVP, fulfilling a lifelong dream that, honestly, I never thought I would attain. I know that I am very active in local communities, but I know people who are much more active so I always thought the bar was out of reach. I am very humbled to be counted among the many other outstanding individuals who hold this honor. I promise to do my very best to uphold the sterling reputation MVPs have; also I am looking forward to the Summit.

Frankly, it would be hard to ever have a month like that again and I am still getting used to many of the changes (being engaged, being an MVP, and being a Principal) but I will get there. It really was an amazing month and I look forward to the next month.

Using Android Studio with Xamarin Studio

Let me be clear: I do not have much respect for the visual design tools that Xamarin creates. There is not anything particularly wrong with them but they just lack refinement, most likely because Xamarin is too busy keeping their bindings updated to stay with changes. This is something I have come to accept on the iOS side and so, when I do create visual layouts for Storyboards or Xib files I use Xcode exclusively, despite the existence of an editor in Xamarin Studio.

Recently, West Monroe engaged in a rare Android project and I got a chance to see how Xamarin Studio worked with Android. Regrettably I found the tooling to be even further behind Android Studio than the iOS side is behind Xcode. Forget even hoping for a sane layout if you used any tools from the support libraries. The few times I got something to render it was so far off that I ended up just running on the device. While this gave me accuracy is slowed my dev time down considerably. I happened to complain about this in one of the Xamarin Support Slack channels I frequent when a fellow dev offered some advice that showed me how to use Android Studio to do the design work. I knew I had to share this.

1) Assuming you have a pre-existing Xamarin Studio solution create an empty Android Studio project somewhere away from the Xamarin project.  I am using a directory called Test while my main code resides in my Projects directory.

2) Once you have setup the Android Studio project open the build.gradle file under your Gradle Script section. Hint: you want the one Module: app.

Within this file, under the android section, add the following block:

sourceSets {
    main {
        res.srcDirs = ['/path/to/Xamarin/Resources/Directory']

.csharpcode, .csharpcode pre
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
background-color: #f4f4f4;
width: 100%;
margin: 0em;
.csharpcode .lnum { color: #606060; }

3) The directory may reload on its own (may have to use Sync Now), if it doesn’t restart Android Studio.

4) Open a layout file. Notice you WILL have to use the .xml extension as Android Studio will not recognize .axml (not sure why Xamarin uses this extension).  You know have full access to the designer. You can freely change themes and use the AS designer to layout and preview your layouts.

Note: you may experience rendering problems or controls missing. I did so I added the following to my dependencies/compile section

compile  '',

.csharpcode, .csharpcode pre
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
background-color: #f4f4f4;
width: 100%;
margin: 0em;
.csharpcode .lnum { color: #606060; }

Hopefully in the future, Xamarin releases a better Android Designer, I would count on it though. I am still having some problems getting this to work fully but the designer has already saved me about an hour with my design work.

Understanding Workflows

In the previous post, I explained the basics of getting Bitrise up and running with a very basic build. I explained the various default steps that are included and the basics of triggers. Now I want to get more in-depth on workflows and triggers.

What is a workflow?

At the very heart of every workflow is the YAML file, bitrise.yml. You can access this file through the Manage Workflow option. This is, in essence, your Bitrise configuration. You can freely distribute this file if you want a client to setup your same build configuration elsewhere; we actually just did this for a client that we finished an engagement with.

Here is a chunk from the workflow we created previously:


If you read through this and consider the current configuration, you can see that parts easily map to the Web components you have been interacting with. I want to call attending to default_step_lib_source.

One of the great things about the way Bitrise is organized is the way steps are used. They are basically downloaded when each step is executed its source is downloaded from a Git repo (in this case the default is listed above). This being the case, you can add your own steps or customizations of existing steps from your own repository; this is also what allows Bitrise to run locally via its CLI implementation. My plan is to go through how to create your own custom steps in a later article; however, this is still something I am learning.

At the end of the day, a workflow really is just a collection of these steps downloaded on command and executed against the code stored on the virtual machine.

Building a a Workflow

Bitrise does a great job giving you a working workflow out of the box. The default one does what you expect and can serve well for continuously integrating your code. In general, the start of a workflow must do the obvious things such as authenticate itself, get the code, and then perform any other operations ahead of building it; for example with a Xamarin project you are going to need to use the User Management step.  However, once you get beyond the basic case, you might want to consider a few of the features that Bitrise offers.

The first of these is the idea of subworkflows. With subworkflows, larger workflows can be comprised of smaller workflows; its like coding, we want to reuse things where appropriate. And if something changes with the build process, better to change it in one area than across many.

To show you what I mean, click the + icon next to primary in the Manage Workflow view. Name of the new workflow whatever you like (I will name mine prepare). Once this is complete you will see this new workflow listed next to primary.


By default, Bitrise copies the steps in the currently selected workflow into the new one, so this will come prepopulated and look the same as primary.

For this exercise, go back to primary and delete all of the steps (select each one individually and use the trash can icon) with the exception of Certificates and profile installer, Xamarin Builder (assuming your repo is a Xamarin project) and Deploy to

Hit Save and then use the interface to rename the primary workflow to CI. To do this, simply click on the workflow name in the tab, Bitrise will allow you to rename it inline.


Before we go farther, I want to point out a naming convention that I like to use. Main workflows (those that will be targeted by triggers) are capitalized, sub workflows (those that will not be targeted by workflows) use lowercase. This is my personal convention, you can use it if you like or develop your own; consistency is the most important thing.

Go now to the prepare workflow and remove the steps that are listed in prepare. Return to the CI workflow and create a pre-workflow phase. This is done by adding a subworkflow to run before the Main steps. (Add prepare).


I recognize, and so does the Bitrise team, that this looks awkward as the very first step in ANY workflow (sub or otherwise) is a “Preparation” step (there is also a clean up at the end). These steps are both smart enough to detect the presence of pre and post workflow phases and WILL NOT run until those workflows complete.

Hit Save and you are just about ready, head over the to Triggers configuration and clean up any extraneous triggers created by Bitrise (by default a trigger is created for each workflow name and that name is assumed to match a remote branch in your Git repo). For now you can add a specific branch name from your repo or stick with * to match all. The important thing is that this trigger kick off the  CI branch (so specify CI for Triggers Workflow).


About Pull Requests and Order of Operations

While adding your triggers you may have noticed a couple things: 1) Triggers can be added in any order you desire and 2) when creating a trigger you have the option to select whether a pull request triggers the workflow.  Let’s talk about these.

Bitrise triggers are order based which is to say the first pattern matched is the one that fires. So in this case, having * first would prevent any other workflow from ever firing; * matches all so the matcher would never get passed this match.

Many teams utilize pull requests (West Monroe certainly does) as a way perform code reviews of code entering the code base. At West Monroe, we often do these when code enters feature branches allowing Senior Developers to review the code and ensure that nothing heinous is being coded. When you check this box, these pull requests will triggers a build as well. This is a very useful feature as it allows the build server to validate the code will be valid if allowed into the code base (including running the unit tests). This greatly speeds up our process and allows the reviewers to focus on the code and not have to worry about whether it builds or not.

How does West Monroe use workflows?

At West Monroe our workflows are triggered with this configuration, though it varies project to project:

  • task/* – triggers CI – used to validate a remote task branch being developed for a feature. This is optional and only used on certain projects
  • feature/* – triggers CI (pull requests build) – validates the feature and generates a developer build that can be downloaded by local QA staff (not distributed to the client)
  • bugfix/* – triggers CI – similar to task, identifies code which is applied to fix a known bug found in a stable version of the code
  • QA – triggers QA – kicked off by a merge of code into itself. Generally this is one or more features being added to this branch. This process generates a build that the client receives for QA
  • stable – triggers Stable – kicked off by a merge of code into itself. This code is one or more approved feature branches (code that has passed QA testing). This generates a build for client stakeholders and the team demos from this code at the conclusion of each sprint

By utilizing workflows and subworkflows, West Monroe is able to managed an automated build and distribution process driven by the fundamentals of Scrum and Agile. The clients receives builds throughout the sprint and provides validation and feedback that guides the team. At the end, the client receives a stable build which can be shown to stakeholders to yield additional feedback. Because only Done items reach this build, the client is able to dictate the features in each build.

App vs Workflow Environment Variables

The final point for this entry is in regard to variables. When you setup your Bitrise project the process forces you to define environment variables, depending on your target platform, for Xamarin they include: BITRISE_PROJECT_PATH, BITRISE_XAMARIN_CONFIGURATION, BITRISE_XAMARIN_PLATFORM. But you can define more, and I often do, especially when you start including other integrations outside the norm (talk about this next time). But what is important is to understand scoping.

My general practice is the default values for my variables are based on what I would need in CI (my lowest level build). Once I get into other workflows (QA, stable, master, etc) I would need different values that I want to feed the build process (for example, a different Xamarin Configuration to force my code to build a certain way) to alter it for that build. In cases like these you can use Manage env. vars to override your existing variables.


Regrettably, and Bitrise knows this, this interface is awful. I recommend copying the name of the variable you wish to override before entering since you will have to specify it exactly to get the override. Remember, even in subworkflows, it is the local Environment variables which take precedence. This being the case, the best way to avoid confusion is NEVER define environment variables for subworkflows, it will cause you pain and create confusion.

You can also define static values in your steps directly, this makes sense in some cases, but its something I try to avoid. It should be noted that Bitrise does not, as far as I know, have a secure way to store credentials, so for now the best way is to limit access to the build server.

So that is it for workflows, hopefully that helps explain them. Until next time.

Getting Started with Bitrise

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.

Welcome to Bitrise

Continuous Integration (CI) was something I learned about during the first years of my undergraduate study in college; right about when I first began to become acquainted with Agile. Since then, I have always sought to understand its value and had the fortune to work with great teams at great organizations that embraced it to one degree or another.

Since joining the West Monroe mobile team we lacked such a solution and our attempts to set up such a system was met with either failure or a complexity that required more maintenance than it was worth (VSO and OSX Server specifically). That is why when I came across Bitrise at Xamarin Evolve 2016, I was very interested. Since bringing it back to West Monroe our productivity on developer projects has increased by orders of magnitude and all teams are now embracing CI as an integral part of our delivery process. It has had such an impact on it that I figured discussing it here would be help others seeking similar solutions.

What is it? And how much will it cost?

The first thing to understand is Bitrise is, primarily, cloud based. Build request spawn virtual machines which are spun up and perform a series of steps. At the termination the machine is, ultimately, destroyed. Bitrise can ALSO be run on-premise if desired using the Bitrise CLI, but quite honestly the cloud option seems to be the perfect option for most scenarios. Pricing wise, Bitrise can be used for free if you keep your team to 2 team members and do less than 200 builds per month with only a 10m time limit per build.

One limitation to the free plan is the single concurrency for builds; makes it highly undesirable if you are working on multiple separate projects. With single concurrency only ONE build can be in process at a time, so if a lot of work is going it can quickly stack up.

But is it easy?

If you are like me and have EVER dealt with CI systems in the past you know that, for the most part, its not an easy chore. The systems are all different and any one of a million things can go wrong. Honestly, if you intend to do DevOps at all you have to understand all of the pieces in the puzzle. From compiling and building, to the use of profiles and build configurations, to understanding how users will interact with other tools.

While Bitrise has a learning curve, the documentation is very good and the team keeps a regulation communication channel open via Slack; I have personally spent time talking over issues I have had with their CTO Viktor. All of them are nice guys and work hard to ensure a quality product. And, compared to other systems I have used, it is extremely easy. During presentations I can go from no builds to a complete CI type build in under 10m using Github.

So how do I get started?

If you want to give a shot head over to and sign up. Take it for a test spin and use to get access to the Slack channel. I am on there most of the time as well (xximjasonxx). As for the more technical gist, I am going to do another article in the coming days on the standard setup and then I want to cover more of the topics in-depth. As I am the main DevOps guy for the mobile teams at West Monroe, I feel it’s a good idea to make sure I have this knowledge in many places in case I get hit by a bus Smile


Testing with Xamarin

On Monday, June 6, 2016 I will be debuting a new talk at Chicago Coder Conference 2016. The talk focuses on much of my research into UI Testing using Xamarin’s UI Testing framework. In addition, I will also talk about my experiences with unit testing both as a means to test application code and to validate UI functionality using the Moq library. UI Testing is a crucial step in the mobile application development process because of the disparity between devices, especially on Android. This talk will not just talk about it but will also show them working and tips for setting them up. I also hope to have a solid discussion around the various levels of testing and what goals are to be achieved.

Current slide deck and code are on my GitHub:

I look forward to seeing you at the talk. I also plan to give this talk again at a future session of the Chicago .NET Mobile User Group.