أين تعيش شيفرتك قرارٌ تجاري لا تقني
برمجياتك أصلٌ لا تعرف على الأرجح أين هو. أربع طرق تفقد بها الشركات الوصول إلى شيفرتها — وما تتطلّبه الملكية الحقيقية.
اسأل شركةً أين أموالها، تأتِك الإجابة فورًا: هذا المصرف، وهذه الحسابات، وهذا الشخص يوقّع. واسأل الشركة نفسها أين شيفرتها المصدرية، فتحتاج الإجابة أسبوعًا وثلاث مكالمات ورسالة واتساب مرتبكة قليلًا إلى مبرمجٍ غادر سنة 2024.
هذا التفاوت غريب، لأن المستودع البرمجي في شركةٍ تعمل ببرمجيات مخصّصة ليس تفصيلًا تقنيًا، بل هو الشيء الذي دفعت ثمنه. أمّا كل ما عداه — الموقع الذي يعمل، والتطبيق في المتجر، والمنصة التي يفتحها موظفوك كل صباح — فمُخرجاتٌ له.
أربع طرق تفقد بها الشركات شيفرتها
لا واحدة منها تتضمّن سوء نية من أحد؛ كلها انجراف.
- الشيفرة على حساب شخصي. المستودع تحت حساب فردي لمبرمج على منصة عامة. لا مؤسسة للشركة هناك، ولا علاقة فوترة، ولا صلاحية إدارية. وحين يمضي ذلك الشخص في طريقه يمضي الأصل معه — لا لأنه سرقه، بل لأن أحدًا لم يضعه في مكانٍ آخر قط.
- مسؤولٌ واحد لا غير. قد يكون المستودع في مؤسسةٍ باسم الشركة، لكن إنسانًا واحدًا يحمل صلاحية المالك الوحيدة. يكفي مرضٌ أو استقالة أو عامل تحقّقٍ ثانٍ منسيّ، لتُغلق الشركة خارج حسابها هي، بلا مسار استرداد.
- خط النشر حاسوب محمول. الشيفرة سليمة، لكن معرفة كيف تتحوّل إلى نظامٍ يعمل ليست مكتوبةً في أي مكان. النشر هو سجلّ أوامر شخصٍ واحد. المستودع ينجو، أمّا القدرة على الإطلاق فلا.
- توقّف الفاتورة. بطاقة مرفوضة، ووسيلة دفع منتهية، وطلبات تحقّقٍ من مزوّدٍ دولي يصعب تلبيتها من العراق. الحسابات تُعلَّق بسبب احتكاكٍ إداري أكثر بكثير مما تُعلَّق لأسبابٍ دراماتيكية — ويحدث ذلك دائمًا في الأسبوع الذي تحتاج فيه إلى النشر.
ماذا يجب أن تعني «شيفرتنا ملكنا» فعلًا
الملكية ليست ملفًّا مضغوطًا أرسله أحدهم بالبريد يوم التسليم. الملف المضغوط لقطةٌ بلا تاريخ، ولا فروع، ولا سجلّ مراجعة، ولا طريقة لمعرفة أي نسخةٍ هي التي تعمل في الإنتاج. الملكية الحقيقية ستة أشياء:
- المستودع بتاريخه الكامل. كل تعديل، وكل فرع، وكل إصدار. التاريخ هو ما يخبرك متى ظهر خللٌ وما الذي أُطلق معه.
- خطوط البناء والنشر. معرَّفة ومُصدَّرة بجانب الشيفرة، حتى يكون الإطلاق عمليةً موثّقة لا شخصًا.
- الحزم. المكتبات الداخلية منشورة في مكانٍ تتحكّم به الشركة، لا في حساب سجلٍّ شخصي.
- صلاحيات تديرها أنت. تضيف الناس وتزيلهم، ويُفضَّل عبر تسجيل الدخول نفسه الذي يستخدمه موظفوك، حتى يزيل إنهاءُ خدمةِ موظفٍ وصولَه من كل مكان فعلًا.
- المفاتيح والأسرار. مفاتيح النشر ومتغيّرات البيئة بحوزة الشركة، وتُبدَّل عند مغادرة أي شخص.
- خروجٌ رخيص. القدرة على نقل ما سبق كله إلى مكانٍ آخر دون مشروع هجرة — وهذه خاصيّة في الصيغة نفسها، لا وعدٌ من مورّد.
Git القياسي هو ما يجعل الخروج رخيصًا
تستحق هذه النقطة انتباهًا أكثر مما تنال عادةً. مستودع Git بنيةٌ قياسية قابلة للنقل: استنسخه فيصير تاريخه كاملًا على قرصك أنت. وأي خدمةٍ تخزّن شيفرتك بصيغة Git القياسية يمكن مغادرتها بأمرٍ واحد، لأن المغادرة ليست إلا استنساخًا في مكانٍ آخر.
وما لا يُنقل هو كل ما تبنيه المنصة حول المستودع: القضايا، ونقاشات المراجعة، وتعريفات خطوط البناء بصيغة خاصة، وسجلات الحزم، والصلاحيات. هناك يسكن الاحتجاز الحقيقي. والسؤال العملي للمورّد ليس «هل أستطيع التصدير؟» بل «إن غادرت الشهر القادم، ما الذي سأفقده ولا أستطيع إعادة بنائه؟»
سحابة أم داخل مبناك؟
كلاهما خيار مشروع، والقرار عادةً يتعلّق بمن يطرح السؤال أكثر مما يتعلّق بالتقنية.
| اختر الاستضافة المُدارة حين | اختر التشغيل الذاتي حين |
|---|---|
| لا يوجد لديك من وظيفته البنية التحتية | تشغّل خوادم أصلًا ولديك من يتولّاها |
| الفريق موزَّع ويحتاج الوصول من أي مكان | تُلزمك جهة تنظيمية أو عقد عميل أو سياسة بإبقاء الشيفرة داخل شبكتك |
| تريد أن تكون الترقيات والنسخ الاحتياطية مشكلة غيرك | تحتاج النشر بجوار أنظمةٍ لا تغادر شبكتك الخاصة أبدًا |
| ثبات التكلفة أهم من التحكّم | التحكّم أهم من الراحة |
وأسوأ إجابةٍ هي الإجابة العَرَضية: لم يقرّر أحد، فانتهت الشيفرة حيث صادف أن كان لأول مبرمجٍ حساب.
تدقيق الخمس دقائق
لا تحتاج استشاريًا لهذا. خذ خمس دقائق وحاول الإجابة بصوتٍ عالٍ:
- أين شيفرتنا المصدرية الآن، وباسم من الحساب؟
- من يملك صلاحية المالك — وهل هم أكثر من شخصٍ واحد ما زال يعمل معنا؟
- لو اختفى كبير مبرمجينا غدًا، هل نستطيع نشر إصلاحٍ يوم الخميس؟
- هل عملية النشر مكتوبة، أم في رأس أحدهم؟
- حين يغادر موظف، ما الإجراء الواحد الذي يزيل وصوله إلى كل شيء؟
- من يدفع فاتورة المنصة، وماذا يحدث إن فشلت تلك البطاقة؟
كل سؤالٍ لا تستطيع الإجابة عنه بجملة هو خطرٌ تحمله اليوم دون أن تسعّره.
لماذا بنينا PearlGit
بنينا PearlGit لأننا احتجنا كل ما سبق لمنتجاتنا نحن أولًا: طلبات دمجٍ بمراجعين إلزاميين وفحوصٍ تمنع الدمج حتى تنجح، وCI/CD يعمل حيث تعيش الشيفرة، وسجلات حزمٍ تحت نموذج الصلاحيات نفسه، وتسجيل دخولٍ مرتبط بالحسابات التي يملكها فريقنا أصلًا.
وقراران تصميميّان هما الأهم لأي عمل. الأول أنه Git قياسي في جوهره، فيبقى خروجك رخيصًا، وتصل الهجرة من منصةٍ أخرى بتاريخها كاملًا. والثاني أنه يعمل في سحابتنا أو كالبرنامج نفسه داخل شبكتك الخاصة — والاختيار قابلٌ للتغيير لاحقًا، لا مفترق طريقٍ تسلكه مرة واحدة. كما أن الواجهة معرَّبة بالكامل، أكثر من أربعة آلاف نص بتخطيطٍ حقيقي من اليمين إلى اليسار، ليراجع الفريق الذي يفكّر بالعربية شيفرته بالعربية.
وأيًّا كان اختيارك، اتّخذه عن قصد. فالشركة القادرة على الإجابة عن «أين شيفرتنا؟» بجملةٍ واحدة شركةٌ قادرة على النجاة من تبدّل موظفيها — وتلك خاصيّة تجارية لا تقنية.