<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Azure on Machine-Cycle</title>
    <link>https://machine-cycle.pages.dev/en/tags/azure/</link>
    <description>Recent content in Azure on Machine-Cycle</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Sun, 29 Aug 2021 10:00:00 +0200</lastBuildDate><atom:link href="https://machine-cycle.pages.dev/en/tags/azure/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Integration test with Pulumi and Azure Kubernetes Service</title>
      <link>https://machine-cycle.pages.dev/en/posts/integration_test_pulumi/</link>
      <pubDate>Sun, 29 Aug 2021 10:00:00 +0200</pubDate>
      
      <guid>https://machine-cycle.pages.dev/en/posts/integration_test_pulumi/</guid>
      <description>Let&amp;rsquo;s see how to use Infrastructure as Code for the provisioning and the testing in an integration environment 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.</description>
    </item>
    
  </channel>
</rss>
