<?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/tags/azure/</link>
    <description>Recent content in Azure on Machine-Cycle</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>it</language>
    <lastBuildDate>Sun, 29 Aug 2021 10:00:00 +0200</lastBuildDate><atom:link href="https://machine-cycle.pages.dev/tags/azure/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Test di integrazione con Pulumi ed Azure Kubernetes Service</title>
      <link>https://machine-cycle.pages.dev/posts/integration_test_pulumi/</link>
      <pubDate>Sun, 29 Aug 2021 10:00:00 +0200</pubDate>
      
      <guid>https://machine-cycle.pages.dev/posts/integration_test_pulumi/</guid>
      <description>Vediamo come sfruttare Infrastructure as Code per il provisioning e il testing in un ambiente di integrazione Per un nostro cliente stiamo svolgendo delle attività di svecchiamento su alcuni prodotti, migrando gradualmente verso architetture a microservizi. Uno dei prodotti in questione ha seguito per molto tempo la politica del “non toccare ciò che funziona”, con il risultato di diventare ingestibile con il passare del tempo. Alcune classi che rappresentano la logica business sono cresciute a dismisura, diventando molto complesse da modificare, con una copertura dei test insufficiente e con una logica di business condivisa tra i vari domini che convivono nella stessa codebase.</description>
    </item>
    
  </channel>
</rss>
