What Is Continuous Integration ?

“It works on my machine” is a phrase you will hear a lot when working in software development.

You can get away with that while working alone, when you are responsible for every single piece of code in your app. But when you start working in a team or have to set up a new development environment, there is a chance that you will forget to check in a file, reference a library from somewhere on your hard drive, and so on. These examples would all be causes for your app not being able to build anywhere besides within your specific development environment.

In addition, like every developer, you integrate your full code each time, including the unit tests for your app. Every time before you check in a new piece of code, you run it to see whether everything still lights up green, review the code coverage stats, and write new tests as you go. (You do that, right?) How awesome would it be if all of that testing work could be done for you automatically? You do not have to memorize a list of things you have to do or must not do before you are about to check in. Instead, you just get a signal when something is going wrong.

Finally, one of the things each developer learns over time is that no matter how good you are, you still have bad days and make mistakes like a real person. There really is just one thing you can do about that, and that is to get some feedback about the mistakes as early on as possible so you can fix them before anyone notices.

Well, continuous integration can help you with all three of these situations. CI encompasses a great number of possibilities to ensure the quality of your app. Basically, it does what it says: CI integrates your code continuously with the rest of the code already there, whether that code has been enriched by other members of your team or is just code that you checked in earlier .

With CI, a version of your app will be created with all the latest sources available at that time, and while doing so, the process will let you know if it still compiles.

From there you can start expanding your build process by letting your unit tests run, sending your app through automated UI tests, loading tests, copying a file to another location, transforming your configuration files, generating a build number, and doing anything else you can think of. The rule of thumb is that anything you can run from a command line can be integrated in your builds.

One of the best and most complete solutions to support you with CI and CD (along with many more features) is Visual Studio Team Services (VSTS) by Microsoft. If you have ever worked with Team Foundation Server (TFS) as a source control tool, you should feel right at home.

VSTS is available online, hosted in an Azure variant of TFS, and actually gets new features before the on-premise TFS does. In addition, it is free (to some extent, of course!).

Besides acting as a source control solution, VSTS has a lot of possibilities. One is the automatic building of your source code, which is one of the aspects this book will be focusing on. Besides that, you can manage your work with Scrum or Kanban boards, edit your code from the web portal, work with branches, search code, push NuGet packages, and do much, much more.

While VSTS is a complete environment and leaves you with little to wish for, there are other good services out there like Bitrise and Fastlane. The focus of this book will be on Microsoft products and thus VSTS, but the appendix includes some pointers to alternative tools that are worth checking out.

What Is Continuous Delivery ?

Imagine you are in the middle of coding the next functionality in your software or maybe starting a whole new project altogether and suddenly the tester on your team pops up at your desk with a possible bug in your app. Or, just when some big new functionality is only halfway done, your manager finds you and requests the latest version to show to the client’s chief executive officer (CEO). While this is something you want to do, you cannot deliver a stable version without rolling back hours of work, and even then you are hoping that you did not forget anything.

These are just two examples in which continuous delivery can prove to be very useful.

As a logical extension of the continuous integration pipeline, CD takes the bits that have been generated while building (also known as artifacts) and delivers them to a certain audience of your choosing. This audience can be a tester on your team, a group of predetermined beta testers, or maybe your girlfriend, but it can also be no one. The fact that you can deliver continuously does not mean you have to. The fact that delivering to specific environments works is a quality check in itself.

The environments can be the different channels with which you supply your shippable app to end users. Which channel you want to use depends on the requirements you have and the end users you are targeting.

In Chapter 7 you will look at HockeyApp, which is great for distributing your apps in a unified way for all platforms to your end users. It also helps you to collect user feedback, and it has a great software development kit (SDK), which allows you to retrieve detailed crash reports remotely, even for desktop apps.

HockeyApp is an essential tool for the modern developer to detect bugs almost before the user does. However, it cannot be used as a production environment in the case of apps because of the different vendors; Apple, Google, and Microsoft require you to distribute your app though their channels.

The different app stores do have some functionality that allows you to send out test versions. However, the features they offer vary, and more importantly, you, as the developer, need to go through three kinds of app store hoops to get what you want.

As mentioned earlier, there will be a point that you cannot get around the app stores anymore as you will have to distribute your production version through them. However, this does not mean you cannot provide these app stores with your app in an automated way.

Why Do You Need an Automated Build Pipeline ?

A “fully featured build pipeline” sounds like something that only big companies can take advantage of, or can even afford. While this may have been true at one point, it sure is not true these days.

So, whether you are a sole developer working on your million-dollar idea, you are already working at a startup with limited funds, or you are working at an established company, you can get started for free on everything that will be described in this book.

There is a possibility that you have one question at this point: why do I even want this? If you are not convinced by the two previous sections, then keep reading.

As mentioned, an automated build pipeline takes a lot of repetitive work out of your hands instantly. From the moment you set up automatic builds, you will benefit, because you will be notified in real time if and when something goes wrong while building your new code. No more will you go hours, days, or even weeks without noticing that the code on your versioning system is in fact unbuildable. That alone should be reason enough to want to set this up.

But the benefits do not stop there. Building is just one thing; there are infinite more tasks that you can add to automated builds. Microsoft has added a marketplace to VSTS, which enables developers to create their own tasks that can be incorporated into a build. There are already a lot of useful packages in there, but if that specific one is not there, you can just create it yourself. This enables you to run any kind of test or diagnostic on your code or app to ensure its quality.

This brings us to the next big advantage: integrating tests. With continuous integration comes testing. While unit testing is probably the first type that comes to mind, you can also integrate functional tests with Xamarin Test Cloud to test your app on thousands of physical devices. This way you can ensure that with each check-in the quality of your software is at least as good as it was before (and ideally the quality has gone up!).

With an automated build pipeline, you get all of this integrated into one place where you can consolidate all the results and build dashboards to inspect the state of your app with just one glance.

When you have this all worked out, then why not do the same for delivering all this to your users? Constructing this process is less work than setting up the automatic builds but takes a lot of work out of your hands nevertheless. To clarify, Figure 1-1 shows an ideal situation.

Figure 1-1. The ideal situation

In the top left, there is you, working on code and creating great apps. Whenever you are ready, you check your code into VSTS, which will trigger a build. In that build, your app will be compiled to see whether it still works. When it does, the unit tests you have in place will run. If everything is still OK, your app is transferred to Xamarin Test Cloud, and the automated UI test scripts are executed. If anything goes wrong at this point, it will be reported to you.

In that case, you can fix it, and the whole cycle will start again.

If all the builds and tests finish successfully, the resulting app will be released to HockeyApp. Depending on how you want to configure things, you can send your app to users from there, which can be testers of your company, and then gradually roll it out to several other groups. If and when all of these groups approve, you can send it to the actual stores. The final step in the upper right of Figure 1-1 is what it is all about: ecstatic users who love you .

If you have published apps before, you know how much work it can be. It includes identifying all the test users, making sure the right people get the right version, uploading a separate version for each platform, and compiling all the gazillion different icon sizes and screenshots to go with it.

Then, when you finally wrestle through that whole process and decide to send your app to production, you wait for the review process to complete, which can take days before showing up in the app store.

No more! You go outside of the normal app stores with HockeyApp so you can deliver your test versions in a unified way, instantaneously, while gaining a singular way to collect feedback from your users and detailed crash reports.

Also, with the release features in VSTS, you can set up a chain of command to transport your app from environment to environment. This is a powerful tool to give only designated people control over when and where to release the app, even all the way up to production! If you set up VSTS properly, you do not even have to worry about releasing the app yourself anymore.

All of this can be done automatically in a repeatable way so you never forget any step, because it won’t be you who is doing it. How to set up an automated pipeline and use it to your full advantage is what this book is all about .

Final Thoughts

Now that you know what continuous integration and continuous delivery are all about, you can start getting your hands dirty. In this chapter, you learned at a high level what CI and CD can do for you, learn about the terminology that comes with them, and saw a scenario to work toward. By the end of this book, you can look back at this scenario and conclude that this is what you have achieved.

In the next chapter, you will learn how to prepare your development environment to begin implementing continuous integration and delivery for your own apps. You will set up some accounts, get an introduction to VSTS, and install the prerequisites needed.