While the goal of the Azure DevOps extension for XebiaLabs is still to deliver build and release artifacts from Azure right to XL Deploy, the new extension provides many performance and flexibility improvements.

What’s new?

Tasks delivered by the Azure DevOps Extension can now be executed on Azure DevOps agents that run Linux, MacOS, or Windows, increasing processing capacity and making the build process simpler and more streamlined.

The process of defining a XebiaLabs endpoint in Azure DevOps has been improved, so you can test the connection between Azure DevOps and XebiaLabs quickly and easily from the endpoint definition window. We’ve also improved the way that we handle self-signed certificates for authenticating with the XL Deploy server.

In addition, locating your XebiaLabs deployment packages is now easier and more powerful, with support for advanced search queries.

How will this impact the VSTS Extension?

Customers upgrading to the Azure DevOps Extension from the XL Deploy Extension for VSTS Extension can continue to use existing tasks for their builds and releases until something needs to be modified.

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.

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.

To Learn More

You can find more VSTS specific information here, and the VSTS extension for XL Deploy here.

]]>Recently we released a build task for Microsoft Visual Studio Team Services (VSTS) and Team Foundation Server (TFS) 2015 that facilitates the integration of the vNext build pipeline with our product, XL Deploy. The new build task is capable of creating a deployment archive (DAR package), importing it to an instance of XL Deploy, and eventually, if requested, triggering the deployment of the newly added package. It also contains some other interesting options that will ease the process of versioning the deployment package.

In the following post I will show you how to build an ASP.NET MVC application, create the deployment package, and deploy it via XL Deploy. Let’s start.

Prerequisites

Before we start, make sure that you have all of the necessary items in place. First of all, your build agent needs to be capable of building your application. In the case of on-premises TFS 2015, this means that you need to have installed Visual Studio on your build server.

You also need to install the XL Deploy build task; if you haven’t done so already, refer to Install the XL Deploy build task. As a prerequisite for the XL Deploy build task, your XL Deploy instance needs to be of version 5.0.0 or later; earlier versions are not supported.

Once you ensure that these criteria are met, you can continue reading.

Building your web application

First things first. Create a new empty build definition in your project. If you are not familiar with how to do this, refer to the MSDN article Create a build definition.

Set the repository mappings accordingly before proceeding any further; again, refer to the MSDN article Specify the repository for more information about doing so. For this example I am going to use TFVC; however, all of the techniques I am going to describe do work also with Git repository.

Now you can specify the necessary build steps to compile and publish the web application.

Add a Visual Studio Build build task.

Once added, you need to set the necessary parameters. The first mandatory setting is the path to the solution file in source control. Click the button with three dots and locate your solution file in the version control tree. Once found and confirmed, the Solution box will be populated with the correct path. In my case, that is $/XL Deploy Showcase/AwesomeWebApp/AwesomeWebApp.sln. This is the solution that will be built in the build definition.

Next you need to use the MSBuild Arguments setting to indicate that all of the built items should be delivered in the build staging directory. This is an important step because when the XL Deploy build task starts creating the deployment archive (DAR package), it will search for items to include in it, starting from this directory (considering the build staging directory as root). That’s why I am going to set MSBuild Arguments to /p:OutDir=$(build.stagingDirectory). This is a common way for MSBuild to pass a parameter; I’m using a variable that will resolve in a specific path when the build is run. A list of available variables and their usage is explained in the MSDN article Use variables. For now, I will not change any other setting. Make sure that Restore NuGet Packages is selected and that the correct version of Visual Studio is listed.

Save the build definition. Enter a relevant name and optionally set the comment.

Now, you can test the build. Queue a new build and check the results. If everything went well, you will get a ‘green’ build.

Now you are sure that the project builds correctly and we can continue with our next task, which is deploying the application via XL Deploy.

XL Deploy build task

In order to continue, you need to have a valid XL Deploy manifest file checked in to our source control. You can read about creating a manifest file at XL Deploy manifest format. I checked in the following manifest:

As you can see, I specified the required IIS application pool, a web site, and, most importantly, WebContent. The WebContent element indicates that the files that do represent the web site.

An attribute called file is present on the deployable element iis.WebContent. This attribute is very important, as it will guide the build task in creating the deployment archive. A relative path is set as the value and indicates the folder that needs to be included in the DAR package. This relative path assumes that the root folder is the build staging directory; it will search this directory for the folders specified here. If they are not present, packaging will fail. Now you understand why I delivered the build output in the staging folder. Although this behavior can be overridden in the advanced settings of the XL Deploy build task, I would advise you not to change it if it is not necessary and until you became confident and sufficiently experienced with TFS 2015 builds.

The manifest file also indicates that I expect MSBuild to package the web application under a default folder called _PublishedWebsites. This is standard behavior for MSBuild.

After the manifest file is correctly checked in, you can continue and edit the recently created build definition by adding another build step. This time, go to the Deploy group and select XL Deploy.

The first mandatory parameter that you need to set is the path to the manifest file. As you did previously for the solution file, click the button with three dots and select the manifest file in source control. In my case, that will be$/XL Deploy Showcase/AwesomeWebApp/deployit-manifest.xml.

Secondly, you need to set the endpoint, which is a definition of the URL and credentials for the XL Deploy server that you intend to use in this deployment. If no XL Deploy endpoints are defined, click Manage and define one. For information about doing so, refer to Add an endpoint in Team Foundation Server 2015. After you are done, click Refresh and your newly added endpoint will appear.

Versioning the package

As you can see, there is a Version option available on the XL Deploy build task. If selected, the deployment package version will be set to the build number format during the process. The build number format is a value that you can set in the General tab of the build definition.

When composing the build number, you can choose between constants and special tokens that are available for that purpose. In Specify general build definition settings, you can read about the available tokens and ways of setting the build number format.

If you are using a different pattern for versioning your deployment package and your build number format has a different use, you can override this behavior by setting a custom value in Version value override parameter under Advanced options.

For this example, I will set this option and then set the build number format to a simple ‘1.1.1$(Rev:.r)’.

Automated deployment

You have the option to automatically deploy the newly imported package to the environment of your choice. If you select the Deploy check-box on the XL Deploy build task, a new field called Target Environment will be available. Here, you need to specify the fully qualified name of the environment defined in XL Deploy. In my case, it is called Test. You can also allow the deployment to be rolled back in case of failure by selecting Rollback on deployment failure.

Note that this requires that you have correctly defined the environment in XL Deploy, with the relevant infrastructure and components. For more information, refer to Create an environment in XL Deploy.

Ready to roll

After you set all of the parameters and save the build definition, you are ready to trigger the new build. Make sure that you set all of the necessary parameters as shown in the picture.

You can now trigger the new build. In the build console you should now see the information relevant to the process of creating and versioning the package.

In case of problems, you can add a new build definition variable named system.debug and set the value to true. Then, in the build log, you will see more detailed messages about all of the actions preformed by the tasks (note that this is not shown in the console). It should be sufficient to diagnose the issue.

Conclusions

This was a small practical example about taking advantage of the new XL Deploy build task. I haven’t covered all of the available options; you can read more about them at Introduction to the Team Foundation Server 2015 plugin. However, this example is sufficient to get started. You can combine other build tasks in your build definition with the XL Deploy build task; but it is important that you invoke the XL Deploy build task after all of the elements that will compose your deployment package are available.

We like plugins too! Check out our entire XL Deploy plugin library and learn how you can connect all of your release automation tools with XL Deploy.