أتمتة Migration Safety للمحترف: امنع downtime من ALTER TABLE قبل ما يلمس الإنتاج

GitHub Actions workflow كامل

الـ workflow بيشتغل فقط على PRs اللي بتعدّل ملفات تحت db/migrations/، وبيمشي Squawk على الملفات الجديدة فقط مش الـ repo كله. متوسط الزمن: 38 ثانية على PR فيه 3 ملفات migration.

سيناريو واقعي: 14 دقيقة downtime على جدول الطلبات

فريق fintech عربي عنده 24 microservice و12 مهندس بيدفعوا في المتوسط 6 migrations أسبوعياً على PostgreSQL 16. قبل ما يفعّلوا Squawk:

• 3 حوادث downtime في 8 شهور بسبب ALTER TABLE على جداول أكبر من 40 مليون صف.
• أطول حادثة: 14 دقيقة قفل تام على جدول orders، خسارة مبيعات تقديرية ~$3,800 + 47 شكوى عميل في الـ support.
• متوسط زمن الاستجابة على incident: 6 دقايق قبل ما حد ياخد باله إن المشكلة في migration للتو دخل.

بعد إضافة الـ workflow وتفعيله على branch protection rule كـ required check:

• 47 PR اترفض تلقائياً في 6 شهور. الأغلبية: نسيان CONCURRENTLY في CREATE INDEX (28 حالة)، وNULL constraints (11 حالة).
• صفر حوادث downtime ناتجة عن DDL في نفس الفترة.
• زمن CI زاد 38 ثانية فقط على الـ PRs اللي بتلمس migrations، صفر على باقي PRs.
• ساعات الـ DBA الموفّرة في المراجعة اليدوية: ~14 ساعة شهرياً.

القواعد الخمس الأهم اللي Squawk بيمسكها

1. require-concurrent-index-creation — يفرض CREATE INDEX CONCURRENTLY على جداول الإنتاج.
2. adding-not-nullable-field — يرفض NOT NULL بدون default ثابت أو سلسلة backfill صحيحة.
3. changing-column-type — يحذّر من ALTER COLUMN TYPE اللي بيعيد كتابة الجدول (مثلاً INT → BIGINT بدون USING).
4. disallowed-unique-constraint — يطلب ALTER TABLE ... ADD CONSTRAINT ... UNIQUE USING INDEX بدل ADD UNIQUE المباشر.
5. renaming-column — يحذّر إن العملاء القدام (apps قديمة، dashboards) ممكن يكسروا فجأة.

trade-offs خفية لازم تفهمها

الأداة دي مش سحر. هي بتمسك syntax بشكل أساسي مش semantics. التفاصيل اللي بتفرق:

• بتكسب: فحص آلي على ~80% من أخطاء DDL الشائعة، صفر تكلفة، 38 ثانية CI overhead، صفر صيانة بعد الإعداد الأولي.
• بتخسر 1: false positives على ALTER TABLE مقصود على جدول صغير (مثلاً جدول config فيه 12 صف). الحل: -- squawk-ignore adding-not-nullable-field فوق السطر.
• بتخسر 2: الأداة مش بتعرف حجم الجدول. ALTER على جدول 1,000 صف مش خطر، لكن Squawk هيشتكي بنفس الحدة.
• بتخسر 3: مش بديل لـ EXPLAIN ANALYZE ولا staging environment بحجم إنتاج. هي طبقة دفاع أولى، مش الوحيدة.
• بتخسر 4: لو فريقك بيستخدم raw SQL داخل application code (مش ملفات migration منفصلة)، الـ workflow ده مش هيمسكه.

متى لا تستخدم هذه الطريقة

لو فريقك بيستخدم ORM بـ auto-migrations زي Django Migrations أو Rails Active Record بدون ملفات SQL خام، Squawk مش هيشتغل مباشرة. هتحتاج تطلّع الـ SQL أولاً عبر ./manage.py sqlmigrate <app> <migration> أو rails db:migrate:status، وتمشي Squawk على المخرج. ده ممكن، بس بيضيف خطوة في الـ CI.

لو DB بتاعتك MySQL أو MariaDB، الأداة الأنسب هي gh-ost + sqlcheck، مش Squawk. وSquawk حالياً بيدعم Postgres dialect فقط بشكل دقيق.

لو الفريق أقل من 3 مهندسين، والـ DB أصغر من 5 مليون صف، الـ overhead المعرفي ممكن يكون أكبر من الفائدة. ابدأ بـ peer review صارم وقالب PR فيه checkbox "هل ALTER TABLE ده آمن على حجم الإنتاج؟"، وأضف Squawk لما تتوسع.

الخطوة التالية

افتح .github/workflows/migration-safety.yml في الـ repo وانسخ الـ workflow اللي فوق كما هو. بعدين شغّل Squawk محلياً على آخر 10 migrations دمجتها في main:

لو طلع عندك أكتر من تحذيرين، الـ ROI واضح من اليوم الأول. لو طلع صفر، عندك إما فريق منضبط أو جدول صغير — في الحالتين Squawk هيفضل تأمين مجاني للمستقبل.

المصادر

• توثيق Squawk الرسمي — squawkhq.com/docs/rules — قائمة كل الـ 38 قاعدة مع أمثلة.
• PostgreSQL Documentation v16 — Notes on ALTER TABLE — شرح أنواع القفل و AccessExclusiveLock.
• Braintree Engineering Blog (2017) — Safe Operations for High Volume PostgreSQL — جدول العمليات الخطرة وبدائلها الآمنة.
• Strong Migrations gem (Ruby) — مصدر الإلهام لجزء كبير من قواعد Squawk.
• PostgreSQL Wiki — Don't Do This — anti-patterns موثقة من الـ core team.
• GitHub PostgreSQL #21443 — تحسين ADD COLUMN ... NOT NULL DEFAULT في PG 11+ للقيم الثابتة.