"لسنا على التحكم بالمصدر بعد" إشارة إيجابية لا مصدر إحراج

الإجابة المختصرة: الفريق الذي ما زال ينشر بـ change sets ليس متأخرا، بل هو فريق غير مثقل. لا يوجد عنده خط تسليم نصف مبني يحتاج تفكيكا، ولا نموذج فروع مهجور يحتاج شرحا، ولا سكربتات كتبها شخص غادر الشركة. أسبوعه الأول مع التحكم بالمصدر أقصر من أسبوع أي فريق آخر تقريبا، والمكسب أكبر.

لماذا تُعد عبارة "لسنا على التحكم بالمصدر بعد" إشارة إيجابية؟

لأن المسافة بين وضعك الحالي ووضعك الممكن هي المسافة كاملة، ولا شيء منها يعوقه قرار سابق. الفرق التي لم تبدأ أصلا تملك ثلاث مزايا هادئة:

• لا شيء يحتاج ترحيلا. مؤسستك اليوم هي مصدر الحقيقة. هذه نقطة انطلاق نظيفة لا فوضى.
• لا سياسة تكاليف غارقة. لا أحد مضطر للاعتراف بأن خط التسليم الذي دافع عنه سنة 2023 كان طريقا مسدودا.
• لا عادات تحتاج نسيانا. الفريق يتعلم أسلوب عمل واحدا مرة واحدة، ويمكن أن يكون الأسلوب الحديث مباشرة.

الفرق التي تعاني أسوأ نتائج الإصدار في سيلزفورس نادرا ما تكون فرق الـ change sets. هي الفرق نصف المُرحّلة: مساران للنشر يعملان بالتوازي، وشخص واحد يفهم ملفات الـ YAML، وخطوة مراجعة يلتف حولها الجميع بمجرد أن يتأخر الإصدار.

مِمَّ يتكون ألم الـ change sets فعلا؟

الألم حقيقي، وتسميته بدقة أنفع من أن يُقال لك إنك متأخر. اعتمادا على مراجعة منشورة جيدة لسلوك الـ change sets، هذه هي التكاليف المتكررة:

• الـ change set لا يمكن تعديله بعد الرفع. إذا نسيت مكونا فستنسخه وتعيد بناء الحزمة من جديد.
• المكونات تُختار يدويا، وأداة الاعتماديات تفوتها السلاسل غير المباشرة من المراجع.
• وصلات النشر باتجاه واحد افتراضيا، ومؤسستا إنتاج غير مرتبطتين لا تستطيعان النشر لبعضهما إطلاقا.
• بعض الـ metadata لا تنتقل ببساطة، ومنها قيم قوائم الاختيار القياسية وعناوين البريد على مستوى المؤسسة.
• الـ profiles تكتب فوق نظيرتها في المؤسسة الهدف، فتحذف بصمت صلاحيات لم تكن موجودة في المصدر.
• لا يوجد تراجع بعد النشر، ولا لقطة محفوظة قبله.

لاحظ أن لا شيء من هذا مشكلة مهارات. إنها مشكلة أدوات يمتصها فريقك بساعات عمل إضافية.

ما الذي عليك تعلمه فعليا؟

أقل مما يوحي به النقاش السائد. عادة الرد على جملة "لسنا على Git بعد" بمحاضرة في استراتيجيات الفروع سببت ضررا حقيقيا، لأنها تنقل الخطوة الأولى من النشر بأمان أكبر إلى أن تصير مطورا. وهما مشروعان مختلفان.

فريق الـ change sets يملك بالفعل أهم ما يلزم: معرفة بالمؤسسة، وعادة استخدام بيئات الاختبار، وحس بما يمكن أن ينكسر. ما ينقصه هو سجل لكل تغيير، وطريقة لعكس تغيير واحد، ومراجعة تحدث قبل الإنتاج لا بعد وقوع العطل. وGit يقدم الثلاثة وهو يعمل في الخلفية. أما هل سيفتح مسؤولو النظام عندك نافذة terminal يوما، فهذا اختيار أدوات لا قانون من قوانين المنصة.

كيف تبدأ الأسبوع القادم بدون مهندس DevOps؟

1. خذ لقطة من المؤسسة إلى مستودع. ليس للنشر منه بعد، بل فقط ليُسجَّل وضع اليوم وتظهر تغييرات الغد على هيئة فروق واضحة.
2. اربط بيئات الاختبار الموجودة عندك. احتفظ بالبيئات كما هي. المسار من بيئة المطور إلى UAT إلى الإنتاج لا يحتاج تغييرا في اليوم الأول.
3. انقل نوعا واحدا متكررا من التغييرات. اختر النشر الذي تكرره أكثر من غيره ومرّره وحده عبر المسار الجديد لمدة أسبوعين.
4. شغّل التراجع قبل أن توسّع النطاق. أول مرة يُعكس فيها إصدار في دقيقة بدلا من سهرة كاملة، ينتهي النقاش.
5. أضف المراجعة في النهاية. بمجرد أن تصل التغييرات على هيئة فروق، تكلف عين ثانية دقائق معدودة. إضافة المراجعة قبل ذلك هي بالضبط ما يجعل الفرق تنسحب.

يمكنك فعل ذلك عبر Salesforce DevOps Center أو Gearset أو Copado أو Serpent. قارن بينها بإنصاف على محور واحد أولا: كم من أسلوب العمل يفترض وجود شخص مهنته كتابة ملفات YAML.

ما الذي يمكن تجاهله؟

• نماذج النضج التي تقيسك بشركات لديها فريق منصة من ثمانية أشخاص.
• الجدل حول استراتيجيات الفروع. فرع رئيسي محمي وفروع مزايا قصيرة العمر يكفيانك سنوات.
• كل من يلمّح إلى أن التحكم بالمصدر موقف أخلاقي. إنه وسيلة للتراجع عن الأخطاء، ولم يكن يوما أكثر من ذلك.

Serpent مبني لهذه النقطة بالذات: نشر قائم على التذاكر وGit يعمل تحته، وتراجع بنقرة واحدة، ومراجعة كود بالذكاء الاصطناعي في كل الخطط، وبدون أي خبرة Git مطلوبة من مسؤولي النظام أو الاستشاريين. لا يثبّت شيئا داخل مؤسستك، والإعداد يستغرق أقل من 15 دقيقة، وفريقنا يجري جلسة عملية مع الجميع بدلا من تسليمك دليل استخدام. هناك خطة Essentials مجانية بعدد مستخدمين غير محدود، ويمكنك اختيار مساحة عمل تجريبية جاهزة بالبيانات أثناء التسجيل لو أردت أن ترى قبل أن تربط أي شيء. ابدأ من Serpent.

FAQ

هل فات الأوان على ترك الـ change sets؟

لا. الـ change sets ما زالت مدعومة وما زالت تعمل. الانتقال قرار يخص مخاطر النشر ووقت الفريق، لا موعدا نهائيا فاتك.

هل يجب أن يتعلم مسؤولو النظام عندنا Git؟

ليس مع أدوات تُبقي Git في الخلفية. يكفي أن يفهم مسؤول النظام معنى النسخة ومعنى التراجع. أما أوامر الفروع فاختيارية.

ما أكبر مكسب في الأسبوع الأول؟

التراجع. القدرة على عكس إصدار سيئ بسرعة تغير شعور الفريق تجاه النشر أكثر من أي قدرة أخرى منفردة.

هل يكفي DevOps Center؟

هو تقدم حقيقي عن الـ change sets ومجاني من سيلزفورس، فهو نقطة بداية منصفة. الفرق عادة تتجاوزه حين تحتاج إلى التعبئة أو بوابات الاختبار أو تراجع أكثر ثراء.

هل ننظف المؤسسة أولا قبل أن نبدأ؟

لا. ضع المؤسسة تحت التحكم بالمصدر كما هي. الفوضى المسجلة أسهل بكثير في التحسين من الفوضى غير المسجلة.