Press "Enter" to skip to content

K2: Continuous Integration Part 2 – Automatic Deployment

0

When I named the previous article from the Continuous Integration series K2: Continuous Integration Part 1 – Automatic Build, it automatically implied, that there supposed to be further parts. And they will be. In this post I will show you, how you can configure TFS (in my case VSTS – Visual Studio Team Services) to do an automatic deployment of K2 packages onto the target K2 environment.

The described below method is based on the materials from the official K2 User Guide – Deploy K2 Packages Using PowerShell. I will just show, how you can configure VSTS for this purposes.

0. Installation and configuration of a build agent.

We need to install and configure a build agent on the target environment as well. If you still do not know, how to accomplish this, please, refer to Step 0 from my previous article – K2: Continuous Integration Part 1 – Automatic Build. However, you need to place the newly created agent in a new Agent Pool. If your agents from the source environment and the target one remain in 1 pool, you will not be able to separate them when doing a deployment or will have to do some manual work by enabling and disabling certain agents in a pool etc. In VSTS you can map your release process only to a certain application pool/queue, not the agent itself. For the demo purposes, I created a new pool K2-CI-Demo-Deployment. It is running and ready for the next steps.

image

1. Create a Release Definition on VSTS

image

For the current deployment we will start with an Empty process:

image

Give the name to your environment, if you need. It is also possible to add more environments or even configure a complex workflow with a chain of deployments, followed or preceded by approvals  etc..

image

Before the deployment, we first need to get the package of the release we are going to deploy. We will be deploying the Expense Claim project, which we managed to build in the previous article. In the Artifacts section you need to do the following:

image

  • Project: K2-CI-Demo
  • Source (Build definition): DemoK2-CI-Demo-CI
  • Default version: Latest
  • Source alias: K2-CI-Demo-CI

Let us also rename the definition we are creating:

image

And before we move on to configuration of the tasks, we should also configure a Release name format.

  • Release name format: Release-$(Build.BuildNumber)_$(Rev:.r)

image

Now we are ready to configure our tasks or, better say, a task. Our deployment will be that simple. First in the Tasks section we need to specify the Agent we will use for our deployment:

image

Below we are adding a Powershell Script task, which will run the deployment script on the target server:

image

We added a Powershell Script task into our process and are ready to configure it:

image

You need to select Inline Script as a Type. And here is the script to use in the Inline Script field:

2. Run and check the results

We can now save our Release definition and test it.  For this you need to add a new release for your definition.

image

Check all the details and click Create button.

image

You will see a new release, added into the list:

image

By opening the release, you can navigate to the Logs tab to see the response from the console on the target machine:

image

Opening the Designer, we can see, the artifacts and even test them:

image

And this is it. The K2 Package, created in the first part of the article, was successfully and automatically deployed onto the target environment. It is also possible to add a more complex powershell script inside your build package, and then run it with the help of VSTS to deploy not only the K2 Package, but also a lot of other project related artifacts.

Feel free to post comments or ask questions. I hope, this article will be useful and it proves even more, that K2 can be used with the DevOps best practices.

Leave a Reply

Your email address will not be published. Required fields are marked *

15 − 13 =