Ryan J. Salva

Build the Ideal Cordova Dev Environment

Sun, 15 May 2016 00:00:00 +0000

Laptops are very personal, very private things. As the days and months pass by, little piles of messes accrue in the file system that are uniquely our own. At the same time, a developer’s laptop is also finely tuned for productivity. As someone who has developed quite a few mobile apps using Apache Cordova, I thought it might be fun to share some of the optimizations I’ve made to my laptop for Cordova development.

I haven’t found the ideal dev environment yet – I’m always tweaking things – but it’s a beautiful mess. This post describes how to build a good dev environment for cross-platform development targeting iOS, Android and Windows.

Hardware
Node Version Manager (NVM)
Globally Installed NPM Packages
VS Code
.bash_profile
Android SDK
Android Emulator
Parallels
Visual Studio
Remote Build Agent

If you’ve got suggestions for improvement, I would looooove to hear them. 💖 Share your tips in the comments section below.

Hardware

If you’re targeting iOS, you need a Mac somewhere in the equation. Likewise, if you’re targeting Windows, you need Windows. Until Apple changes their licensing, the only way for the two systems to co-exist on the same hardware is by running Parallels on a Mac device. So, that’s what I do.

Hardware: 13” MacBook Pro with all the RAM and disk upgrades available.
Operating Systems: Mac OSX El Capitan and Parallels running Windows 10.

If it’s not an option for you to develop on a Mac, there are plenty of cloud build solutions available (e.g. PhoneGap Build, MacInCloud, Mac Stadium), but since this tutorial is focused on building a local development environment, we’ll leave that subject for another day.

Mobile Device Library 📱

For local testing, I keep a library of devices and operating systems representative of the general population. My goal isn’t to test against everything, but to cover the “big players.”

iPhone 5
iPhone 6s
Samsung Galaxy S4
Nexus 7
Windows 950

Node Version Manager (NVM)

Besides Cordova itself, Node Version Manager (NVM) is the single most important piece of software for you to install. Not all versions of Node and NPM are compatible with all versions of Cordova. In fact, it’s kind of a complicated mess:

Cordova	Node	NPM
<5.3.3	^0.12.0	^2.0.0
>=5.3.3	~4.0.0	^2.0.0
>=5.4.1	^5.0.0	^3.0.0

NVM allows you to install and manage multiple versions of Node + NPM simultaneously on the same machine. If you’re going to maintain multiple projects over time, NVM allows you to continue using Cordova 4.x with Node 0.12 on old maintenance projects, while using the latest-and-greatest versions of Node + NPM on your new projects.

Also, because NVM installs packages in the user’s local directory where you have ownership rights, permission errors caused by installing NPM packages with sudo go away. For an eloquent explanation of why you should avoid using sudo with npm , read this post from Explosion Pills. The relevant part:

Using sudo npm install (and potentially sudo npm <anything>) is a bad idea ™. This is an issue for at least a few reasons:

npm install has the ability to run arbitrary scripts. Due to how npm is set up and the fact that you can alter the registry and it can use DNS, it is possible that you will accidentally install a malicious package in general, install a malicious package masquerading as a perfectly valid package, or install a package with good intentions that may run scripts that are somehow detrimental to your system if run as root.

Running sudo npm install (without -g) will create a local directory that can only be altered by the root user. This can really screw things up for you if you try to do npm <something> in the same directory or project later on.

Even sudo npm install -g with a valid installation target can mess things up for you and make it hard to use npm without sudo under some circumstances in the future – particularly if you change your npmconfiguration midstream. The root user can and will create files in your npm cache and potentially a file like ~/.npm/_locks, and future npm installor npm install -g will give you the dreaded EACCES error.

NVM makes it so that you never have to use sudo again. Installing it is easy. Simply follow the instructions on the NVM website.

# install nvm
curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.31.1/install.sh | bash

# confirm that nvm is installed
nvm --version

# install the latest stable release
nvm install v4.4.4

# make it the default
nvm alias default v4.4.4

I recommend using the last stable version of Node for Cordova development. Remember that even (as opposed to odd) version numbers are officially stable and “Long Term Supported.”

Globally Installed NPM Packages

When building a new machine, there are a few utilities that I expect to use in (almost) every project. Rather than install a duplicate instance in each project directory, I prefer to install these npm packages globally:

Package Name	Why?
cordova	This is a Cordova development environment, right? Required.
ionic	Ionic delivers silky smooth, good-looking UI and provides a good starting point for most projects.
taco-cli	TACO provides an array of utilities for Cordova development, including `--livereload` which auto-refeshes the webview on save for browsers, emulators and devices
code-push-CLI	Code Push is my preferred service for publishing updates without re-submitting to the app store.
typescript	TypeScript provides a much better code editing experience than JavaScript alone with auto-complete, code refactoring and access to future JS features (e.g. decorators) that aren’t available in ES6 today. It’s also recommended by the teams building Ionic and Angular.
eslint	Eslint will help you enforce a sensible coding style guide without being a jerk about it.
eslint-plugin-standard	This plugin forms the foundation of our coding style guide.
git	Source control is kinda necessary. Required.
gulp	Gulp is a build task manager. It might be a little old school, but it’s simple and gets the job done. You might prefer Browserify or Web Pack.
ios-deploy	Enables ios-build.
ios-sim	Enables launch to the ios simulator without opening xcode
remotebuild	RemoteBuild is a simple node server that allows your Windows VM to delegate iOS builds to Xcode and launch the simulator. In other words, it allows you to build for iOS from your Windows machine.

You can install all of them at once by executing:

npm install -g cordova ionic code-push-cli typescript eslint eslint-plugin-standard git gulp ios-deploy ios-sim remotebulid

VS Code

I use VS Code as my primary editor. It’s based on Atom, but don’t be fooled into thinking it’s an Atom clone. Besides being significantly faster – especially with large projects – Code has a number of advantages:

Large ecosystem of plugins, extensions and themes
Git integration
Built-in debugger
Wicked good intellisense and code refactoring features

To the default installation, I add the following extensions:

Extension	Why?
Cordova-tools	Adds both Cordova and Ionic CLI integration, debugging tools for iOS/Android, intellisense for plugins and code snippets for Ionic UI controls.
ESLint	This plugin leverages the ESLint npm packages installed above. Style violations receive a red squiggly in the code editor. You can right-click on any of these errors and auto-fix all the errors in your project.
TSLint	TSLint provides the same features offered by ESLint, but for TypeScript rather than JavaScript.

To install these extensions, simply invoke the Command Pallette with Command+P (Mac) or Control+P (Windows) and type:

> ext install cordova-tools
> ext install eslint
> ext install tslint

Edit, Preview and Debug Loop

Like most developers, the vast majority of my time is spent in a quick, iterative loop where I progressively (1) edit code, (2) refresh the webview, then (3) debug and inspect the result. There are lots of tricks intended to shortcut steps within this loop – mostly by auto-refreshing the webview on save.

I accomplish this today using either taco run ios --livereload or ionic serve --lab depending on the circumstances.

Generally speaking, I use taco run [platfrom] --livereload any time I want to deploy to an emulator or device where (a) all the plugins work and (b) fidelity is high. Meanwhile, I reserve ionic serve --lab for those situations where I merely want to work quickly on a desktop browser and don’t need plugins or perfect simulation.

.bash_profile

So much magic happens in the terminal. It’s a shame that it’s so damn ugly and illegible by default. A lot of people choose oh-my-zsh, but I’m quite fond of my custom .bash_profile assembled from a handful of online tutorials and pimped out to match my personal tastes. You can find my .bash_profile here: http://github.com/ryanjsalva/bash.

The basic strategy is to declare nothing directly in .bash_profile, but instead break the file into multiple modules which I import. You can learn a lot by just looking at the code, but I’ll point out a few important features below.

.bash_nvm

This file is required to use NVM, but it also adds command completion to your terminal. To see completion in action, type “nvm” in the terminal, then tab to complete partial words or double-tab between words to get a list of all the actions & arguments available.

# export NVM directory
export NVM_DIR="$HOME/.nvm"

# enable command completion
[[ -r $NVM_DIR/bash_completion ]] && . $NVM_DIR/bash_completion

# source NVM
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"

.bash_finder

This file is totally for the “power user.” 💪 It defines shortcuts for common terminal tasks. For example, these lines provide an easy way to show/hide all the hidden system dot files like .gitignore

# Show hidden files in Finder
alias showFiles='defaults write com.apple.finder AppleShowAllFiles YES; killall Finder /System/Library/CoreServices/Finder.app'

#   Hide hidden files in Finder
alias hideFiles='defaults write com.apple.finder AppleShowAllFiles NO; killall Finder /System/Library/CoreServices/Finder.app'

I also include several shortcuts to make Terminal navigation easier:

# Opens current directory in MacOS Finder
alias f='open -a Finder ./'

#   'cd' to frontmost window of MacOS Finder
cdf () {
    currFolderPath=$( /usr/bin/osascript <<EOT
        tell application "Finder"
            try
        set currFolder to (folder of the front window as alias)
            on error
        set currFolder to (path to desktop folder as alias)
            end try
            POSIX path of currFolder
        end tell
EOT
    )
    echo "cd to \"$currFolderPath\""
    cd "$currFolderPath"
}

# Always list files/folders after cd
cd () { command cd "$@"; ll; }

# Go Home
alias ~="cd ~"

# Clear terminal display
alias c='clear'

# Find executables
alias which='type -all'

# After you create a directory, cd into it
mkdir() { command mkdir -p "$1"; cd "$1"; }

# Move a file to the MacOS trash
trash () { command mv "$@" ~/.Trash; ll; }

# Full Recursive Directory Listing
alias lr='ls -R | grep ":$" | sed -e '\''s/:$//'\'' -e '\''s/[^-][^\/]*\//--/g'\'' -e '\''s/^/   /'\'' -e '\''s/-/|/'\'' | less'

# Create a ZIP archive of a folder
zipf () { zip -r "$1".zip "$1" ; }

You’ll find many more shortcuts defined in my GitHub repository, so be sure to look there for inspiration.

.bash_cordova

This little gem comes from the Apache Cordova project and provides completion for Cordova CLI. Tab to complete partial words or double-tab between words to get a list of all the actions & arguments available.

.bash_network

Again, this is for the power user and helps you get information about your local network.

# Show all open TCP/IP sockets
alias netCons='lsof -i'

# Flush out the DNS Cache
alias flushDNS='dscacheutil -flushcache'

# Display open sockets
alias lsock='sudo /usr/sbin/lsof -i -P'

# Display only open UDP sockets
alias lsockU='sudo /usr/sbin/lsof -nP | grep UDP' 

# Display only open TCP sockets
alias lsockT='sudo /usr/sbin/lsof -nP | grep TCP'

# Get info on connections for en0
alias ipInfo0='ipconfig getpacket en0'

# Get info on connections for en1
alias ipInfo1='ipconfig getpacket en1'

# All listening connections
alias openPorts='sudo lsof -i | grep LISTEN'

# All ipfw rules inc/ blocked IPs
alias showBlocked='sudo ipfw list'

# My external ip address
alias myip="dig +short myip.opendns.com @resolver1.opendns.com"

# My local/internal ip address
alias localip="ipconfig getifaddr en0"

.bash_prompt

This prompt makes me happy. 😸 It does four things:

Adds color
Identifies the current version of Node (super-important when using NVM)
Identifies the current branch when navigating a directory under source control
Adds emoji flare to make the command line a little more rock ‘n roll

function my_prompt(){
    NODEV=`node --version`
    NVMV="[node:$NODEV]"

    GIT=''
    BRANCH=`git branch 2> /dev/null | grep \* | awk '{print $2}'`
    if [[ "$BRANCH" != "" ]]; then
    GIT="[git:$BRANCH]" 
    fi
    printf "\n$txtred$PWD $txtwht$NVMV $GIT$txtrst\n"
}

PROMPT_COMMAND=my_prompt
export PS1="⚡ "

Android SDK

It goes without saying that if you want to build for Android, then you need the Android SDK. Unless you want develop custom plugins, you don’t need Android Studio. Instead, keep it “light” and just install the Command Line Tools (a.k.a. the SDK).

Once you’ve installed the Android command line tools, go to your Terminal and open the SDK package manager by typing android. Google encourages you to download and install a bunch of stuff you don’t need. Instead, uncheck everything and only select the following options:

Package	Why?
Tools (everything)	These are your build tools. If you want to build an APK, you’ll need everything here.
Android [version] (API [number])	SDK Platform

Pay particular attention to the last option in the list: Intel x86 Emulator Accelerator (HAXM Installer). This option is critical because the Google emulator is slooooooow. 🐌 Unless you want to pay $400+ per year for the Genymotion emulator on your Mac, HAXM is your best option to improve Android emulator performance. But it requires an extra step to complete installation.

After you’ve installed all the API packages, open ~/Library/Android/android-sdk-macosx/extras/intel/Hardware_Accelerated_Execution_Manager/IntelHAXM_6.0.1.dmg to finish installing HAXM. Follow the installation instructions accepting all the defaults, then you’ll be ready to start your first emulator.

Android Emulator

Whenever possible, I use a tethered device because they are faster and of higher fidelity. But if I don’t have a device handy or need to test on a version of the OS that’s not in my device library, then to-the-emulator I go.

Google’s Android emulator doesn’t come with any pre-configured devices, so you have to create one first. From the terminal, run android avd to open the Android Virtual Device Manager. Under the “Android Virtual Devices” tab, click “Create” and configure your first device as shown below.

Setting	Value	Why?
AVD Name	Nexus-7	Just pick something short and descriptive
Device	Nexus 7	This is a good catch-all device representative of tablets.
Target	Android 6.0 - API Level 23	A recent version of the OS. You’ll want to create emulators for older versions, too.
CPU/ABI	Google APIs Intel Atom	?
Keyboard	Checked	?
Skin	Skin with dynamic hardware controls	You can use the controls to change device orientation, “shake” the device, click the home button, etc.
Front Camera	Webcam	I prefer to use my laptop’s webcam over the Max Headroom floating ball.
Memory Options	RAM: 1024, VM Heap: 32	?
Internal Storage	?	?
SD Card	?	?
Emulation Options	?	?

Once you’re done configuring, you can go back to the terminal and launch your emulator with:

# start the emulator
emulator @Nexus-7 &

The & at the end of that command means, “open in the background.” Observe that the emulator… well, it’s not fast, but it’s not horrifically slow because Intel’s HAXM is speeding things up:

Other Apps on the Mac

App	Why?
Xcode	Build tools for iOS
PhotoShop	Graphic Design (bitmap)
Illustrator	Graphic Design (vector)
Hellium	For when I want to have a video playing while I work
MAMP	Local server for rare occasion when I’m coding PHP
Slack	Team collaboration

Configuring Parallels

Once you’ve setup your Mac, the hard part is over. Windows is surprisingly easy to install and configure. When setting up your Windows virtual machine, Parallels will give you the option to optimize for “Software Development.”

While you can preserve many of the defaults for this preset, you may want to make a few tweaks. I’m not going to provide an exhaustive list of every setting since many merely depend on personal preference, but I’ll highlight a few of the important ones:

Tab	Category	Name	Value	Why
Options	Optimization	Performance	Faster virtual machine	Your VM will always be the process starved for resources
Options	Optimization	Enable Hypervisor	Checked	Speeds up emulators running inside the VM
Options	Optimization	Tune Windows for Speed	Checked	Speed is more important than fancy animations
Options	Full Screen	Use OS X Full Screen	Checked	It took me a while to figure out how to get the resolution right, so I’m including it here.
Options	Full Screen	Allows Windows 10 to set display gamma	Checked	See above
Hardware	CPU & Memory	Processors	Half	As a general rule, allocate half of your available processors to the VM
Hardware	CPU & Memory	Memory	Half	As a general rule, allocate half of your available RAM to the VM
Hardware	Graphics	Graphics Memory	Quarter	As a general rule, allocate one quarter of your available GPU to the VM
Hardware	Graphics	Retina Resolution	Best for Retina	It just looks better/crisper
Hardware	Graphics	3D acceleration	DirectX10	At least on my machine, this does some weird magic that makes full screen look “right”
Hardware	Network	Source	Shared Network	Makes it possible to delegate builds to Xcode and VS from either side of the machine

Visual Studio

Once you’ve got Windows 10 up-and-running, you’ll want to install Visual Studio which includes all the build tools for Windows Universal Apps. Visual Studio 2015 Community Edition is “free for individual developers, open source projects, academic research, training, education, and small professional teams.” It also includes the Tools for Apache Cordova (a.k.a. “TACO”). Full Disclosure: I’m the product manager for TACO, so… yah, they’re kinda awesome.

“Free for individual developers, open source projects, academic research, training, education, and small professional teams.”

To install TACO, select it from the optional components during VS setup. If you already have Visual Studio installed, you can add TACO by going to “Change or Remove Programs” in the Control Panel, right-clicking on Visual Studio and selecting “Change.”

Visual Studio will install all the Windows and Android SDK build tools in your Parallels instance, so all the setup work you had to do on the Mac… it’s not necessary for Windows.

Local vs. Global

By default, VS installs a “sandboxed” version of Node + NPM similar to the one used by NVM on your Mac. As of this writing, Visual Studio installs Node 0.12 and NPM 2.2 because they are universally compatible with all versions of Cordova <=6.x. While I recommend using the sandboxed version, you can use the globally installed versions of Node + NPM by changing the settings in Tools > Options.

Remote Build Agent

Code on your Mac should be accessible to Windows and vice versa so long as Parallels is running. You can build from the command line or use Visual Studio’s built-in F5 launcher. If you want to build from Visual Studio, but deploy to an iOS simulator or device, you’ll need to setup a remote build agent.

In essence, the remote build agent is a light-weight node server that runs on your Mac and listens for builds from Visual Studio. When it receives a build request, it marshalls the request to Xcode. Upon finishing the build, it can either return the IPA to Visual Studio or deploy it to a Simulator/Device.

This isn’t entirely relevant to setting up a local development environment, but if you ever need to share your screen with others (e.g. during a virtual meeting or while presenting on-stage), then there are two other essential tools.

Vysor.io screencasts your tethered Android device
Quicktime screencasts your tethered iOS device

Celebrate! 🎉

You’ve reached the end of another long blog post. Celebrate your victory with another song in the playlist. I recommend selecting a classic from the archives, “F**k and Run” by Liz Phair.

Maintain Separate Configs for Dev, Beta and Release Build Targets

Sat, 07 May 2016 00:00:00 +0000

This is part four of a four part series (😆 🎉 👏) and assumes you’ve already set-up continuous integration with our sample project. If you haven’t already, I highly recommend reading part one, Continuous Integration for Cordova Apps, where we setup the build server used in this tutorial.

Change Your App’s Configuration Based on Branch

In parts I - III, we used Visual Studio Team Services (VSTS) to setup build definitions for unit testing, beta testing and over-the-air updates. All three of our build definitions run using continuous integration on a single branch (i.e. the master branch). Consequently, every time we push a code change, all three of these build definitions run.

Android-Dev: runs Karma+Jasmine unit tests to ensure code quality
Android-Beta: distributes the app to manual testers via HockeyApp
Android-Release: distributes app updates to the public via Code Push

Frankly, this is bad. We don’t want to distribute a beta release every time there’s a feature check-in and we sure as hell don’t want to release in-development features to the public. To control what happens at check-in, we need a branching strategy. We need to run a different set of build steps depending on which branch receives the commit.

Two Big Advantages

By creating a unique branch for each release type, we gain two big advantages.

First, we can maintain a different set of config files for each branch – enabling us to use different API keys or service providers for each release type. For example, imagine that you want to use the “Staging” Code Push deployment key during development, but the “Production” deployment key when you release to the public. Using this technique, you can dynamically switch the keys during continuous integration.

Second, we can trigger different build steps for each branch. For example, we can run unit tests every time we push to the “dev” branch without actually releasing anything. When we’re ready for user feedback, we can release to beta testers via HockeyApp by pushing to the “beta” branch.

To realize our dream, we must:

Update the Source Code
1. Create a branch for each build definition
2. Create config files for each build definition
3. Add gulp tasks to move and rename the config files before build
Configure VSTS
1. Change each build definition to trigger based on branch
2. Source the build from the appropriate repository
3. Add a custom gulp build step within each build definition

Update the Source Code

Let’s start by creating three new branches at the terminal:

# create a dev branch to trigger CI unit tests
git checkout -b dev
git commit "create dev branch"
git push

# create a beta branch to trigger CI hockeyapp distribution
git checkout -b beta
git commit "create beta branch"
git push

# create a release branch to trigger CI codepush distribution
git checkout -b release
git commit "create release branch"
git push

# respect the proper code flow; start in the dev branch
git checkout dev

Right now, all three branches are a carbon copy of the master branch. Each branch can operate independently, but ideally the code should flow from dev to beta to release. Thus, we start by making all our changes in the dev branch.

Give each branch a custom config.xml

In a “normal” local development environment, Cordova build depends on a config.xml file in the root directory to define things like icons, splash screens and the App ID. To support different configurations for each branch, I’ve created a special /config folder with XML and JS files for each release type (i.e. dev, beta and release). Let’s compare a few lines from dev.xml and beta.xml to see what’s different:

Switch the Code Push Deployment Key

This code snippet from /config/dev.xml shows where we declare the Code Push deployment key.

<platform name="android">
    <preference name="CodePushDeploymentKey" value="YOUR-ANDROID-DEVELOPMENT-DEPLOYMENT-KEY" />
</platform>
<platform name="ios">
    <preference name="CodePushDeploymentKey" value="YOUR-IOS-DEVELOPMENT-DEPLOYMENT-KEY" />
</platform>

We don’t want to use the same key in both development and production, so we’ll use a different key in /config/release.xml

<platform name="android">
    <preference name="CodePushDeploymentKey" value="YOUR-ANDROID-PRODUCTION-DEPLOYMENT-KEY" />
</platform>
<platform name="ios">
    <preference name="CodePushDeploymentKey" value="YOUR-IOS-PRODUCTION-DEPLOYMENT-KEY" />
</platform>

Give each branch a custom Gulp task

Our release-specific config files are defined in code, but we still need to move them to a place where Cordova can find them at build time during CI. To move the config files dynamically, we’ll create a gulp task that VSTS can run immediately before Cordova build. Each gulp task will rename the config files and copy them to the appropriate directory. So, for example, gulp release will:

Rename release.xml to config.xml and move it to the project root
Rename release.js to config.js and move it to /www/js/

The ✨magic✨ happens in gulpfile.js:

// prepare for public release
gulp.task('release', function() {
    gulp.src('./config/release.xml')
    .pipe(rename('config.xml'))
    .pipe(gulp.dest('.'));

    gulp.src('./config/release.js')
    .pipe(rename('config.js'))
    .pipe(gulp.dest('./www/js'));
});

// prepare for beta distribution
gulp.task('beta', function() {
    gulp.src('./config/beta.xml')
    .pipe(rename('config.xml'))
    .pipe(gulp.dest('.'));

    gulp.src('./config/beta.js')
    .pipe(rename('config.js'))
    .pipe(gulp.dest('./www/js'));
});

// prepare for development environment
gulp.task('dev', function() {
    gulp.src('./config/dev.xml')
    .pipe(rename('config.xml'))
    .pipe(gulp.dest('.'));

    gulp.src('./config/dev.js')
    .pipe(rename('config.js'))
    .pipe(gulp.dest('./www/js'));
});

You can use the same technique to customize anything in response to a build definition. And as you might have guessed, the technique isn’t limited to XML and JS. You can do all sorts of things:

Change your app icon and splash screen to display a “beta” badge only in the beta release
Use a different API key for services like maps, analytics, data sync, etc. in production
Show features only in development builds

That wasn’t too bad, now was it? Take a break, catch your breath and regroup by playing a song in your headphones. I recommend “Street Lights for a Ribcage” by Sleepy Eyes of Death.

Configure VSTS

Our code is setup to dynamically rename and move config.xml using a Gulp task. Now, we need to automate the process using continuous integration in VSTS. For each build definition, we’ll add a Gulp build step to move and rename the config files. Then, we’ll change the trigger branch and source repository to match the branch.

Using the same instance of VSTS that you configured in Parts I, II and III of this series, login and navigate to the “BUILD” tab where you will edit the “Android-Dev” build definition.

Add a space-delimited array of Gulp tasks for dev sass test. In order, these will:

dev rename and moves /config/dev.xml to /config.xml
sass compile SASS to CSS
test execute our Karma+Jasmine tests

Under the “Triggers” tab, change continuous integration to trigger when code changes in the dev branch.

Under the “Prepository” tab, change the default branch to use dev branch as the source repository.

“Android-Beta” and “Android-Release” will follow a similar pattern. You can see a full list of the values below.

Build Definition	Gulp Tasks	Source Repository	Trigger Filter
Android-Dev	dev sass test	Dev	Dev
Android-Beta	beta sass	Beta	Beta
Android-Release	release sass	Release	Release

Checking Our Work

You’ve done all the hard work, now pluck the fruit of your labors. 🍊 In Terminal:

# trigger CI for "Android-Dev" by pushing a change
git checkout dev
git touch readme.md
git commit -m "triggering dev CI"
git push

# trigger CI for "Android-Beta" by pushing a change
git checkout beta
git merge dev
git push

# trigger CI for "Android-Release" by pushing a change
git checkout release
git merge beta
git push

When you return to the VSTS portal, you’ll find the CI builds waiting in the queue. Double-click on any of the builds to see the build output in real-time. Celebrate with a song in your headphones. I recommend “The Commander Thinks Aloud” by The Long Winters.

Mobile DevOps: A Four Part Series

Release Without Re-submitting to the App Store

Sun, 01 May 2016 00:00:00 +0000

This is part three of a four part series and assumes you’ve already set-up continuous integration with our sample project. If you haven’t already, I highly recommend reading part one, Continuous Integration for Cordova Apps, where we setup the build server used in this tutorial.

JavaScript’s Unfair Advantage

Mobile apps created with JavaScript (e.g. Apache Cordova, ReactNative) enjoy a unique privilege within app stores. Unlike compiled apps that developers can only update through the app store, JavaScript apps can download and install updates from any trusted server.

Imagine this: you’ve just released a major update when… BAM! The one-star reviews start pouring in due to a crashing bug. If you had to re-submit to the app store, you could be waiting days before the store approved and published your new package. By that time, many users will have abandoned your app. The nasty ones might have even written a few flaming store reviews. 🔥

With over-the-air updates, you can deliver bug fixes directly to your customers by downloading new assets (e.g. HTML, CSS, JS, images) from the cloud and replacing the files packaged with your app. In other words, you can deliver updates immediately and on your own schedule.

How does it work?

To understand how updates work, it’s helpful to get a high-level overview of the workflow:

The first time you publish, you submit the full app including both compiled code and web assets to the app store.
When you want to publish an update, you zip up your web assets (no compiled code) and publish them to the Code-Push cloud service. We’ll talk about different service providers in a moment.
On some event (e.g. deviceready, resume, button click), each mobile device checks the Code-Push cloud service for an update.
If an update is available, each mobile device downloads the update and replaces the contents of /www with your new code.

Of course, there are lots of optional detours along this path. For example, you could (1) give users the option to skip an update, (2) update a subset of files in /www, or (3) release to only a subset of users. The service itself is very configurable.

Is Apple really cool with it?

Anytime I speak about bypassing the app store, someone invariably asks if this whole thing is really kosher with the app stores. The answer is, “Yes! Yes! A thousand times, yes!” In fact, it’s written into Apple’s developer agreement (emphasis mine). The same goes for Android.

Service Providers

There are a number of plugins & services that make over-the-air updates possible. Cordova developers can choose between PhoneGap Hydration, Ionic Deploy and Code Push. Code Push also happens to be the defacto choice for most ReactNative developers, so our example will use it.

Let’s code (push)

Again, our tutorial will use the superfly sample project and Visual Studio Team Services (VSTS) setup in part one of this series.

Like other device capabilities, Code Push has it’s own Cordova plugin (cordova-plugin-code-push) which has already been added to our sample project. You can see the reference in config.xml:

<plugin name="cordova-plugin-code-push" spec="~1.6.0-beta" />

Create Your Code-Push Service

To register for the Code Push service, you must first install the Code Push CLI. From your terminal…

# install code-push globally
npm install -g code-push-cli

# sign up for the free code-push service
code-push register

This second command will open a browser where you should simply follow the registration process. As usual, it’s free to use, so don’t worry about pulling out the credit card. 💸

Manage Deployments

Once you’ve registered, go back to the command line where we’ll register our first app with the Code Push service.

code-push app add superfly

Code Push will return two deployment keys: Staging and Production. These keys are used to identify your app when making a request to the Code Push service and will be saved in config.xml. If you lose the key, don’t worry. You can retrieve it at any time by executing:

code-push deployment list superfly -k

Under most circumstances, you’ll want to deploy to iOS and Android separately. After all, if a bug fix is unique to Android, we don’t want to inconvenience iOS users with an unnecessary update. So, let’s prepare for the future by creating separate deployment keys for iOS and Android.

# rename the default Staging key for Android
code-push deployment rename superfly Staging Staging-Android

# rename the default Production key for Android
code-push deployment rename superfly Production Production-Android

# create a new Staging key for iOS
code-push deployment add superfly Staging-iOS

# create a new Production key for iOS
code-push deployment add superfly Production-iOS

# make sure we got it right
code-push deployment list superfly -k

Add the Deployment Key to Your App

You’ve created deployment keys for each platform. Now, it’s time to save those deployment keys with your app. Open config.xml in the superfly project and insert the Staging-Android and Staging-iOS deployment keys where indicated:

<platform name="android">
    <preference name="CodePushDeploymentKey" value="YOUR-ANDROID-DEPLOYMENT-KEY" />
</platform>
<platform name="ios">
    <preference name="CodePushDeploymentKey" value="YOUR-IOS-DEPLOYMENT-KEY" />
</platform>

Notice that we’re hard-coding the deployment keys in config.xml. In part four of this series, I’ll show you how to dynamically change keys based on your deployment target (e.g. Staging or Production).

Safety first!

Any Cordova app using version 5 or greater is required to use the whitelist plugin and declare a Content Security Policy (CSP). The CSP essentially answers the question, “what domains are trusted to provide data?” To establish trust with the Code Push server, we need to add the following meta tag to index.html:

<meta http-equiv="Content-Security-Policy" content="script-src https://codepush.azurewebsites.net http://localhost:* 'self' 'unsafe-inline' 'unsafe-eval'; media-src *">

Translated into English this CSP says, “It’s okay to execute JavaScript from…”

👍 https://codepush.azurewebsites.net
👍 http://localhost
👍 Any file referenced in root directory
👍 Inline <script> tags
👍 eval() statements are also OK
👍 Images, videos and other media can come from anywhere

Invoke the Code-Push API

We’ve already established our app’s identity by created deployment keys. Now, we need to tell the app how and when to ping the Code Push service for an update. For demonstration purposes we’re simply going to check for updates when clicking a menu item, but you may want to use app lifecycle events like deviceready. Our button can be found in /www/templates/menu.html.

<!-- Code Push -->
<a class="item item-icon-left" ng-click="codePush()">
    <i class="icon ion-ios-cloud-download-outline"></i>Check Update
</a>

… and the handler in /www/js/controllers.js

/* ---------------------------------------------------------------
   codepush check for update */
$scope.codePush = function() {
    console.log('check for code push update');
    
    var updateDialogOptions = {
        updateTitle: "Update",
        mandatoryUpdateMessage: "You will be updated to the latest version of the app.",
        mandatoryContinueButtonLabel: "Continue",
        optionalUpdateMessage: "Update available. Install?",
        optionalIgnoreButtonLabel: "No",
        optionalInstallButtonLabel: "Yes",
    };

    var syncOptions = {
        installMode: InstallMode.ON_NEXT_RESTART,
        updateDialog: updateDialogOptions
    };
    
    var syncStatusCallback = function (syncStatus) {
        switch (syncStatus) {
            // Result (final) statuses
            case SyncStatus.UPDATE_INSTALLED:
                $ionicPopup.alert({
                    title: "Sweet Success",
                    template: "Restart your app to complete the update."
                });
                break;
            case SyncStatus.UP_TO_DATE:
                $ionicPopup.alert({
                    title: "All Good",
                    template: "Your application is up to date."
                });
                break;
            case SyncStatus.UPDATE_IGNORED:
                console.log("The user decided not to install the optional update.");
                break;
            case SyncStatus.ERROR:
                $ionicPopup.alert({
                    title: "@#$!",
                    template: "Something went wrong. Try restarting your app."
                });
                break;

            // Intermediate (non final) statuses
            case SyncStatus.CHECKING_FOR_UPDATE:
                console.log("Checking for update.");
                break;
            case SyncStatus.AWAITING_USER_ACTION:
                console.log("Alerting user.");
                break;
            case SyncStatus.DOWNLOADING_PACKAGE:
                console.log("Downloading package.");
                break;
            case SyncStatus.INSTALLING_UPDATE:
                console.log("Installing update");
                break;
        }
    };

    window.codePush.sync(syncStatusCallback, syncOptions);
}
// --------------------------------------------------------------- */

While this looks complicated, it’s really quite simple once you break it down.

updateDialogOptions {...} provides optional text and styling information
syncOptions {...} tells Code Push to replace the content of /www on restart
syncStatusCallback handles the range of possible responses from the Code-Push service
window.codePush.sync(...) invokes the actual codePush API

The truth is that you could omit items 1-3 and just let Code Push do everything with window.codePush.sync(), but it’s nice to see what’s possible with a fully customized implementation.

Automate Deployments with VSTS

Similar to the steps followed in part two of this series, we’re going to clone our pre-existing build definition and add a Code Push build step. Login to VSTS and navigate to the BUILD tab. Right-click on the “Android-Build” definition and select Clone.

With the new build definition selected, click “Add build step” and choose “Code Push - Release” from the Deploy category.

Configure Your Code Push Build Step

Once you’ve added the build step, you’ll need to configure it as pictured below:

Label	Value	Why?
Authentication Method	Access Key	Establishes trust with the Code Push cloud service
Access Key	$(code-push-access-key)	To protect our access key, we’ll encrypt it in a variable
App Name	superfly	This is human readable app name published to the store
Deployment	Staging	We’ll use staging while testing
Update Contents Path	platforms/android/assets/www	Default location where Cordova outputs the web assets for Android
Target Binary Version	^0.0.2	Semantic Versioning. This says, “install the update if you’re installed app is of version 0.0.2+n”
Rollout	100%	Deploy this update to 100% of possible users
Descrition		You can display this message to users before an update
Mandatory	Unchecked	Don’t require this update
Disabled	Unchecked	We want to run this build step
Enabled	Checked	We want to run this build step
Continue on error	Unchecked	Stop the presses when there’s a build error
Always run	Unchecked	Since we never continue on error, it’s okay to leave this unchecked

Establish Trust Between VSTS and Code Push

As you probably noticed above, we referenced a VSTS build variable to store $(code-push-access-key), but haven’t actually created one yet. Remember, the Access Key establishes a bond of trust between VSTS and the Code Push service so that VSTS can deploy on your behalf. To get your Access Key, go to the command line and execute:

# create the access key
code-push access-key add superfly

This command will return a 32 character key. Back in VSTS, go to the Variables tab and add a variable named “code-push-access-key” using your new key. To protect it from prying eyes, select the lock icon to the right of the input box.

Deploy on Commit

At last, we’re ready to commit our code changes and use Code Push to deploy our update over-the-air. Make sure “Continuous Integration” is checked under the Triggers tab and save this build definition as “Android-Release.”

With “Continuous Integration” checked, this build definition will run every time someone commits code to the master branch. To trigger the next build, open your terminal and push the latest changes…

git commit -m "Add code push"
git push

Once the files have transferred, you should be able to see your build complete in VSTS. Select “Android-Release” then double-click on the build number under “Queued Builds”.

Open the App and Check for Updates

To see Code Push in action, deploy the app to a local device or emulator. I’m using a Nexus 5 running Android Marshmallow (because I’m fresh like that). From your terminal…

cd ~/Code/superfly
cordova run android --device

From the running app, open the slide-in menu and select “Code Push Update”

TA-DA! Your app will update on restart.

Mobile DevOps: A Four Part Series

Beta Test with HockeyApp

Tue, 26 Apr 2016 00:00:00 +0000

This is part two of a four part series and assumes you’ve already set-up continuous integration with our sample project. If you haven’t already, I highly recommend reading Continuous Integration for Cordova Apps.

Unit tests and end-to-end tests provide a great sanity check before pushing code into source control, but the best bugs are often discovered through manual testing. Real human users just have a better sense for when something isn’t “right.”

For beta testing, I prefer HockeyApp over Apple TestFlight or the Google beta program because it allows me to distribute to unlimited beta testers, collect crash analytics and user feedback.

With HockeyApp, I can:

Upload my apps manually through the website or through a CI system
Distribute to a controlled group of iOS, Android and Windows users
Collect detailed crash reporting and analytics
Collect user feedback (e.g. send messages, attach screenshots, threaded communication)
Control the app version installed on user devices
Integrate with most popular bug tracking systems

HockeyApp is also free for accounts with up to 2 apps, so it’s a no-brainer to try.

Get Started

While HockeyApp allows you to manually upload app packages through their website, we want to automate releases through our build server on VSTS. So, let’s start by creating a free account on http://www.hockeyapp.net.

Once you’ve created an account, we need to establish trust with VSTS by sharing an API Token. Go to Account Settings within the HockeyApp portal and select API Tokens in the sidebar. From here, create an “All Apps” token with “Full Access” rights. HockeyApp will generate a 32-character token. You’re going to use that token in a minute, but just keep the tab open for now.

Switch to a new browser tab and open the Build tab of your VSTS account. Right-click on the Android-Build definition that you previously created and select Clone. After all, there’s no need to start from scratch again. In the cloned build definition, add the HockeyApp build step after “Cordova Build”.

To get the HockeyApp Connection, you’ll need to take one extra step. Click Manage adjacent to the input box. In the new window, select HockeyApp, then enter the 32-character token you created in HockeyApp.

When you return to VSTS, simply click the refresh button adjacent to the drop-down to make your new connection appear. Configure your build step as pictured below:

Label	Value	Why?
HockeyApp Connection	All Apps	Points to the API token you created in HockeyApp and establishes trust
App ID	com.ryanjsalva.superfly	This is the default App ID of my sample project. You can find/change it by looking for the `<widget>` tag in config.xml
Binary File Path	platforms/android/build/outputs/apk/android-debug.apk	Default location where Cordova outputs the native app package
Symbols File Path		Not used by our project
Native Library File Path		Not used by our project
Release Notes (File)		Not used by our project
Release Notes	Recommended update.	Because if we say it’s “recommended”, surely they’ll install it, right?
Publish	Checked	Immediately publishes to HockeyApp
Mandatory	Unchecked	Not a required update
Notify Users?	Checked	Users are more likely to install if you tell them something is available
Tags		No tags mean the update goes to everyone
Teams		No teams mean the update goes to everyone
Users		No users mean the udpate goes to everyone
Enabled	Checked	We want to run this build step
Continue on error	Unchecked	Stop the presses when there’s a build error
Always run	Unchecked	Since we never continue on error, it’s okay to leave this unchecked

Save this build definition as Android-Beta. We won’t build yet because there are still a few code changes necessesary, but celebrate anyway with a song in your headphones. I recommend The Modern Lovers’ Girlfriend.

Invoke HockeyApp from Code

The HockeyApp SDK is delivered as a Cordova plugin. That plugin is already installed in our sample project (you’re welcome), but we need to invoke it. Fortunately, that only requires modifying a few lines. In /www/js/app.js, uncomment the following line and replace “APP_ID” with the value for <widget id="APP_ID"> found in config.xml. Assuming you don’t create your own APP_ID, the value will be “com.ryanjsalva.superfly”.

hockeyapp.start(null, null, "APP_ID");

Note that the APP_ID needs to match in three places:

Location	Value	Why?
/config.xml	`<widget id="APP_ID">`	Authoritative source for APP_ID
/www/js/app.js	`hockeyapp.start(null,null,"APP_ID")`	Establishes app identity when calling into the HockeyApp API
VSTS	HockeyApp build step configuration	I honestly don’t know

Next, we need to uncomment a few lines from /www/js/controllers.js

$scope.fakeCrash = function() {
    console.log('fake crash');
    hockeyapp.addMetaData(null, null, { someCustomProp: 23, anotherProp: "Custom Value" });
    hockeyapp.forceCrash();
}

// hockeyapp send feedback
$scope.sendFeedback = function() {
    console.log('send feedback');
    hockeyapp.feedback();
}

// hockeyapp check for update
$scope.checkForUpdate = function() {
    console.log('check for HockeyApp update');
    hockeyapp.trackEvent(null, null, 'Check for Update');
    hockeyapp.checkForUpdate();
}

These methods will be invoked when we click the corresponding menu items in our app’s menu bar. As you can see, there’s not much to them. The one thing I’d call out is hockeyapp.addMetaData([json]). You can invoke this method at any time to record n parameters describing your runtime state. This can be tremendously helpful if you need help debugging you app in the wild.

Run that build, you crazy kid

Now, you’re ready to automate your next build with another commit. Go back to Terminal and run:

git commit -m "enabled hockeyapp"
git push

When you return to VSTS, you should find a build in the queue for Android-Beta.

Install HockeyApp on your Android Device

While that’s building, grab your Android phone and install HockeyApp. HockeyApp is also available for iOS and Windows, but this tutorial only builds for Android… so, hopefully, you’ve got an Android phone handy 😛

After authenticating on your Android device – and assuming the beta build has completed – you should see an app appear in your HockeyApp mobile client. Install and open it. You’ll find at least two fun features to try in the sample app sidebar menu:

Fake Crash will force the mobile app to crash so you have a chance to explore HockeyApp’s crash analytics
Send Feedback allows beta testers to submit feedback to the development team directly through the app. Don’t forget to try attaching a picture (e.g. a screenshot) where you can annotate with crude finger drawings.

Once you’ve had a chance to play with the app and forced a few crashes, go back to the HockeyApp portal. With a few minutes of exploring, you’ll find lots of neat features. Listen to a song in your headphones while exploring, I recommend “March of the Nucleotides by Bit Shifter.”

Mobile DevOps: A Four Part Series

Continuous Integration for Cordova Apps

Mon, 25 Apr 2016 00:00:00 +0000

This is part one of a four part series focused on devops for mobile apps. It assumes you’ve already installed NVM, Node, NPM, Git, Gulp, Cordova and Ionic. I also recommend using VS Code for your code editor, but use whatever’s comfortable. All steps work equally well on Mac and Windows.

Why Continuous Integration?

Continuous Integration is just fancy talk for “my app builds whenever I commit my code to source control.” In theory, it enables developers to release after every commit, but that’s not why most developers use it. The truly useful thing is that you can “decorate” your build with other scripts. For example, you can auto-magically:

Run unit, functional or UI tests to measure code quality
Notify other team members that a build is available
Distribute your app to beta testers
Publish your app to the store

Imagine this: you start by working on a new feature in your personal branch. Excited to share your work, you merge with the dev branch where unit tests automatically run and pass.

Satisfied that code quality is… well, pass-able, you merge to the beta branch where your new feature is automatically distributed to beta testers for manual testing. Beta testers using Android devices notice that the layout is broken on views using your new feature, so they send feedback from within the app along with a screenshot. You fix the bug, then merge with dev and beta where unit tests and beta distribution auto-magically happen again.

Confident that your feature is ready for the public, you merge with the release branch which triggers another release. Because your app is built with Cordova, you can update without re-submitting to the app store. Your build server pushes a new release and users get a notification. “Hey, buddy. A new version is available. Update now.”

Running unit tests, distributing to beta testers, releasing bug fixes over-the-air… all these steps happen automatically when you commit to a branch under watch.

Over the next four blog posts we’ll…

Setup continuous integration
Distribute our app to beta testers for manual testing
By-pass the app store to release bug fixes
Customize our build steps to use a different config for each release type – i.e. dev, beta, release.

Get the Sample Project

Start by cloning the sample project into your local directory and restoring all the npm packages

git clone http://github.com/ryanjsalva/superfly
cd superfly
npm install

Create Your Project in VSTS

Visual Studio Team Services (VSTS) provides three basic services:

Git-based source control
Cross-platform build automation
Agile team management (e.g. scrum boards, backlogs, bug tracking)

In a lot of ways, you can think of VSTS as the union between GitHub, Atlassian and Jenkins (if you’re familiar with those). By combining all three services in the same tool, we can automate a lot of the grunt work. As of this writing, it’s free for teams of 6 or less. Once you’ve logged in, you’ll see this page:

Side note: It’s almost criminal that you can get a pre-configured automated build environment for free these days. What a time to be alive.

Create a new project and name it superfly. On the next screen, choose to start by “adding code.” VSTS will provide you with a git URI that you can run in the terminal. Now we just need to push our first commit to VSTS.

git remote add origin https://ryanjsalva.visualstudio.com/DefaultCollection/_git/superfly
git commit -m "first commit"
git push

Congratulations! You’ve setup your dev environment and source control. Celebrate with an awesome song on your headphones. I recommend anything from Girl Talk’s Feed the Animals.

Let’s Get Unit Tests Running

Like most Angular projects, our sample app uses Karma and Jasmine to run unit tests found in the /tests directory. Our sample project includes a Gulp task to invoke these tests.

gulp.task('test', function (done) {
  new Server({
    configFile: __dirname + '/tests/karma.conf.js',
    singleRun: true
  }, done).start();
});

If you’re not already familiar with Gulp, it’s simply a build task manager. Using Gulp, you can create build tasks that move, concatenate, obfuscate, prettify or other wise modify files. You can see it work by opening terminal and executing gulp test

This task runs our unit tests in a headless browser called PhantomJS. If everything worked correctly, you should see the following response:

Using gulpfile ~/Desktop/superfly/gulpfile.js
Starting 'test'...
22 04 2016 21:38:37.271:INFO karma: Karma v0.13.22 server started at http://localhost:9876/
22 04 2016 21:38:37.277:INFO launcher: Starting browser PhantomJS
22 04 2016 21:38:38.398:INFO PhantomJS 1.9.8 (Mac OS X 0.0.0): Connected on socket /#WzMqeZ4EfOqhVS27AAAA with id 41819505
PhantomJS 1.9.8 (Mac OS X 0.0.0): Executed 2 of 2 SUCCESS (0.007 secs / 0.012 secs)
Finished 'test' after 1.4 s

Run Tests on Every Push

Now that we have tests running locally through a manual step, we want to run them in the cloud automatically. Head back to VSTS and click on the “BUILD” tab at the top. From here, we’ll create our first build definition by clicking the [+] icon.

Name your build definition “Android-Build”, choose the Empty template and select the Continuous Integration checkbox since we want builds to run on every push. Otherwise, stick with the defaults.

Each build definition is comprised of multiple build steps executed in serial order. Let’s add some. Click Add build step and add the following steps in this order:

npm: to download all the node_modules not saved in our repository
Gulp: to run our “test” task
Cordova Build: to build the app

For the most part, you should be able to go with all the defaults. To configure each build step, select it and set the following values:

Under the Cordova Build step, notice the $(configuration) variable. This allows us to dynamically change the build configuration (e.g. debug or release) at queue time, but it requires a little extra setup. Switch to the Variables tab and add a new variable for “configuration” before clicking SAVE.

Since we’re here, we might as well take a look at some of the other interesting fields, though no changes will be required. Under the Triggers tab, we see that new builds will be triggered every time there’s a push to the master branch.

Under the Repository tab, we see that new builds will also use source from the master branch.

If you haven’t already, click SAVE so that we can trigger our first CI build. Go back to terminal, and commit a change:

touch readme.md
git commit -m "created empty readme"
git push

You can see your build spool by clicking Builds, then navigating to the Queued tab and double-clicking the queued build.

When it’s all done, you should see a build progress report declaring success. Celebrate with another song in your headphones. I recommend “I Don’t Want to Get Over You” by the Magnetic Fields.

Ryan J. Salva

Build the Ideal Cordova Dev Environment

Hardware

Mobile Device Library 📱

Node Version Manager (NVM)

Globally Installed NPM Packages

VS Code

Edit, Preview and Debug Loop

.bash_profile

.bash_nvm

.bash_finder

.bash_cordova

.bash_network

.bash_prompt

Android SDK

Android Emulator

Other Apps on the Mac

Configuring Parallels

Visual Studio

Local vs. Global

Remote Build Agent

Share with Others

Celebrate! 🎉

Maintain Separate Configs for Dev, Beta and Release Build Targets

Change Your App’s Configuration Based on Branch

Two Big Advantages

Update the Source Code

Give each branch a custom config.xml

Switch the Code Push Deployment Key

Give each branch a custom Gulp task

Configure VSTS

Checking Our Work

Mobile DevOps: A Four Part Series

Release Without Re-submitting to the App Store

JavaScript’s Unfair Advantage

How does it work?

Is Apple really cool with it?

Service Providers

Let’s code (push)

Create Your Code-Push Service

Manage Deployments

Add the Deployment Key to Your App

Safety first!

Invoke the Code-Push API

Automate Deployments with VSTS

Configure Your Code Push Build Step

Establish Trust Between VSTS and Code Push

Deploy on Commit

Open the App and Check for Updates

Mobile DevOps: A Four Part Series

Beta Test with HockeyApp

Get Started

Invoke HockeyApp from Code

Run that build, you crazy kid

Install HockeyApp on your Android Device

Mobile DevOps: A Four Part Series

Continuous Integration for Cordova Apps

Why Continuous Integration?

Get the Sample Project

Create Your Project in VSTS

Let’s Get Unit Tests Running

Run Tests on Every Push

Mobile DevOps: A Four Part Series