note: add some small changes on 17-11-2015 based on some new insights on the latest version of DXC.
Did you already hear about Appveyor? If the answer is no, check out for example the post A good continuous integration system is a joy to behold by Scott Hanselman.
So now you do know how cool it is, let’s start using it for your EPiServer project. The EPiServer Digital Experience Cloud is running on Azure, so everything you read here does work for your Azure setup as well.
Attaching your source…
Attaching your source to Appveyor is really easy.
- Go to your Appveyor portal page
- Select New project
- Select the source control system you use.
- We use Visual Studio Online
- You see all vs online instances you have access to
- Select the branch folder you like to have CI for.
- A Appveyor project is created for you, that’s all!
- Now you are in the settings area of Appveyor. All items you can set here, can be downloaded / saved as a yaml file (Export YAML)
Create the yaml file
The beauty of Appveyor is that most things are working out-of-the box, without too much setup. For example you can setup the CI environment by using an easy to read Yaml file, or just create the Yaml file automatically within Appveyor. If the Yaml file is not in your project, the build server relies on the settings you did in the "admin" portal. Exporting the default configuration to a Yaml file is very easy. Go to your project settings page and hit the "Export Yaml" menu item en create the Yaml file from there. Add the file to the root of your code repository. Our Yaml file looks like this:
version: 0.1.{build}
configuration: Release
assembly_info:
patch: true
file: '**\AssemblyInfo.*'
assembly_version: '{version}'
assembly_file_version: '{version}'
assembly_informational_version: '{version}'
nuget:
account_feed: true
project_feed: true
disable_publish_on_pr: true
before_build:
- nuget restore website\solutionname.sln -source http://nuget.episerver.com/feed/packages.svc/ -source https://www.nuget.org/api/v2/
build:
publish_wap_xcopy: true
verbosity: minimal
deploy:
- provider: WebDeploy
server: https://--- website name ---.scm.azurewebsites.net:443/msdeploy.axd?site=--- website name ---
website: --- website name ---
username: --- username ---
password:
secure: --- your secure key here ---
Every setting in this Yaml file can be managed from the Appveyor portal as well. But in the end I think it’s easy to have this file versioned in your project. Let’s describe our setup.
Versioning
Versioning can be handled by the Appveyor build server. It automatically sets the version numbers of your projects. In our example that’s a prefixed version number (0.1.) combined with the buildnumber ({build}).
Episerver nuget settings
Appveyor does restore nuget packages automatically, but when using EpiServer we rely heavily on EPiServers nuget package feed. Therefor you can execute a pre-build command (see: before_build) and add the sources you rely on there. Appveyor can also serve as your own private nuget server. If you build nuget packages in your solution these are automatically added to the private nuget feed (based on the .nuspec files).
Web deploy
After each commit (or tfs check-in) we like to deploy our stuff to our dev test environment of course. This again is really easy to setup.
See the deploy part of the YAML file, or go to the deployment settings area in Appveyor. You need to download your publish profile from the Azure portal
or in case you use the EPiserver Digital Cloud Experience platform, you can get this from your support engineer.
The file is an xml file. All data needed to setup Appveyor correctly for Web deploy is in this file:
- Server: https:// + < publishProfile publishUrl > + msdeploy.axd?site= + < publishProfile msdeploySite >
- Website name: < publishProfile msdeploySite >
- Username: < publishProfile userName >
- Password: < publishProfile userPWD >
Build a zip package and deploy.
I don’t like to do CI for our live environment. And because we like to test the "GO Live procedure" we don’t do this for our
acceptance environment either. We like to have a person who push the red button. When using DXC the EPiServer support team will push this button. Appveyor to the rescue; it can create a zip package for
xcopy deployments and save it as an artifact (publish_wap_xcopy: true or go the the Build tab and set Package Web Applications for XCopy deployment).
If you think a specific version is stable enough, just download the zip file and send it together to the administrator who has to deploy the package.
Appveyor can also do the deployments for you, but when your administrator don’t have access to you Appveyor portal WAWSDeploy can help you out.
For the administrator (and also for the developer) WAWSDeploy is an easy to use tool to help you with the deployment of the zip file. You can install WAWSDeploy via Chocolatey and read more about it at David Ebbo’s blogpost. This is especially handy when you own the environment, in case of the DXC a lot is handled for you by the support team.
Conclusion
Appveyor works really great within an EPiServer DTAP street. This is mainly because the great code first approuch and the ease of use of Appveyor. The Digital Cloud Experience Platform makes it even more easier, because we don’t have to do transformations for services busses, connectionstrings etc and even the deployment to staging and prod. The EPiServer support team will manage this for you.