لماذا يحتاج كل أثر إلى اسم ورقم

فريقك يبني كودًا كل يوم. بحلول يوم الجمعة، لديك سبعة أرتيفاكتات مختلفة في مستودعك. لا أحد يتذكر أي منها تم اختباره، وأيها يحتوي على الإصلاح العاجل، وأيها يجب أن يذهب إلى الإنتاج. يسأل أحدهم: "أي بناء ننشر؟" ويكون الجواب هز كتف.

هذه هي اللحظة التي تدرك فيها أن الأرتيفاكتات بدون تسمية واضحة ليست أرتيفاكتات على الإطلاق. إنها مجرد ملفات. بدون نظام تسمية وترقيم مناسب، ينتج خط أنابيبك ضوضاء بدلاً من اليقين.

مشكلة الأرتيفاكتات غير المسماة

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

المشكلة الأساسية بسيطة: إذا لم تستطع تحديد الأرتيفاكت بشكل فريد، فلن تستطيع نشره بشكل موثوق. وإذا لم تستطع النشر بشكل موثوق، فلن تستطيع الإصدار بثقة.

ما الذي يجعل الأرتيفاكت قابلاً للتحديد

كل أرتيفاكت يحتاج إلى شيئين: اسم ورقم. الاسم يخبرك ما هو الأرتيفاكت. الرقم يخبرك أي إصدار من هذا الشيء هو. معًا، يشكلان معرفًا فريدًا يمكن لكل فرد في الفريق الرجوع إليه دون غموض.

الاسم عادةً ما يكون اسم التطبيق أو المكون. الرقم هو الإصدار. عندما تجمعهما، تحصل على شيء مثل payment-service-2.1.3. هذه السلسلة تشير إلى أرتيفاكت واحد بالضبط. ليس الذي من الأسبوع الماضي. ليس الذي له اسم مشابه. فقط ذلك الأرتيفاكت.

الإصدارات ليست للعرض فقط

الإصدارات هي النظام الذي يعطي معنى للجزء الرقمي من معرف الأرتيفاكت الخاص بك. إنه ليس مجرد عداد يتزايد. نظام إصدارات جيد يخبرك بشيء عن الأرتيفاكت نفسه. إنه ينقل طبيعة التغيير، ومستوى المخاطرة، والعلاقة بالإصدارات السابقة.

النظام الأكثر استخدامًا هو الإصدارات الدلالية. يستخدم ثلاثة أرقام مفصولة بنقاط: MAJOR.MINOR.PATCH. كل رقم له معنى محدد.

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

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

الثبات يبدأ من الإصدارات

رقم الإصدار ليس مجرد تسمية. إنه عقد. بمجرد بناء الأرتيفاكت ووسمه بإصدار، يجب ألا يتغير هذا الإصدار أبدًا. إذا أعدت بناء نفس الكود، يجب أن تحصل على نفس الأرتيفاكت. إذا تغير شيء، يجب أن يتغير الإصدار.

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

الإصدارات والإصدار شيئان مختلفان

الخطأ الشائع هو معاملة الإصدارات والإصدار كمفهوم واحد. ليسوا كذلك. الإصدارات تتعلق بتسمية الأرتيفاكت. الإصدار يتعلق بقرار جعل هذا الأرتيفاكت متاحًا للمستخدمين.

يمكنك بناء الإصدار 2.2.0-beta ونشره إلى بيئة التدريج للاختبار. هذا الإصدار موجود كأرتيفاكت، لكنه ليس إصدارًا. بعد الاختبار، قد تقرر ترقيته إلى 2.2.0 وإصداره إلى الإنتاج. أو قد تجد مشكلات وتبني 2.2.1 بدلاً من ذلك.

هذا الفصل يمنحك المرونة. يمكنك بناء وإصدار الأرتيفاكتات بشكل متكرر، ولكن الإصدار فقط عندما تكون واثقًا. رقم الإصدار يتتبع هوية الأرتيفاكت. قرار الإصدار يتتبع جاهزيته.

الآثار العملية لخط الأنابيب الخاص بك

بمجرد أن يكون لديك نظام تسمية وإصدارات واضح، تصبح عدة أمور أسهل.

التتبع يصبح تلقائيًا. عندما يتم الإبلاغ عن خطأ في الإنتاج، تنظر إلى الإصدار الذي يعمل في تلك البيئة. تتحقق من التغييرات التي دخلت في ذلك الإصدار. تقارنه بالإصدار المستقر السابق. كل هذا ممكن لأن كل أرتيفاكت له معرف فريد يرتبط بالكود المصدري وعملية البناء.

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

التواصل يصبح أوضح. بدلاً من قول "انشر أحدث بناء"، تقول "انشر payment-service 2.1.3 إلى الإنتاج". الجميع يعرف بالضبط ما يعنيه ذلك. مسؤول قاعدة البيانات يعرف أي ترحيل قاعدة بيانات يتوقع. فريق ضمان الجودة يعرف أي اختبارات تم تشغيلها. فريق العمليات يعرف ما يجب مراقبته.

قائمة مراجعة بسيطة لتسمية الأرتيفاكتات

إذا كنت تقوم بإعداد تسمية الأرتيفاكتات لأول مرة، إليك قائمة مراجعة قصيرة للبدء:

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

الخلاصة

تسمية الأرتيفاكتات وإصداراتها ليست تمرينًا بيروقراطيًا. إنها أساس النشر الموثوق. بدونها، ينتج خط الأنابيب الخاص بك عدم يقين. معها، كل أرتيفاكت له هوية واضحة، كل نشر له هدف واضح، وكل استرجاع له وجهة واضحة. سمِّ أرتيفاكتاتك. رقمها بشكل ثابت. اجعلها ثابتة. عندها يمكنك النشر بثقة.