Last year, we showed you how to use our Team Foundation Server (TFS) XL Deploy plugin to create, import and automatically deploy applications from TFS and Visual Studio Team Services (VSTS).
This plugin allows you to build a package with TFS/VSTS, import the package into XL Deploy and automatically trigger a deployment to your chosen environment(s). With this integration, you get an easy, consistent way of packaging and deploying your applications from TFS/VSTS to all your target platforms: from legacy enterprise apps running on on-premise middleware, to cloud, PaaS and Docker.
With the new 7.0 version of the VSTS/TFS plugin for XL Deploy, we’ve improved the plugin even further with the addition of two build/release tasks:
- Package with XL Deploy – Packages your application
- Deploy with XL Deploy – Imports the package and deploys it to the chosen environment
Although this functionality was already present in the original XL Deploy “Build” task, breaking it into two separate tasks adds fine-grained control: the “Package with XL Deploy” task can be added to the build pipeline so that you’re only building the package once, while the “Deploy with XL Deploy” task can be added to the release pipeline multiple times so you can deploy that one package to different environments in the pipeline. This ensures that the code you’re deploying to production is exactly the same code that was successfully tested in the lower environments.
To demonstrate how these tasks work, I’ll walk you through how to create an XL Deploy package during the build stage and, later on in your release definition, deploy that package to different environments. Let’s get started…
Building the Artifact
As I described in a previous post, we will keep our Visual Studio Build. However, instead of using the XL Deploy build task, we will add the “Package with XL Deploy” task, which you can find in the Package category in the Task catalog.
Once we add the task, we need to point it to the right manifest path, choose whether we want the task to set the version of the created package based on the build number and, in our case, publish the artifact to TFS. If the latter option is selected, once the package is created, it will be uploaded to TFS and associated as an artifact to the current build. At the end, the result should be similar to the following:
We can now try the build and, if successful, we should see a DAR package under the build artifacts.
Once we see that the artifact uploaded, we can move to the next step.
Deploying from the VSTS Release Management
We are now going to create a new release definition and start with an empty template. As the artifact source, we are going to indicate a build, and from the relevant drop-down menu, select the build definition that we created in our previous step. You also may choose to select a continuous deployment option and a specific build queue for this build.
Now that we’ve created the release definition for the initial environment, we’ll choose Add Task and then select the “Deploy with XL Deploy” build task from the Task catalog.
This task will allow us to import the DAR package into XL Deploy and trigger the deployment for the desired environment. Bear in mind that the plugin will check if the package is already in XL Deploy and, if so, will skip the import. This means that if you are using it multiple times for different environment definitions, it will only be imported the first time.
Now we need to select the XL Deploy Endpoint, which indicates the instance of XL Deploy we are using for this deployment, and fill in the necessary indications about the artifact location and the name of our target environment. For further information about selecting the XL Deploy Endpoint, see “Add an XL Deploy endpoint in Visual Studio Team Services.”
If the release process can pick up the artifact from the TFS server, it means that the release process itself will deliver the artifact, which it gets from the associated build. If you are not uploading the artifact to the TFS Server, you can make it available to the release process from an alternative source, such as a file share. In this case, the release task will copy the file from the UNC path you provide.
And that’s it! Now we can create a new release and let our task delegate the deployment to XL Deploy.