Service Virtualization

Chapter 4. Service Virtualization and Continuous Delivery

This chapter provides an overview of the role that service virtualization can play in an organization that uses Continuous Delivery (CD) to maximize their speed of application development and release. We’ll take a look at how both concepts fit together, and what additional benefits are gained from containerizing your virtualized test environments.

The Role of Service Virtualization in the CD Process

Organizations that are embracing CD as a means of bringing software to production in a fast and flexible manner can’t do without the ability to test their applications in a continuous and automated manner. This implies that suitable (with regard to configuration and test data, for example) test environments should be available on demand, something that is proving to be very difficult to do without service virtualization.

Although development teams usually can get by with dependency mocking in the early stages—most notably when writing and executing unit tests—it is becoming increasingly difficult to manage real test environments in the later stages (for integration and end-to-end testing) in such a way that continuous testing can be facilitated. Two of the most important problems related to this are synchronization of test data across dependencies and lack of availability of all dependencies required at the same time.

Building and using simple stubs might work when the technology and behavior to be simulated is relatively straightforward. But modern heterogeneous environments and composite applications comprising a lot of different types of components and dependencies (web services, databases, mainframes, ERP systems, SaaS solutions) require a more sophisticated, enterprise-level solution. This is exactly where service virtualization comes into play.

We need to give you one warning, though: even though service virtualization has potentially many benefits to your development and testing activities, you shouldn’t rely solely on it and forget about “the real world.” There are some very good reasons for methodically testing against real dependencies:

• While setting up virtual assets, you might choose not to model certain dependency characteristics for the purpose of speed or flexibility. This applies especially to nonfunctional aspects such as security and performance. To be sure that your system under test is able to cope with these aspects, as well, test it against real dependencies.
• Over time, your virtual asset definition might become out of sync with the dependency being simulated. Although it’s no substitute for proper communication and version control, testing against the real dependency every now and then is a good way of detecting these changes.

A typical CD process takes care of the above by having code tested against an increasing number of real implementations as the code progresses through the pipeline. In the early stages, tests are run mainly against simulations as a way to balance cost of dependency management and speed. Here, the majority of defects will be, or at least should be, caught. As the code moves closer toward the production environment, virtual assets are traded for real dependencies, as depicted in Figure 4-1.

Figure 4-1. Trading virtual assets for actual dependencies as code moves through the Continuous Delivery pipeline

Containerizing Virtual Test Environments

Using service virtualization as an enabler for CD brings many benefits of its own. However, when we treat the virtual environments as artifacts in that CD process, just like the system under test itself, and combine this approach with the power of cloud computing, we really take service virtualization to the next level.

A sample CD cycle, powered by containerized service virtualization, could follow a path that looks as follows:

1. A developer commits his code changes to a version control system such as Git or Subversion.

2. The build server, for example Jenkins or Atlassian Bamboo, triggers a new build and run unit tests to ensure code quality on the unit level.

3. After unit tests pass, the system under test is deployed on a test environment that is created dynamically on a public or private cloud server.

   Simultaneously, a virtual test environment is created and provisioned on its own public or private cloud server. Test environment configuration is set so that the desired behavior, test data sets and performance characteristics (for example) are enabled.

4. Tests (system, integration, or end-to-end) are run against the system under test, which in turn communicates with the virtual assets in the simulated test environment.

5. After these tests pass, the system under test is deployed safely into a production environment. Meanwhile, the cloud test environments are deprovisioned and removed, ready to be re-created in the next cycle.

Figure 4-2 offers a graphic representation of this process.

Figure 4-2. Containerized service virtualization as an enabler for CD

In this chapter, we looked at how you can combine CD and service virtualization to deliver quality software at the speed that today’s competitive markets demand. The next chapter discusses the role service virtualization plays in and the associated benefits for a number of other IT trends.