Explore Available Build Steps
When you dive into writing your first build definition, the most obvious approach may be to add a bunch of generic command line steps. Instead, take a few minutes to peruse the variety of build steps available, including those in the third-party marketplace.
Tool installer tasks, in particular, are likely to work better than fetching tools yourself on every build. We’re using the Node installer and a couple of Yarn tasks, and I’m experimenting with the Chromium installer.
Keep Your npm Scripts Portable
npm Scripts offer a convenient place to stash common operations related to your project, such as the build and test commands you use in CI. Here are a couple of pointers:
1) Use cross-env to make your POSIX-style environment variable references work in Windows:
"coverage": "cross-env COVERAGE=true ember test --config-file testem_ci.js",
The sad truth is that Node performance on Windows is often still really bad. Fortunately, it’s 2017, and bizarro Microsoft offers Linux agents:
My advice is to use them!
By all means, regularly run Windows builds to make sure compatibility doesn’t rot, but carefully consider their frequency. Perhaps only run them nightly, or to validate PRs, rather than on every commit.
Microsoft’s Visual Studio Team Services aims to be the one-stop shop for your backlog, source control, continuous integration, release, and deployment.
It’s certainly not my first choice of CI tools (that currently goes to CircleCI), but with some care, it can be workable. If you need Windows and Linux, VSTS is arguably even better than integrating two separate services as many open-source projects do. (e.g., Travis CI and Appveyor).
Are you using VSTS CI? What have been some of your high points and low points?