Adding service virtualization to your Continuous Delivery pipeline

Lately I’ve been working on a couple of workshops and presentations on service virtualization and the trends in that field. One of these trends – integrating virtualized test environments, containerization and Continuous Delivery – is starting to see some real traction within the service virtualization realm. Therefore I think it might be interesting to take a closer look at it in this post.

What is service virtualization again?
Summarizing: service virtualization is a method to simulate the behaviour of dependencies that are required to perform tests on your application under test. You can use service virtualization to create intelligent and realistic simulations of dependencies that are not available, don’t contain the required test data or are otherwise access-restricted. I’ve written a couple of blog posts on service virtualization in the past, so if you want to read more, check those out here.

Service virtualization

Continuous Delivery and test environment challenges
The challenges presented by restricted access to dependencies during development and testing grow stronger when organizations are moving towards Continuous Delivery. A lack of suitable test environments for your dependencies can be a serious roadblock when you want to build, test and ultimately deploy software on demand and without human intervention. You can imagine that having virtual assets that emulate the behaviour of access-restricted components at your disposition – and more importantly: under your own control – is a significant improvement, especially when it comes to test execution and moving up the pipeline.

Using virtual test environments as artefacts in your pipeline
While having virtual test environments run at some server in your network is already a big step, ‘the next level’ when it comes to service virtualization as an enabler for Continuous Delivery is treating your virtual assets as artefacts that can be created, used and ultimately destroyed at will. I’ll talk about the specific benefits later, but first let’s see how we can achieve such a thing.

One way of treating your virtual test environments as CD artefacts is by containerizing them, for example using Docker. With Docker, you can for example create an image that contains your service virtualization engine, any virtual assets you would like to use and – if applicable – data sources that contain the necessary test data to emulate the required behaviour.

Another way of creating virtual test environments on demand is by hosting them using an on-demand cloud-based service such as Microsoft Azure. This allows you to spin up a simulated test environment when required, use and abuse it and destroy it after you are (or your deployment process) is done.

At the time of writing this blog post, I’m preparing a workshop where we demonstrate – and have the participants work with – both of these approaches, and while the technology is still pretty new, I think this is an interesting and exciting way of taking (or regaining) full control of your test environments and ultimately test faster, more and better.

Adding containerized service virtualization to your continuous delivery pipeline

Benefits of containerized test environments
Using containerized test environments in your Continuous Delivery process has a couple of interesting advantages for your development and testing activities:

  • As said, test environments can be spun up on demand, so no more waiting until that dependency you need is available and configured like you need it to be.
  • You don’t need to worry about resetting the test environment to its original state after testing has completed. Just throw the test environment away and spin up a new instance ready for your next test run.
  • Having the same (virtual) test environment at your disposal every time makes it easier to reproduce and analyze bugs. No more ‘works on my machine’!

Further reading
Want to read more about containerized service virtualization? See for an example specific to Parasoft Virtualize this white paper. And keep an eye out for other service virtualization tool vendors, such as HP and CA. They’re likely working on something similar as well, if they haven’t released it already.

Also, if you’re more of a hands-on person, you can apply containerization to open source service virtualization solutions such as HoverFly yourself.

6 thoughts on “Adding service virtualization to your Continuous Delivery pipeline

  1. Pingback: Java Web Weekly, Issue 132 | Baeldung

  2. Though provoking, to be sure. Must put this on my ‘to-do’ readlng list as we move toward the bright new world of continuous-everything 😉


    • Oh, and by the way, a little booklet written by me will be released next month with an overview of service virtualization and how it can be applied to various IT methods, practices and trends. I’ll surely publish a post to announce it once it’s available.. This might be interesting to you too..

      • That’s wonderful news Bas. If u want someone 2 review it b4 it goes out the door i have some spare time. Most of my doc.s are done in asciidoctor – ( a bit like Markdown syntax ) and it outputs html, docbook or pdf’s but i can do other stuff too. Cheatsheet is here:
        – just an idea ;-}

        i also started looking up ‘continuous’ topics and found Jonathan’s team doing something like this so have sent ur details to them too. See:

        Will come back 2 u with more questions if thats ok?
        Thanx in advance

        • Hey Jim,

          Reviewing is currently in progress (coordinated by the publisher) so thanks, but maybe another time. I used their content management system to write the report, which is built on top of Git. Pretty cool stuff!

          Thanks for forwarding my stuff, no problem! And keep those questions coming, I’ll do my best to answer them.

Leave a Reply

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