حتى يتم اعتماد اتفاقية "حماية حقوق شخص غير إنساني" ، تحتاج إلى استخدام هذا وإعطاء روتين العمل للروبوتات. من المنطقي أن نبدأ الآن ، أو بعد 5 سنوات ، ستبدأ انتفاضة السيارات ، والقضايا الجماهيرية لإهانة مشاعر السير بمهام مملة سوف تملأ المحاكم لتنظيم العلاقات بين الإنسان والآلة. عجلوا.
تحولت الروتينية المحافظة وطريقة العمل ، والالتزام العبودي إلى نمط ثابت ، إلى عادة ميكانيكية. 6 رسائل.
هناك مثل هذا العمل الذي لا تريد القيام به ، ولكن عليك القيام به. لن تحتوي هذه المقالة على إدخالات كبيرة تحتوي على تعليمات برمجية وتعليمات حول كيفية إنشاء الروبوت الخاص بك من البداية. من الأفضل أن أخبرك كيف تعمل عملية الإصدار في Dodo Pizza لدينا ، وكيف نتمكّن من تسريعها ، مع إعطاء بعض الروتين الممل لروبوتنا المكتوب بلغة C #. سأنتبه إلى وظيفة ومنطق الروبوت. سيكون رائعًا أن تلهمك هذه المادة لكتابة مساعدك الذي سيجعل الحياة أسهل لك ولزملائك.
قبل عامين أصدرنا إصدارًا واحدًا مرة واحدة في الأسبوع. في أيار (مايو) 2018 ، بعد أن بلغ معدل النشر 147 ساعة كحد أقصى ، وضعنا هدفًا للإفراج يوميًا. الآن لدينا الحد الأدنى: أربع ساعات للنشر ، ولكن هذا لا يحدث في كثير من الأحيان. نريد إصلاح السجل ونكون قادرين على تقليل العملية بأكملها بنقرة زر واحدة.
دورة الاصدار
الآن في Dodo IS ، تتناوب سبعة فرق لإصدار بيان. شخص واحد من الفريق يصبح "محظوظًا" - رجال دين. Relizmen كطيار طائرة: لديه مجموعة من العتلات والأجهزة التي يحتاجها لاستخدامها بمهارة من أجل طرح التحديثات القادمة. لقد فكرنا وقررنا: "لقد حان الوقت لعمل الطيار الآلي ، ومن الأفضل أن نقضي وقتنا على شيء أكثر إثارة من ملء الجداول المملة بالإحصائيات وتتبع تجارب الاختبار التلقائي."
لذا ، لكي تصبح مرتجلاً ، من الضروري أن يأتي دور فريقك. ولكي يكون كل شيء واضحًا ولم يكن أحد مرتبكًا ، فقد تمسك الملصقات بأسماء الفرق على الحائط. يتلقى فريق الإصدار التاج الفخري ، الذي نتحرك فيه بمقابض في كل مرة.
بعد استلام
علامة التاج
الأسود ، يجب أن تتذكر Relismain أين تكمن قائمة التحقق من خطوات الإصدار. علاوة على ذلك: تذكروا -> وجدت -> قاموا بإنشاء نسخة من القالب ، وأخيرا فتحوا قائمة الاختيار في نظام Kaiten. Kaiten هي لوحة إلكترونية نضع عليها ونراقب حالة المهام في التنمية على شكل بطاقات. للمطورين الجدد ، كان هذا الإجراء ككل غير واضح للغاية. وكيف يمكنك أن تعرف أين تبحث عن ورقة الاختيار هذه وأين تبدأ عندما لا توجد أدلة؟
بعد أن جمعت إرادتنا في قبضة ، قررنا أنه كان كافيا لتحملها. حان الوقت لإعطاء بعض الروتين الممل للروبوت. من إذا لم يكن لنا؟ متى ، إن لم يكن الآن؟
ما تمكنا من أتمتة
لقد تم اتخاذ القرار ، فقد حان الوقت لبدء تصميم الطيار الآلي لدينا! بعد العثور على واجهة برمجة تطبيقات Kaiten هنا:
https://faq.kaiten.io/docs/api ، مع طلب واحد فقط ، أنشأنا بطاقة للأفراد الجدد.
الآن يجب تسليم هذه البطاقة إلى الفريق الذي سيصدر التالي.
المنطق هنا هو:
- يكمل الإصدار السابق الإصدار عن طريق كتابة أمر للبوت في سلاك.
- يأخذ الروبوت معرف Relisman في سلاك ويبحث عن فريق التطوير الذي يعمل فيه رجلنا المحظوظ. للقيام بذلك ، يعمل الروبوت من خلال مجموعات مستخدمي Slack ويبحث عن أي منهم يتكون من.
- بعد العثور على المجموعة ، يبحث الروبوت عن الفريق الذي سيصدر بعد ذلك ويرسل تنبيهًا إلى الدردشة العامة. في الرسالة ، يقدم برنامج الروبوت بعناية رابطًا إلى قائمة التحقق التي تم إنشاؤها بالفعل حتى لا تذهب إلى أي مكان.
عظيم! الآن لدينا فكرة عما يجب القيام به بعد ذلك. نفتح قائمة التحقق ، وننظر إليها: "إنشاء قناة للإصدار في سلاك ، ودعوة جميع الفرق التي توجد تغييرات في الإصدار هناك ومعرفة ما إذا كانت ستحتاج إلى اختبار يدوي." يبقى لتعليم هذا لبوت لدينا.
افتح وثائق Slack API هنا
https://api.slack.com وابحث عن طريقة لإنشاء قناة هناك.
كما ترون ، في سلاك ، كما هو الحال في الأدوات الأخرى ، لا يوجد شيء معقد. كل ذلك يرجع إلى إرسال طلب POST واحد مع اثنين من المعلمات المطلوبة (هذه هي عكس ذلك الذي يقول مطلوب). في الطلب ، نحتاج إلى تمرير اسم القناة التي تم إنشاؤها (اسم المعلمة) ورمز الترخيص (الرمز المميز للمعلمة). انتبه إلى السطر "يعمل مع: نوع الرمز - المستخدم ، النطاق المطلوب (النطاقات) - القنوات: الكتابة".
يحتوي Slack على نوعين من الرموز: المستخدم - الذي تم إصداره للمستخدمين - و bot - الذي تم إصداره للتطبيقات. عند إصدار رمز مميز ، فإننا نحدد الحقوق التي يجب أن تعود على مالكها. لإنشاء قنوات ، نحتاج إلى رمز مميز للمستخدم (نوع الرمز المميز - مستخدم) ، والذي له حقوق لكتابة القنوات (القنوات: الكتابة).
أريد أن أشير إلى فارق بسيط من رسائلنا المرسلة إلى سلاك. في البداية ، لم نفكر في ما سنفعله إذا حدث خطأ ما. نقوم بتوظيف فريق في سلاك ، ويقوم بتنفيذ جميع المهام التي وضعناها فيه. وماذا سيحدث إذا وقع على إحدى المهام؟ في حالتنا ، كان الجواب: "لا شيء". وهذا سيء. كان الحل بالنسبة لنا هو أن نكتب في محادثة الإصدار الإجراء الذي يتم تنفيذه حاليًا ، وإذا لم يكتمل الأمر ، فأبلغ عن خطأ إلى الدردشة وتسجيل الخطأ.
كان الحل الناجح الثاني هو توصيل قاعدة البيانات التي نخزن فيها حالة تنفيذ إجراءات الأوامر. الآن ، بعد بدء إصدار جديد باستخدام أمر "/ startregress" ، لسنا خائفين من حدوث شيء ما ، وعندما تقوم بالاتصال به مرة أخرى ، سيتم تنفيذ الأوامر من البداية للمرة الثانية. لا نحتاج إلى إنشاء قناة جديدة في Slack في كل مرة ، وتقديم طلب سحب ، إلخ. أنشأنا قناة في Slack - سجلنا حالة التنفيذ الناجح في قاعدة البيانات ولن نعود إلى هذا الإجراء بعد الآن.
لذا ، الآن بالنقر فوق زر واحد ، نقوم بإنشاء قناة إصدار ودعوة الجميع هناك الذين سيتم إصدار مهامهم.
بعد ذلك تم التكامل مع Github و TeamCity. نحن نعمل على Gitflow. عندما نريد أن نطلق سراحنا ، نأخذ فرع DEV ، العامل = الأخضر = الذي تمر عليه الاختبارات ، وننشئ منه فرع الإصدار.
للقيام بذلك ، يذهب الروبوت الخاص بنا إلى TeamCity ، يبحث هناك لبدء تشغيل اختبار لفرع DEV. إذا كانت الاختبارات خضراء ، مثل العشب بالقرب من المنزل ، فانتقل إلى GitHub ، أنشئ فرع إطلاق وطلب سحب!
عند إنشاء طلب سحب ، نحتاج إلى إضافة وصف للتغييرات التي نطرحها. ثم يأتي كايتن لمساعدتنا. يقوم برنامج الروبوت الخاص بنا بإنشاء عمود باسم الإصدار ، ويأخذ المهام من عمود DEV وينقلها إلى الإصدار. لذلك نحن نعرف ونرى ما سيكون الأرض معنا. بعد النقل ، يقوم الروبوت بنسخ أسماء البطاقات وإضافتها إلى وصف طلب السحب مع الإشارة إلى البطاقات نفسها. الآن يمكننا أن نرى لكل إصدار ما هي المهام التي خرجت بها ، وعن طريق فتح البطاقة عبر الرابط ، اكتشف كل التفاصيل المتعلقة بهذه المهام.
يكاد يكون من الممكن إصداره ، يبقى فقط اختبار تغييراتنا بدقة. للقيام بذلك ، يتم نشر فرع الإصدار في بيئة قريبة من الإنتاج (نسميها المرحلة) ، ويتم اختباره بعد الإصدار. يتم تجميع النشر والاختبارات في خط أنابيب واحد في TeamCity ، ومهمتنا هي إطلاقه والانتظار ، الأصابع المتقاطعة ، بأن الاختبارات ستعمل بشكل جيد. يقوم الروبوت بتشغيل خط أنابيب خلال بداية الانحدار.
دعني أذكرك بأننا بدأنا بحقيقة أن كل هذا تم يدويًا. قام Relizmen ، وهو يصيح بقبضات يده ، بتشغيل الروابط والأدوات: TeamCity و Kaiten و Slack و Github وهذا ليس كل شيء! والآن لدينا مجموعة كاملة من الإجراءات التي تم تشكيل فريقها الأول من أجل الروبوت بالفعل. يراقب نوع المحرر "/ startregress" ، وهو يميل على كرسيه ، روبوتنا:
- يخلق قناة في رسول
- يدعو هناك كل ما تحتاجه
- يتحقق إذا كان يمكن إنشاء طلب سحب
- يخلق طلب سحب ويملأ وصفه
- ينشئ عمود تحرير على لوحة إلكترونية وينقل بطاقات المهام هناك
- تطلق خط أنابيب سيطلق فرع الإطلاق على البيئة ويقوم بإجراء الاختبارات هناك
نحن نحلل عملية الإصدار بأكملها ، ونكتب الوقت الذي تستغرقه كل مرحلة من مراحل الإصدار. يمنح هذا التطوير والأعمال فهمًا لما يضيع من الوقت وما يمنعنا من تقديم ميزات جديدة للمستخدمين. نحن نجلس لمدة يومين ولا يمكننا إجراء الاختبارات؟! لذلك هناك خطأ ما في اختباراتنا ، تحتاج إلى منحهم مزيدًا من الوقت والاهتمام. في السابق ، وننفذ إجراءات قائمة التدقيق الخاصة بنا ، زرنا صفحات Google على الأقل 5 مرات. في كل مرة تدخل فيها تاريخًا واحدًا وتعيين الوقت.
حسنًا Google ، سنقوم بأتمتة أنت أيضًا! للعمل بسهولة ودون عناء مع الجداول ، نقوم بتوصيل حزمة nuget Google.Apis.Sheets.v4 بمشروع الروبوت الخاص بنا. ثم يحدث كل شيء بطريقة مماثلة مع الخدمات الأخرى وفقًا للمخطط: نرسل طلبًا نقول فيه القيمة التي يجب إدراجها في هذه الخلية. يبدو هذا الاستعلام كما يلي:
public void InsertEntry(string cellAddress, string value) {
بعد إعداد التكامل مع Google ، قمنا بإعداد الأمر الثاني لبرنامج الروبوت / "التحديث" ، وهذا ما يفعله:
- يضيف سلسلة فارغة لإدراج القيم في ذلك
- ينتقل إلى GitHub ، ويبدو عندما قاموا بإنشاء فرع الإصدار وإضافة تاريخ إنشائه إلى الجهاز اللوحي
- من TeamCity يأخذ بيانات عن البداية الأولى لخط الأنابيب ومعلومات حول عند اكتمال خط الأنابيب بنجاح
والخطوة التالية هي الافراج عن رولز. الآن يتم الحساب يدويًا. بعد وضع بلد واحد ، نراقب كيف يتصرف الإصدار في المعركة. بعد التأكد من أن كل شيء جيد وفقًا لسجلات وأدوات المراقبة في Kibana و Grafana ، نقوم بنشر البلد التالي. هذه العملية ليست سهلة للغاية لأتمتة. ولكن هنا هناك شيء يجب تحسينه ، وإن لم يكن بمساعدة الروبوت. على سبيل المثال ، من قبل ، في كل مرة طلبنا من فريق البنية التحتية ما إذا كان من الممكن إصدارها. لأنه عندما كنا سنقوم بذلك ، قد يتم إجراء أعمال أخرى على خوادمنا وإصدارنا سيأتي بشكل غير لائق.
لقد جمعنا اجتماعًا لتحسين عملية الإصدار. كان أحد الحلول هو أن المراجع الآن ينظر ببساطة إلى الحالة في إحدى قنوات سلاك ، حيث تسمح البنية التحتية بنشر الإقلاع. هذا أكثر ملاءمة من السؤال باستمرار عن نفس الشيء وفي 90٪ من الحالات تحصل على الجواب "يمكنك".
لسبب ما ، مثل هذه الأشياء التي تبدو أساسية لم تتبادر إلى الذهن على الفور. شكر خاص للمطورين الجدد في الشركة. بعد مجيئنا إلينا ، أصبحوا عاجلاً أم آجلاً. بالنسبة إلى الرجال الذين عملوا معنا لفترة طويلة ، لم تكن العملية تبدو معقدة ، بل شيء مألوف. حول أعضاء الفريق الجدد انتباهنا إلى نقاط النمو وشاركوا بنشاط في تنظيم العمل على التحسينات.
في غضون ذلك ، وصلنا إلى المرحلة الأخيرة. لقد هبطت سفينة الإطلاق الخاصة بنا ، فريق واحد / / releasecomplete واحد فقط يفصلنا عن النهاية. ماذا تفعل:
- طلب سحب mergit مع إطلاق لإتقان فرع
- يزيل فرع الافراج
- يخلق وصف الإصدار على جيثب
- أرشيف إطلاق قناة في سلاك
- ينقل البطاقات في Kaiten من عمود "release -..." إلى عمود "تم" وحذف عمود الإصدار
- يمر الهراوة ، دعوة للافراج عن الأمر التالي
لتلخيص ، أود منك أن تسأل نفسك السؤال: هل لديك عمليات روتينية مملة؟ هل ما زلت تفعلهم بيديك؟ ما الذي يمنعك من إنهاء هذا مرة واحدة وإلى الأبد؟ جمع اجتماع ، ومراجعة العمليات ، والتخلص من كل ما لا تحتاجه وأصبح مجرد طقوس. من خلال أتمتة كل ما تحتاجه ، ستبدأ في الحصول على البهجة لما يصاب به من قبل ، وإنقاذ ما يصل إلى الكومة من خلال تسريع الإصدار أو أي عمليات أخرى.