{"id":31863,"date":"2021-01-13T00:00:00","date_gmt":"2021-01-12T23:00:00","guid":{"rendered":"https:\/\/blexin.com\/?p=31863"},"modified":"2021-05-20T18:18:17","modified_gmt":"2021-05-20T16:18:17","slug":"integration-test-with-pulumi-and-azure-kubernetes-service","status":"publish","type":"post","link":"https:\/\/blexin.com\/en\/blog-en\/integration-test-with-pulumi-and-azure-kubernetes-service\/","title":{"rendered":"Integration test with Pulumi and Azure Kubernetes Service"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

We are carrying out update activities on some products for one of our clients, gradually migrating to microservice architectures. One of these products has followed the policy of “do not touch what works” for a long time, and as a result, it becomes unmanageable over time. Some classes representing business logic have grown beyond measure, becoming very complex to modify, with insufficient test coverage and a business logic shared between the various domains that coexist in the same codebase.<\/p>\n\n\n\n

All these factors made it difficult to maintain the system, and it was therefore decided to gradually evolve the code into different services. Unfortunately, business logic has remained shared between domains, and, currently, this sharing is the most important problem.<\/p>\n\n\n\n

To properly divide the logic between various (micro)services and continue to deploy value without introducing regressions or unexpected malfunctions, we need to make sure that the modifications do not change the expected behavior of the software and, as always, the best weapon is to have a codebase well covered by testing.<\/p>\n\n\n\n

Unit Tests<\/strong> are very useful for the purpose, but they are not enough to make us confident about the changes we make to the logic. We also need to be able to test the interactions between two or more generated (micro)services, performing them in a temporary environment as close as possible to the production one, called Ephemeral Environment<\/strong>. In other words, we need an Integration Test <\/strong>suite.<\/p>\n\n\n\n

To succeed in our aim is very useful the concept of Infrastructure as Code<\/strong> (Iac), which consists of representing the infrastructure (network, virtual machine, load balancer, and connection) in a descriptive way through the code. Following the principle that the same code always generates the same library, the same model of Iac always generates the same environment every time it is applied. By describing our target environment, then, we can share the same configuration between development teams and operations.<\/p>\n\n\n\n

We use an Iac framework to recreate an Ephemeral environment in which our services could run, simulating the production environment. This also allowed us to isolate all external dependencies outside the scope of our logic. Recreated the environment, we built an integration test suite that could validate logic and simplify the addition of new features to the product.<\/p>\n\n\n\n

Among the many Iac frameworks on the market, Pulumi<\/strong><\/a>, was chosen, which provides a CLI, a runtime, libraries, and a hosting service that work together. It allows you to deliver, provision, update and manage infrastructure in the Cloud, supporting multiple languages, including Typescript, Javascript, Python, Go, and.NET, and their native tools, libraries, and package managers. Pulumi works on almost all cloud providers or alternatively on an instance of Kubernetes <\/strong>(k8s); wanting to test locally, we can then use minikube<\/strong><\/a> or kind<\/strong><\/a>.<\/p>\n\n\n\n

A Pulumi program has the following components:<\/p>\n\n\n\n