How AppVeyor can streamline your development process

In a previous blog post, I talked about the awesomeness of AppVeyor. Since then, AppVeyor has become a key part of everyday development at Razor, so I’d like share a few techy tips and tricks we’ve learnt along the way…

Build It 🔨

When building/packaging code via AppVeyor, the configuration can be stored in the settings section of the portal for the respective Project, or in a file called appveyor.yml at the the root of the repository. I’d recommend putting the majority of settings in this YML file to allow for branch specific configuration. The only exceptions are the Project name, build version format, tags. What about senitive data? Don't worry, you can encrypt it and place it inside the YML under the environment, deploy, and notifications sections. It’s worth noting that the any configuration inside the appveyor.yml file will override equivalent ones in the web portal. The build format version is an example where you want to store it in both places, but set it to 0.0.0.{build} in the web portal - you can think of this as the default value that will be used if AppVeyor can’t parse the YML file. In those rare circumstances, we don’t want to reserve a version number for an unusable build, although AppVeyor now has a handy feature for deleting unwanted builds.

We ❤️ shiny new technologies, so here's an example of an appveyor.yml file that can be used for .NET Core projects to build, package, and deploy (this one is from our AppVeyor dashboard):

Most of this file is pretty self explanatory, but AppVeyor also provides a handy appveyor.yml reference.

Ship It 🚢

The output from each build usually contains at least one artifact. In terms of web applications, it’ll probably be a ZIP file containing all of the files required to run it on a web server. Not only can AppVeyor generate these artifacts and make them available for download, it can deploy them to variety of destinations in the cloud. We mainly use Web Deploy to deploy web applications to Azure Web Apps (platform-as-a-service). For those who prefer to keep everything on-premise, AppVeyor also has a deployment agent that can be installed behind the firewall.

AppVeyor has three ways in which deployments can be configured; portal settings, appveyor.yml, and Environments. The first two options act as extensions to the build, meaning each artifact will automatically get deployed at the end, but the build must take place first. Environments are separate to Projects, and only contain information about the artifact and the destination - just enough to carry out the deployment. The good thing about Environments, apart from separating responsibilities, is that they can be triggered automatically at the end of each build, or manually if a previous deployment failed, which will happen more than you think. In theory, building the exact same code more than once could produce a different output. Maybe the environment has changed. Or maybe the NuGet server is unavailable or returns the wrong version of a package that your solution relies upon.

Dashboard It? 📈

Dashboards are also awesome. They're so awesome that we decided to create an AppVeyor dashboard to display our builds and deployments. Because we like to give back to the community, this project is open-source and available on GitHub.

Builds

appveyor-dashboard-builds

Deployments

appveyor-dashboard-deployments

Want It? 🙋

If you want to know more about how Razor can help you integrate AppVeyor into your development cycle, get in touch.