Testing microservices shouldn’t be that different from testing a monolithic application. However, there are some challenges we must address to make this transition easy. The question to answer is, “how do we perform functional tests on a decomposed application?”
As we move away from monolithic practices and into a Kubernetes microservice environment, we lose the concept of an application version. Instead we are faced with lots of loosely-coupled, independent functions with RESTful APIs. While the concept of API contract testing applies at the unit testing level, we have work to do to pull together our functional testing harness.
Testing microservices at a functional level
Unit testing individual APIs or microservices does not validate the readiness of a full application release. For this reason, we can not eliminate the functional testing process entirely. If we do, we risk missing situations where one microservice is using an older version of another microservice, and that causes an adverse impact. This level of anomaly can only be found when we perform functional testing on the application as a complete product.
In monolithic environments, the application version is our release candidate. A new release candidate initiates the work done by our functional test harness, which in many cases lags behind the development sprints that perform unit testing on the API contracts. While development teams may make incremental coding changes, functional testing is based on a full release candidate, and the release of that candidate causes the execution of an entirely different set of linked test cases. When testing microservices, this level of functional testing is still required and critical.
Ideally, we want to leave our functional testing in place even when our application is built on a set of loosely coupled services. To do this, we need visibility into the logical application version. In order to remain efficient at the functional testing level, we need some insights into what has changed between two application versions, allowing the functional testing to be targeted. What we want to avoid is constantly retesting everything simply because we have no reference as to which microservice caused a new release of the application version.
Re-imagining continuous integration
In monolithic environments, we rely on our application build (compile/link) to create a new version of the application, creating a new release candidate. This new version is then pushed to the testing team to execute a functional test. With microservices, this build goes away. Instead, our build takes a single microservice and builds a new container image. That container image is then pushed up to a container registry. Now we have a new microservice release candidate, which in turn created a new application version release candidate. Welcome to your new continuous integration process.
Testing microservices
DeployHub resurrects the application version in a microservices implementation to support your functional testing. It does this using automated configuration management that automatically creates new application versions each time a new microservice has been registered. Since microservices are shared, a new microservice will often create multiple application release candidates. DeployHub tracks the microservice impact to all consuming applications. This impact analysis allows DeployHub to then inform CircleCI to initiate testing workflows for multiple applications, providing details on exactly which microservices caused the new application release.
The DeployHub orb
The DeployHub orb integrates into CircleCI to perform automated configuration management as soon as a new container has been created and registered. DeployHub then automatically increments the application version of all impacted applications, and runs the workflow of each. DeployHub uses a key value pair at the application level to specify the default testing environment for deployment and the name of the CircleCI testing pipeline to run post deployment. Additionally, DeployHub provides an impact analysis view that shows, at each application level, which microservice initiated the change.
See it in action
We’ve made it easy for you. Check out our demo of the DeployHub-CircleCI integration.
Conclusion
Testing microservices and their consuming applications becomes much easier with DeployHub integrated into your CircleCI pipelines. Testing becomes driven by an automated process triggered by a release candidate event, in much the same way as we did with monolithic environments. Your functional testing suite remains unchanged and insights show you the impact of a single microservice update on all applications.
About DeployHub
DeployHub empowers organizations to achieve business agility through a managed approach to microservices. DeployHub eliminates the confusion and complexity common with microservices by providing a SaaS centralized view of microservice usage and sharing across clusters and teams.
For more information and to use the DeployHub CircleCI orb, find us on the CircleCI orb registry. You can also learn more about DeployHub at DeployHub.com. DeployHub is based on the Ortelius Open Source Project.
