لقد أحدث نهج DevOps في هندسة البرمجيات تغييرًا جذريًا في سرعة الإصدار عن طريق توحيد التطوير والعمليات التشغيلية. ومن المرجح للغاية أن تعمل مبادئ DevOps في الوقت الحاضر على توجيه عمليات فريق التطوير لديك من خلال توفير إطار عمل لتطبيق الإدماج والنشر بشكل متواصل. عندما تُطوِّر البرامج باستخدام نهج DevOps، فأنت تتبع دورة حياة تتمثل مراحلها في التطوير، والاختبار، والموافقة، والإنتاج (DTAP). وقد حققت المؤسسات التي تحتوي على فرق تطوير كبيرة، ولا سيما الفرق المتفرقة، تحسينات ملحوظة في عمليات دورة حياة تطوير البرامج (SDLC) لديها باستخدام نهج DevOps. ولهذا السبب يبدو أمرًا منطقيًا تمامًا أن يُطبَّق نهج DevOps ذاته على تطوير روبوتات التشغيل الآلي للعمليات الروبوتية (RPA) على مستوى المؤسسة.
توفر معظم حلول RPA في الوقت الحاضر إمكانات تتيح لك الانتقال بالروبوتات من إحدى مراحل دورة حياة التطوير إلى المرحلة التالية. هل يعني ذلك أنها تدعم نهج DevOps لإدارة دورة حياة الروبوتات (BLM)؟ الإجابة هي لا. إن الفكرة القائلة بأن مجرد نقل الروبوتات خلال دورة حياة DevOps يمثل BLM ما هي إلا إحدى الأساطير. ولكن شأنها شأن كل الأساطير، قد تبدو منطقية إذا لم تخضع للفحص شديد الدقة.
DevOps وBLM ليسا شيئًا واحدًا
تحدث كل مرحلة من دورة حياة DevOps في بيئة منفصلة. فأنت تُجري التطوير في بيئة ما، وتُجري الاختبار في بيئة أخرى. وتعد مرحلة الإنتاج منفصلة أيضًا. وبهذا، لإدارة دورة حياة أحد الروبوتات، يجب أن تكون قادرًا على توفير بيئات منفصلة للروبوتات وفقًا لمرحلة دورة الحياة المتواجدة بها. كما يتعين أن تكون قادرًا أيضًا على نقل حِزَم الروبوتات بأكملها بين المراحل.
لنقل أنك أنشأت الروبوت A، ومن أجل تشغيله بكفاءة، يعتمد الروبوت A على عمليات منفصلة وهي A.1 وA.2 وA.3. تتعين إدارة الروبوت وبرامجه التابعة ونقلها خلال دورة حياة الروبوت كحزمة واحدة. ربما تقول إن هذا أمر بديهي. ولكن معظم حلول RPA لا تفعل ذلك بسهولة —فما تفعله فقط هو استيراد وتصدير الروبوت بين البيئات التي توفرها. وتدير أنت ملحقات الروبوت بصورة منفصلة. ربما تقول "حقًا؟ تبدو هذه مهمة مضجرة". هذا صحيح. وهي بالفعل مهمة مضجرة كما سيخبرك أي مدير لبرنامج RPA.
نهج DevOps في بيئة تطوير أحد الروبوتات
دون وضع إطار عمل حقيقي لميزة BLM، يتعين عليك إنشاء بيئات التطوير والاختبار لديك وإدارتها. وسيتعين عليك أيضًا إدارة الملحقات وتطويرها بصورة منفصلة. وقد ينجح هذا بصورة جيدة إذا كنت تريد إثبات مفهوم RPA، ولكن لا يمكنك تطبيقه على نطاق واسع. فكلما زاد عدد الروبوتات التي تحتاج إلى إدارتها باستخدام عمليات منفصلة، استغرق الأمر وقتًا أطول للانتقال بالروبوتات إلى مرحلة الإنتاج. وعلاوة على ذلك، في حالة فشل التعامل مع الملحقات، فقد تواجه المزيد من الأخطاء التي قد تؤخر الإدماج والنشر المتواصلين.
قد يمثل الامتثال مشكلة أيضًا. فبالنسبة للروبوتات التي تؤثر في عمليات ذات متطلبات للامتثال، مثل العمليات المالية التي يغطيها قانون ساربينز أوكسلي (SOX)، يجبرك عدم وجود إطار عمل حقيقي لميزة BLM على تطوير وإدارة قيودك الخاصة على الروبوتات.
توسيع النطاق باستخدام BLM
إن إطار عمل BLM الذي يتضمنه Automation Anywhere Enterprise يقوم بأكثر من مجرد استيراد الروبوتات وتصديرها–فهو يندمج بسهولة في سير عمل DevOps. وهو يتميز بدعم مدمج لبيئات التطوير والاختبار والموافقة والإنتاج المنفصلة، بما في ذلك ميزات التحكم الكامل في الإصدار والتراجع.
وتعد ميزة التحكم في الوصول على أساس الدور (RBAC) شديد الدقة أمرًا ضروريًا آخر لكل مؤسسة لدعم أمان منصة RPA للمؤسسات. مع التحكم الدقيق في الوصول على أساس الدور، تنتقل الروبوتات بسلاسة بين مراحل دورة حياة DevOps. ولكن ماذا عن الملحقات؟ تنتقل الملحقات جنبًا إلى جنب مع الروبوتات. وهذا لأن منصة Automation Anywhere Enterprise تدير حزمة الروبوت بالكامل باعتبارها جزءًا من دورة حياة الروبوت. ويتيح لك هذا التحكم في الإصدارات والأدوار وحِزَم الروبوتات تطوير المزيد من الروبوتات بصورة أسرع حتى في حالة وجود متطلبات صارمة للامتثال. وهذا يسمح لك بتوسيع نطاق RPA بسرعة خلال المؤسسة وتجربة الحصول على عائدات أعلى على الاستثمار بصورة أسرع—وهي إحدى سمات استراتيجية RPA من فئة المؤسسات الموضوعة بعناية.
يمكنك طلب عرض توضيحي لمنصة Automation Anywhere Enterprise اليوم للحصول على تجربة مباشرة لإدارة دورة حياة الروبوت.