The latest News and Information on Continuous Integration and Development, and related technologies.
Testing in isolation is known to be expensive. It’s time-consuming to execute thoroughly, and it typically requires a testing environment — sometimes multiple testing environments. That said, testing in isolation is undeniably effective.
If you work anywhere near the field of software development, you’ve likely already heard that you should always write code that is well-tested. Everyone wants to have well-tested code and for a good reason! Testing ensures our code is working as intended and protects against regression. Thoroughly testing code helps teams confidently ship software faster and with fewer issues.
Infrastructure as Code (IaC) is the practice of recording the desired state of your infrastructure using a declarative language. In this article, I’m going to assume that your team is starting from scratch. Maybe some of your build process has been scripted, and maybe there is some manual testing and quality assurance work happening. Many readers will find that they are midway through the IaC adoption journey I’ll describe, or that they have missed some steps.
In my interactions at industry events like AWS re:invent and KubeCon, I talk with a lot of developers. Devs often tell stories of things that prevent them from working quickly and efficiently. Many involve frustrating interactions with sys admins, SREs, or DevOps colleagues. One story I have heard several times involves a conversation like this: dev: Hey, SRE team. My build is failing and I don’t know what’s happening with the app in the build node.
