<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>CI/CD &amp; DevOps on dplabs — Software Engineering &amp; Technology Consultancy</title>
		<link>https://dplabs.tech/categories/ci/cd--devops/</link>
		<description>Recent content in CI/CD &amp; DevOps on dplabs — Software Engineering &amp; Technology Consultancy</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Tue, 28 Jul 2026 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://dplabs.tech/categories/ci/cd--devops/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Trunk-Based Development vs GitFlow: What the Debate Is Actually About</title>
				<link>https://dplabs.tech/blog/trunk-based-vs-gitflow/</link>
				<pubDate>Tue, 28 Jul 2026 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/trunk-based-vs-gitflow/</guid>
				<description>&lt;p&gt;The branching strategy debate is loudly opinionated in both directions. GitFlow advocates point to clean release management and isolated feature development. Trunk-based development advocates point to the evidence that short-lived branches correlate with higher engineering performance. Both sides are often talking past each other.&lt;/p&gt;&#xA;&lt;p&gt;The useful question is not &amp;ldquo;which is better&amp;rdquo; but &amp;ldquo;which fits our context&amp;rdquo; — and the context includes team size, release cadence, engineering practices, and the nature of the software being delivered.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Database Migrations in Continuous Delivery</title>
				<link>https://dplabs.tech/blog/database-migrations-continuous-delivery/</link>
				<pubDate>Mon, 04 Aug 2025 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/database-migrations-continuous-delivery/</guid>
				<description>&lt;p&gt;Every CI/CD guide covers application deployment. Very few cover the harder problem: database schema changes in a system that can never be offline.&lt;/p&gt;&#xA;&lt;p&gt;The challenge is that application and database deployments are not atomic. During a rolling or blue-green deployment, old and new application versions run simultaneously against the same database. A migration that&amp;rsquo;s incompatible with the old version causes the old version to fail — precisely during the deployment window when you can least afford failures.&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>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>
