الدليل: إدارة إصدار البرامج للفرق الصغيرة

إضفاء الطابع الرسمي على عملية إدارة الإصدار (إذا كان هناك أي)

في بعض تكوينات الفريق ، لا سيما تلك الموجودة في الشركات الناشئة ، لا توجد DevOps ولا مهندسو بنية تحتية لتقديم الدعم عند إصدار إصدار جديد من المنتج.

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

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

أدخل قائمة التحقق من إصدار البرنامج

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

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

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

الخطوات المقترحة لاستخدامها كأساس

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

1. إنشاء فرع التحرير

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

من الناحية المثالية ، يجب أن يكون لديك ثلاثة فروع على الأقل:

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

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

لإنشاء فرع إصدار جديد ، من فرع التطوير في محطة git الطرفية ، اكتب:

$ git checkout -b release/xyz

من الملائم استخدام اصطلاح تسمية ، مثل الذي تم تحديده أعلاه ، مع استبدال xyz برقم إصدار main.minor.patch وفقًا لاحتياجاتك (إنها سياسة يجب أن تحددها داخل فريقك وتلتزم بها).

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

2. نتوء الإصدار

ستكون الخطوة التالية هي رفع (تعديل أو زيادة) رقم الإصدار في فرع الإصدار .

يجب عليك فتح AndroidManifest.xml / package.json / pom.xml / أو أينما تم تخزين إصدار التطبيق في مشروعك (YMMV) ، قم بتحديث رقم الإصدار ، ثم قم بتنفيذ التغييرات على فرع الإصدار الحالي.

من المهم تحديث رقم الإصدار لسببين.

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

أخيرًا ، يوصى بدفع فرع الإصدار إلى الأصل ، بحيث يكون متاحًا للمطورين الآخرين:

$ git push -u origin release/xyz

3 أ. دمج فرع التحرير لإتقانه ووضع علامة عليه

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

 $ git checkout master $ git merge --no-ff release/xyz $ git push

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

بعد ذلك ، حان الوقت لوضع علامة على الإصدار في الفرع الرئيسي :

$ git tag -a xyz -m 'description of new version, features or fixes included'

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

3 ب. استخدم طلب سحب لدمج فرع التحرير

هناك بديل آخر يستخدم كثيرًا ، وهو استخدام طلب سحب لدمج فرع التحرير في فرع رئيسي .

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

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

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

4. نشر Master إلى بيئة الإنتاج

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

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

بعد تحميل التطبيق ، تأكد من نشره بنجاح وأنه يعمل كما هو متوقع.

5. دمج مرة أخرى في تطوير وحذف فرع التحرير

الآن اكتمل الإصدار تقريبًا ، سترغب في دمج فرع الإصدار في التطوير ، لتحديث رقم الإصدار في الأخير ونقل جميع إصلاحات الأخطاء التي تم إجراؤها إلى فرع التطوير الرئيسي:

 $ git checkout develop $ git merge release/xyz

حان الوقت الآن لإزالة فرع التحرير:

$ git branch -d release/xyz

6. جيل التغيير

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

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

 <app's name or component released> <version xyz> | <date> <developer's name in charge of release> | <developer's email> Features: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Bugs fixed: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Enhancements: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Optional: known issues plus other release notes.

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

• Github Changelog Generator ، بواسطة skywinder ،
• ReadmeGen التي كتبها fojuth
• تغييرات جيثب ، بواسطة lalitkapoor

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

7. التواصل مع أصحاب المصلحة

هذا هو المكان الذي تقوم فيه عادة ببعض الأمور التالية:

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

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

8. الاستمالة تعقب المشكلة

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

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

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

حول أتمتة عملية الإصدار

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

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

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

تبني أفضل الممارسات

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

ابحث عن أنسب يوم لتنفيذ التحرير

عادةً ما أقوم بإصدار تطبيقات أعمل عليها أيام الخميس ، بين الظهر ونهاية العمل.

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

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

النسخ الاحتياطي لقاعدة البيانات الخاصة بك قبل إصدار جديد

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

الطرح على مراحل

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

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

هناك أداة رائعة على وحدة تحكم مطوّري البرامج في Android تنفذ عمليات طرح مرحلية لتطبيقات Android.

التكامل المستمر

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

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

إن نقطة البداية لتطبيق CI هي إعداد "خادم تكامل مستمر ؛" بعض الأدوات الرائعة التي يمكنك تجربتها هي: CruiseControl و Bamboo و Jenkins و Travis.

استثناء: سوف ينجح كل شيء

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

استثناء القتلة

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

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

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

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