Hi, I am running Octopus Deploy version 2.6.5.1010 together with TFS 2012 and have managed to set up automatic deploy of our application to our new test environment.
Now my question is how i should include the tests that we where running in the build and deploy process?
Details:
Our previous deployment process was terrible and included a post-build event that simply copy pasted the output from the build to the target environment, stopping services, publishing dacpacs, starting the processes again. The main problem now is that when using octopus deploy to handle the deploy, the TFS Build does not know when the deployment is finished (at least not in my deployment solution with sending RunOctoPack=true and OctoPackPublishPackageToHttp=xxx as msbuild arguments).
So. How do i go about handling gated checkins tests and nightly builds that include integration tests when using Octopus Deploy?
Thanks for getting in touch! If i understood correctly, this is how you’d like your build & deploy process to look like
Compile and probably run unit tests (TFS)
Pack using Octopack and push to Octopus (TFS)
Deploy (Octopus)
Once (3) finishes successfully, run integration tests against the code that was just deployed (This would ran or at least be triggered from TFS I assume)
Let me know if i got it right so i can give you a proper answer. If i didn’t get it right, please write down your process with steps just like i did so we can work this out toghether
Thats right. As i see it there are two possible scenarios to trigger the Integration Tests:
Build process somehow gets the results of the deploy from octopus(pass/fail) and can decide whether to run integration tests based on this. (How do i get the results of the deploy back to the build process?)
Octopus triggers integration tests from a PostDeploy.ps1 script (don’t know how to trigger these tests that are deployed as dlls from a powershel script, what do I need on host to run them??)
Even though you could do it from Octopus, it is a good practice to run the tests from your build server. You can add an extra step to your build process right after you push the package, where you call our command-line utility Octo.exe to trigger the deployment. This command line tool has a parameter called --progress that will show you the progress of the deployment and that will return an exit code depending on the success or not of the deployment. This way you can tell your Integration Tests step whether to run or not.
Yes! I did this and ran octo.exe create-release --deployTo servername --waitfordeployment seems to be working but will have to get back on this tomorrow.
This seems to be working now. I’m happy to see that it works using TFS but unfortunately I have now removed a lot of the flexibility with lifecycles, environments etc now that I have hardcoded the octo.exe command in the build.proj file in my solution.
I can probably improve my build.proj using variables instead so I will fix that.
I agree that this takes flexibility out of the process. That is mostly because we are trying to fit everything within the boundaries of just one build process (build, unit tests,deploy and integration tests). Even though it is very nice to have everything in one place, sometimes its best to separate the processes a bit. But this of course will depend a lot on your project’s structure
I must admit though that TFS does not provide the flexibility that other build servers like TeamCity provide, where you can easily manipulate your build process, adding command line steps, modifying its version at runtime and even triggering other builds easily using an API. You can do it from TFS, but its just not very intuitive. Luckly TFS is planning on changing that with build vNext, and we already have plans to get right on top of that: http://octopusdeploy.com/blog/octopus-integration-with-tfs-build-vnext
