<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Devops on dplabs — Software Engineering &amp; Technology Consultancy</title>
		<link>https://dplabs.tech/tags/devops/</link>
		<description>Recent content in Devops on dplabs — Software Engineering &amp; Technology Consultancy</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Mon, 01 Jun 2026 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://dplabs.tech/tags/devops/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Infrastructure as Code Is Software</title>
				<link>https://dplabs.tech/blog/infrastructure-as-code-is-software/</link>
				<pubDate>Mon, 01 Jun 2026 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/infrastructure-as-code-is-software/</guid>
				<description>&lt;p&gt;Infrastructure as Code emerged as a response to the problem of undocumented, inconsistent, manually-managed infrastructure. Click-ops servers where nobody knows what&amp;rsquo;s actually configured. Snowflake environments that differ from production in undocumented ways. Infrastructure that can&amp;rsquo;t be reproduced.&lt;/p&gt;&#xA;&lt;p&gt;IaC solved these problems by treating infrastructure as code. The irony is that many teams write infrastructure code with none of the engineering rigor they apply to application code. No reviews, no tests, no code quality standards, no documentation. The result: IaC that has the same problems as the click-ops it replaced, plus the added complexity of Terraform state files.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Deployment Strategies: Blue/Green, Canary, and Rolling Deployments</title>
				<link>https://dplabs.tech/blog/deployment-strategies/</link>
				<pubDate>Mon, 12 May 2025 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/deployment-strategies/</guid>
				<description>&lt;p&gt;A deployment strategy is not just a technical implementation detail. It determines how much risk you take with each release, how quickly you can recover from problems, and what infrastructure you need to support it. Choosing without understanding the trade-offs is choosing accidentally.&lt;/p&gt;&#xA;&lt;h2 id=&#34;rolling-deployments-the-default&#34;&gt;Rolling Deployments: The Default&lt;/h2&gt;&#xA;&lt;p&gt;Rolling deployments incrementally replace old instances with new ones. At any point during the deployment, both old and new versions are running simultaneously.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Terraform: Modules, State, and the Hidden Complexity</title>
				<link>https://dplabs.tech/blog/terraform-modules-state/</link>
				<pubDate>Mon, 21 Apr 2025 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/terraform-modules-state/</guid>
				<description>&lt;p&gt;Terraform is the dominant infrastructure as code tool for AWS, GCP, and Azure workloads. Getting started is straightforward. Operating it at scale — across multiple teams, environments, and hundreds of resources — surfaces complexity that the getting-started tutorials don&amp;rsquo;t address.&lt;/p&gt;&#xA;&lt;p&gt;This article focuses on the operational lessons: state management, module architecture, and the patterns that keep Terraform manageable as infrastructure grows.&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt;: Terraform is developed by HashiCorp under the BSL license. OpenTofu is the open-source MIT-licensed fork, API-compatible with Terraform 1.5. For teams that require a fully open-source toolchain, OpenTofu is the alternative to evaluate.&lt;/p&gt;</description>
			</item>
			<item>
				<title>CI/CD Is a Feedback Loop, Not a Deployment Tool</title>
				<link>https://dplabs.tech/blog/cicd-is-a-feedback-loop/</link>
				<pubDate>Mon, 25 Nov 2024 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/cicd-is-a-feedback-loop/</guid>
				<description>&lt;p&gt;Most CI/CD implementations optimize for the wrong thing. They treat the pipeline as a deployment automation tool — a mechanism for running tests and pushing artifacts to production. The tests pass, the deploy runs, work is done.&lt;/p&gt;&#xA;&lt;p&gt;This framing misses the fundamental value of continuous integration and continuous delivery: &lt;strong&gt;compressing the feedback loop between writing code and understanding its consequences&lt;/strong&gt;.&lt;/p&gt;&#xA;&lt;p&gt;The faster that loop runs, the faster defects are caught, the smaller the blast radius of errors, and the more confidence engineers have when deploying. Everything else follows from this.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
