<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Migration on Daffa Abhipraya</title><link>https://blog.abhipraya.dev/tags/migration/</link><description>Recent content in Migration on Daffa Abhipraya</description><generator>Hugo</generator><language>en-us</language><copyright>© Daffa Abhipraya</copyright><lastBuildDate>Thu, 12 Mar 2026 00:00:00 +0700</lastBuildDate><atom:link href="https://blog.abhipraya.dev/tags/migration/index.xml" rel="self" type="application/rss+xml"/><item><title>PPL: Building a Production-Safe Migration Pipeline with Automated Rollback</title><link>https://blog.abhipraya.dev/ppl/part-a/data-seeding/</link><pubDate>Thu, 12 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-a/data-seeding/</guid><description>&lt;h2 id="why-database-migrations-need-safety-nets">
 &lt;a class="anchor" href="#why-database-migrations-need-safety-nets" data-anchor="why-database-migrations-need-safety-nets" aria-hidden="true">#&lt;/a>
 Why Database Migrations Need Safety Nets
&lt;/h2>
&lt;p>Imagine this scenario: a developer adds a new column to the invoices table, pushes to &lt;code>main&lt;/code>, and the CI/CD pipeline deploys it to production. Everything looks fine until the next morning, when the team discovers that the migration also dropped a constraint that was silently relied on by another service. Rolling back means manually writing SQL against the production database at 2 AM.&lt;/p></description></item></channel></rss>