Using VSTS on a daily basis I find that I add a regular list of VSTS Marketplace extensions to my VSTS environment. I find them convenient and helping me to get the most out of VSTS. The list below is primarily focussed on the Work and Code area and not so much on the Build and Release area.
I’ve created a new VSTS Build & Release task to help you interact with the (VFS) Virtual File System API (Part of KUDU API of your Azure Web App). Currently this task can only be used to delete specific files or directories from the web app during your build or release workflow. It will be updated in the near future to also be able to list files or to upload / download files through the VFS API
The reason i made this task was that i needed it at my current customer. We’re deploying our custom solution to a Sitecore website running on Azure web apps using MSDeploy. The deployment consists of 2 parts: an install of the out-of-the-box Sitecore installation and the deployment of our customisations. When deploying new versions we want to keep the Sitecore installation and MSDeploy will update most of our customisations. Some customisations however create artifacts that stay on the server and aren’t in control of the MSDeploy package that can cause errors on our web application. This new VSTS Build / Release task can help you delete these files. In the future this task will be updated with other functionality of the VFS API such as listing, uploading or downloading files.
Let’s have a look how to use this task and how it works under the hood.
Azure functions are great to build small specialized services really fast. When you create an Azure Functions project by using the built-in template from the SDK in Visual Studio you’ll automatically get a function made in a CSX file. This looks like plain old C# but in fact it is actually is C# Script. When you’re deploying these files to Azure you don’t have to compile them locally or on a build server but you can just upload them to your Azure Storage directly.
In the last update for Azure Functions the option to build precompiled functions was added. Doing this is actually pretty simple. I’ve created a sample project on Github containing a precompiled Azure function, unit tests for the function and an ARM template to deploy the function. Lets go over the steps to create a precompiled Azure function.
From Visual Studio Team Services (VSTS) it’s possible to deploy to an Azure Subscription using an Active Directory Service Principal.
Although the information on the blog post for the 3-clicks setup is still actual, the script link provided for the manual configuration is not available anymore (not found, probably because the Git repo has been moved/renamed).
For both the suggested ways (3-clicks or manual), there are some concerns from my side about the principal setup, which I think they could be improved:
- The principal which is created during the process gets the “Contributor” role granted on the whole Azure subscription, and using the manual powershell script, the default role is even “Owner” (this can be modified).
- The name of the Active Directory Application/Principal is some random guid which is difficult to be identified, see this picture:
When you are developing Powershell scripts, creating some unit tests will help you in monitoring the quality of the scripts. Writing some tests will give you some assurance that your code still works after you make some changes. Writing Powershell unit tests can be done with Pester. Pester will enable you to test your Powershell scripts from within Powershell. It is a set of Powershell functions for unit testing Powershell. These functions will allow you to mock and isolate the Powershell code under test. When you want to integrate your unit test into your VSTS build pipeline, you need an build extension to run then in your build pipeline.
Azure Functions enable you to easily run small pieces of code in the cloud. To do this right, you need to setup continuous delivery of the infrastructure and the code involved. Otherwise you will end with an uncontrolled environment where nobody knows what code is actually running. In this blog post I’ll describe how to setup a deployment pipeline for Functions with VSTS. This will enable you to deploy Functions as Infrastructure as Code.
From an deployment perspective an Azure Function contains of two parts:
In my previous blog post Lock Azure resources to prevent accidental deletion, I showed how to add a lock to a resource with an ARM template to protect it from accidental deletion. When you want to delete the resource, you first need to remove the lock. A lock cannot be removed with an ARM template. To remove the lock you can use:
In some cases you want to protect critical resources from accidental deletion. Some examples are a storage account with source data for processing, a Key Vault with disk encryption keys, or another key component in your infrastructure. When losing some resources that are key in your infrastructure, recovery can be dramatic. Resource Manager locks will enable you to protect these critical resources from deletion.
At my current customer we’re implementing an Azure environment which also contains a Sitecore application. We’re using VSTS to for all aspects of the application development lifecycle from agile planning to source control and automated builds & releases. In the release pipeline we can use the out of the box Azure web deploy build steps to deploy our code to our web app which is a Sitecore instance. The next step is to be able to also deploy the Sitecore content we created as code using TDS to our Sitecore Site.
Sitecore.Ship is an open source project which makes it easy to deploy Sitecore .Update files to your Sitecore Instance. It is created by Kevin Obee and it can be found here on Github
in our Build we build our TDS projects using MSBuild to generate .Update files which we can then deploy in our release pipeline to Sitecore. There was one problem however which was that there was no build task to do this. Since my role at my current client is supporting all the development teams in improving their continuous delivery process i decided to create a task to make their life easier.
Sitecore.Ship build task
You can download the build task now in the VSTS marketplace.
To be able to upload your .update files using Sitecore.Ship you have to install Sitecore.Ship on your Sitecore instance first. when you’ve done that don’t forget to whitelist the IP address of your build server in the web.config so Sitecore.Ship will allow your build server to do the deployment.
After that add my Sitecore Ship VSTS task to your workflow, select the .update file and the URL of your Sitecore site and you’re done.
The task works for both VSTS and TFS 2015/2017 and works for your sitecore site hosted on prem or in Azure.
Of course this VSTS task is open source and the source can be found here on Github
the tasks is uploading the sitecore packages through powershell. even if you are not using powershell you might want to use this piece of powershell if you want to upload things to Sitecore using Sitecore.Ship manually. The script is quite basic setting up a httpclient that sends the files to Sitecore through http Post.
If you want to run the powershell script manually you have to replace to 2 lines that retrieve the parameters from the build task to parameters that are sent to the script.
This is the first VSTS build task i’ve created so please let me know if you like it or if you have feedback in improving this task by leaving a comment here or on Github.
also check out one of the many other VSTS build tasks made by my colleagues from Xpirit
Geert van der Cruijsen
The post Created an open source VSTS build & release task for Sitecore.Ship appeared first on Mobile First Cloud First.
For the quick answer jump directly to the conclusion
Yesterday I was setting up the build for an ASP .NET Core (Web API) application I wrote, this application was using a package from the VSTS Package Management repository.
To setup this build I was using the new dotnet Core tooling (in preview) which is available when creating a new Build Definition: