Category name:OctopusDeploy

More sweetness…

I already blogged about ‘OctopusDeploy &TestComplete sweetness!’ and now I ‘d like to add a little more…

First, since we bought a TestComplete Enterprise license we were able to run TestExecute on multiple machines and thus add more servers that could execute tests.

Second, I could see problems coming our way if we we were to keep our test scripts outside of source control or outside the branch.We would run the risk that we’d change the system in such a way that the tests would no longer be correct. I spend some time today on mitigating that problem. Here’s what I did:

  • I wrapped the TestComplete project inside a class library
  • added a deploy.ps1 that does the magic of starting TextExecute
  • set all files to ‘Content & Do not copy’
  • created a package with _PublishedApplications and Octopack
  • set up a server in the environment in the role ‘TestComplete’
  • added a step to the octopus project to deploy the TestComplete package to that server.


Seriously, this setup is starting making me happier every day!

BTW: still bothered by the SMS that is send with every test run…

OctopusDeploy &TestComplete sweetness!

Seriously, this is just sw33t! After a deploy our system is being tested with no less than 2 tests! Smile with tongue out 



Okay, it’s actually a lot sweeter than it sounds. The first test is to check whether our website will return the correct response in case we do not specify an id. This is just a basic test.

The sweetness is in the second test. This test performs a XML post to the API and checks afterwards whether the returned id from the API is collectable on our website. And apparently it is! This test tests the API, the windows service, and the website. That is all there is for our system.

Now on to check whether the SMS that we send arrives…

Running Testcomplete scripts with Octopus Deploy

It was becoming more and more clear that just running a deployment without testing that the deployment has gone as planned, and yesterday we had a deployment gone bad…Luckily it was on the test environment and not on production.

So my conclusion was that we have to do some automated system or UI testing apart from the unit & scenario tests we run in the build. We have just bought a license for Testcomplete ( to automate our tests, so it would be sweet if we could run our tests right after a deployment.

I took a relatively simple test to try to implement in the deployment process: a simple text-check on a webpage. First I had to find out how to start testcomplete from the command line and specify a test. Refer to the documentation for this, because it is well specified how to do this. The step from command line to powershell is a breeze after that.

There is however a problem: Testcomplete doesn’t just return success or failure, it generates logfiles. So we are stuck with the process of extracting the results from the logfile. I run TestComplete in silent mode and export the log to an mht file, which is a multipart mime file. The script unpacks this file, finds the root.xml file amongst all the parts (decodes base64 format) and gets the status code from the xml. You can look in this script to see the details.

After this worked locally I installed a Tentacle on the testcomplete server and tried to start kick off the powershell script with Octopus. It started, but the test result failed because I could not navigate to the website in my script. This is because of the fact that the Tentacle runs as local system and is thus bound to the system. I used an AD user as the service account for Tentacle and it worked as charm.

Happy deploying!

(PS: There might be easier ways to get the results from TestComplete or to parse a multipart mime document. If you know, please tell me, because this is not the most elegant way…)

Octopus deploy at Sound Of Data

Two month ago I blogged Application Lifecycle Management ( I would have given regular updates on progress if it weren’t for an important project for a customer which got in the way. Or did it?

We decided to use the project as a showcase of what can be achieved when Application Lifecycle Management is firmly in place. Here’s what we did.




Development & branching

To begin with we looked at the iterative development process and the branching strategy. We decided that we should keep the Main branch stable whatever it takes, so we developed every user story in a separate branch and merged these in a sprint branch. The main branch would remain untouched until such time as the sprint branch was considered stable.


Build & packaging

We also set up a fully automated build; three of them to be exact. One for continuous integration – with a failing build notification so that the entire team would know that the build was failing and could assist in fixing it – and one that creates some packages to be released on the sprint branch and another one that creates packages for the main branch. The packages were created as described in my blog post (here and here).

The goal was ultimately that these packages would be installable on all environments (Devtest, Test, Acceptance and Production), but the sprint branch packages – the possibly unstable ones – should only be installable on DevTest. To do this we created 2 NuGet repositories (fileshares) that the build would publish to: the sprint branch would be published to our team repository and the main branch would be published to the release repository.



We decided to use Octopus Deploy for our automated deployment tool. We used the following setup to get a smooth deployment cycle. We created 2 environments, 2 project groups and 2 projects: one for the team and one for the real stuff. The team project (group) can only release to the team devtest environment and will release the sprint packages. The release packages that come from the main branch, can be published to Test, Acceptance and Production, the AppSettings that have different values between these environments are being changed by octopus using variables. Octopus does a really great job at this.



So what can we do now? We can deploy that product every time a build is finished. We do not do this automatically, because our tester, not surprisingly, does not enjoy having the devtest environment change during her tests. She’s basically in control; when she’s ready for a new test, she presses the button on the Octopus portal, a new version is deployed and she can start the next test round. (In practice we’re still pressing the button, but that’s an adoption issue…) When she gives the green light for the sprint branch, we merge into the main branch. We run the build and if it succeeds we can start to deploy to test where our tester does her thing again. We deploy to acceptance if all is still well. The same really holds true for deployment to production.

I overheard a colleague say: “Deployment has gotten from being really stressful, to being really boring; I am starting to annoy my colleagues with stupid jokes when releasing software…” Well, at least it is over very quicklyJ.

From here, we now want to go and automate the deployment of all our products. We don’t just want to write software, we want our software to be used.


Happy coding! And deploying, I guess…

PublishedApplications sweetness for TFS Build

I just learned that there exists a nuget package that allows you to build your non-web projects to a ‘_PublishedApplications’ directory just as your web projects are build to a ‘_PublishedWebsites’ directory.

Check it out:

From there on it’s an easy ride to get your build to produce Octopus deploy packages. You can read about it here:

If you want to know all about setting up TFS build for Octopus deploy, check this great walkthrough:


Happy Coding!