1. Why an Automated Pipeline?
An automated pipeline , continuous integration (CI), and continuous delivery (CD) are all terms that describe the process and tools that help you compile and deliver your software in an automated way. Since the software publication process remains largely the same, you do not have to repeat it manually every single time you want to push out a new version. Repetition is something people are not really good at, but computers are well suited for doing the same thing over and over again.
In this chapter, you will learn about the high-level terms that will be used in this book. Moreover, the chapter will explain why it is a good idea to set up a development pipeline of your own.
While the concept of an automated pipeline is far from new, it does have some interesting challenges when it is combined with the new world of mobile apps. The ecosystem of the different app stores differs from traditional desktop and web applications in terms of the freedom you have as a developer to control the environment on which your app will land. Also, it requires some specific handling to create a package that is accepted by the different app store vendors. These are all topics that we will look at throughout the course of this book.
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 clients 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 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.
