التنمية المستندة إلى Trunk مقابل Git Flow

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

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

كيف غيرت أنظمة التحكم في الإصدارات العالم

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

يكلف الكثير من الوقت ومساحة القرص الصلب والمال.

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

دعونا نلقي نظرة عليهم:

نلاحظ أنه مع نضوج أنظمة التحكم في الإصدارات ، هناك ميل لزيادة القدرة على العمل في المشاريع بالتوازي.

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

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

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

أساليب التنمية

في الوقت الحاضر ، أكثر أنظمة التحكم في الإصدارات شيوعًا هو Git ، حيث بلغت حصة السوق حوالي 70 بالمائة في عام 2016.

انتشر Git مع ظهور نظام Linux والمشهد مفتوح المصدر بشكل عام. كان GitHub حاليًا أكثر التخزين عبر الإنترنت شيوعًا للمشاريع العامة ، وكان أيضًا مساهمًا كبيرًا في انتشاره. نحن مدينون بإدخال طلبات السحب سهلة الإدارة إلى Git.

ببساطة ، طلبات السحب هي طلبات تم إنشاؤها بواسطة مطور برامج لدمج التغييرات التي تم إنشاؤها مع المشروع الرئيسي. يتضمن عملية مراجعة تلك التغييرات. يمكن للمراجعين إدخال تعليقات على كل جزء يعتقدون أنه يمكن تحسينه ، أو يرون أنه غير ضروري.

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

Git مجرد أداة. يمكنك استخدامه بعدة طرق مختلفة. حاليًا ، أكثر أنماط التطوير شيوعًا التي يمكنك مواجهتها هما Git flow و trunk-based development. في كثير من الأحيان ، يكون الناس على دراية بأحد هذه الأساليب وقد يتجاهلون الآخر.

دعنا نلقي نظرة فاحصة على كلاهما ونتعلم كيف ومتى يجب علينا استخدامهما.

تدفق بوابة

في نموذج تطوير تدفق Git ، لديك فرع تطوير رئيسي واحد مع وصول صارم إليه. غالبًا ما يطلق عليه الفرع develop .

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

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

أدناه ، يمكنك رؤية مخطط تدفق Git ، الذي يصور سير عمل عام:

تتمثل إحدى مزايا Git flow في التحكم الصارم. يمكن للمطورين المعتمدين فقط الموافقة على التغييرات بعد النظر إليها عن كثب. يضمن جودة الكود ويساعد على التخلص من الأخطاء في وقت مبكر.

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

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

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

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

إيجابيات وسلبيات Git Flow

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

متى يعمل Git Flow بشكل أفضل؟

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

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

  

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

متى يمكن أن يسبب Git Flow مشاكل؟

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

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

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

سير عمل التطوير المستند إلى جذع

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

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

دعنا نلقي نظرة على سير عمل التطوير المستند إلى صندوق الأمتعة.

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

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

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

إيجابيات وسلبيات التنمية القائمة على Trunk

دعنا نلقي نظرة فاحصة على كلا جانبي التكلفة — أفضل وأسوأ السيناريوهات.

متى يعمل التطوير المستند إلى Trunk بشكل أفضل؟

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

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

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

متى يمكن أن تسبب التنمية المبنية على الجذع مشاكل؟

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

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

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

إستخدم الأداة المناسبة للعمل المناسب

كما قلت من قبل ، Git هي مجرد أداة. مثل أي أداة أخرى ، يجب استخدامها بشكل مناسب.

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

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

ومع ذلك ، إذا كنت تعمل مع مبرمجين مبتدئين أو أشخاص لا تثق بهم تمامًا ، فإن Git flow هو بديل أفضل بكثير.

مجهزة بهذه المعرفة ، آمل أن تكون قادرًا على اختيار سير العمل الذي يتناسب تمامًا مع مشروعك.