صورة:
أهلاً بكم! نحن مهندسو التشغيل الآلي من الشركة ونحن ندعم تطوير منتجات الشركة: نحن ندعم خط أنابيب التجميع بالكامل من الالتزام بسطر من التعليمات البرمجية من قبل المطورين إلى نشر المنتجات النهائية والتراخيص على خوادم التحديث. بشكل غير رسمي ، يُطلق علينا اسم مهندسو DevOps. في هذا المقال نريد أن نتحدث عن المراحل التكنولوجية لعملية إنتاج البرمجيات وكيف نراها وكيف نصنفها.
ستتعرف من المادة على مدى تعقيد تنسيق تطوير المنتجات المتعددة ، وحول ماهية الخريطة التكنولوجية وكيف تساعد في تبسيط الحلول وتكرارها ، وما هي المراحل والخطوات الرئيسية لعملية التطوير ، وكيف هي مجالات المسؤولية بين DevOps والفرق في شركتنا.
حول الفوضى و DevOps
باختصار ، يتضمن مفهوم DevOps أدوات وخدمات التطوير ، بالإضافة إلى المنهجيات وأفضل الممارسات لاستخدامها. دعونا نفرد ما هو عالمي هدف من تنفيذ أفكار DevOps في شركتنا: هذا هو التخفيض المستمر في تكلفة إنتاج وصيانة المنتجات من الناحية الكمية (ساعات العمل أو ساعات الماكينة ، وحدة المعالجة المركزية ، ذاكرة الوصول العشوائي ، القرص ، إلخ). الطريقة الأسهل والأكثر وضوحًا لتقليل التكلفة الإجمالية للتطوير على مستوى الشركة بأكملها هي تقليل تكلفة أداء المهام التسلسلية النموذجية في جميع مراحل الإنتاج. لكن ما هي هذه المراحل ، كيف تفصلها عن العملية العامة ، ما هي الخطوات التي تتكون منها؟
عندما تقوم شركة ما بتطوير منتج واحد ، يكون كل شيء أكثر أو أقل وضوحًا: عادة ما تكون هناك خارطة طريق مشتركة ومخطط تطوير. ولكن ماذا تفعل عندما يتوسع خط الإنتاج ويوجد المزيد من المنتجات؟ للوهلة الأولى ، لديهم عمليات وخطوط تجميع متشابهة ، وتبدأ لعبة "العثور على الاختلافات X" في السجلات والنصوص. ولكن ماذا لو كان هناك بالفعل أكثر من 5 مشاريع قيد التطوير النشط والدعم المطلوب للعديد من الإصدارات التي تم تطويرها على مدار عدة سنوات؟ هل نريد إعادة استخدام أكبر عدد ممكن من الحلول في خطوط أنابيب المنتج أم أننا مستعدون لإنفاق الأموال على تطوير فريد لكل منها؟
كيف تجد التوازن بين الحلول الفريدة والمتسلسلة؟
بدأت هذه الأسئلة تثار أمامنا أكثر فأكثر منذ عام 2015. زاد عدد المنتجات ، وحاولنا توسيع قسم الأتمتة (DevOps) ، الذي دعم خطوط تجميع هذه المنتجات إلى الحد الأدنى. في الوقت نفسه ، أردنا تكرار أكبر عدد ممكن من الحلول بين المنتجات. بعد كل شيء ، لماذا تفعل الشيء نفسه في عشرة منتجات بطرق مختلفة؟
مدير التطوير: "أيها الرجال ، هل يمكننا بطريقة ما تقييم ما تفعله DevOps للمنتجات؟"
نحن: "لا نعرف ، لم نطرح مثل هذا السؤال ، ولكن ما هي المؤشرات التي يجب أخذها في الاعتبار؟"
مدير التطوير: "من تعرف! يفكر…"
كما في ذلك الفيلم الشهير: "أنا في فندق! .." - "أه .. هل تدلني على الطريق؟" عند التفكير ، توصلنا إلى استنتاج مفاده أننا نحتاج أولاً إلى اتخاذ قرار بشأن الحالات النهائية للمنتجات ؛ أصبح هذا هدفنا الأول.
لذا ، كيف يمكنك تحليل عشرات المنتجات مع فرق كبيرة إلى حد ما من 10 إلى 200 شخص وتحديد مقاييس قابلة للقياس عند تكرار الحلول؟
1: 0 لصالح Chaos أو DevOps على شفرات الكتف
بدأنا بمحاولة تطبيق مخططات IDEF0 ومخططات عمليات الأعمال المختلفة من سلسلة BPwin. بدأ الالتباس بعد المربع الخامس للمرحلة التالية من المشروع التالي ، ويمكن رسم هذه المربعات لكل مشروع في ذيل ثعبان طويل تحت 50+ خطوة. شعرت بالحزن وأردت العواء على القمر - لم يكن ذلك مناسبًا بشكل عام.
مهام الإنتاج النموذجية
تعد عمليات الإنتاج النمذجة مهمة معقدة للغاية ومضنية: تحتاج إلى جمع ومعالجة وتحليل الكثير من البيانات من مختلف الإدارات وسلاسل الإنتاج. يمكنك قراءة المزيد عن هذا في المقالة "".
عندما بدأنا نمذجة عملية الإنتاج لدينا ، كان لدينا هدف محدد - لنقل إلى كل موظف مشارك في تطوير منتجات شركتنا ، وإلى مديري المشاريع:
- كيف تصل المنتجات ومكوناتها ، بدءًا من الالتزام بسطر من التعليمات البرمجية ، إلى العميل في شكل أدوات تثبيت وتحديث ،
- ما هي الموارد التي يتم توفيرها لكل مرحلة من مراحل إنتاج المنتجات ،
- ما هي الخدمات المشاركة في كل مرحلة ،
- كيف يتم تحديد مجالات المسؤولية لكل مرحلة ،
- ما هي العقود الموجودة عند مدخل وخروج كل مرحلة.
سيؤدي النقر فوق الصورة إلى فتحها بالحجم الكامل
ينقسم عملنا في الشركة إلى عدة مجالات وظيفية. يتمثل اتجاه البنية التحتية في تحسين تشغيل جميع موارد القسم "الحديدية" ، فضلاً عن أتمتة نشر الأجهزة الافتراضية والبيئة عليها. يوفر اتجاه المراقبة تحكمًا في أداء الخدمة على مدار الساعة طوال أيام الأسبوع ؛ كما نقدم المراقبة كخدمة للمطورين. يوفر اتجاه سير العمل للفرق أدوات لإدارة عمليات التطوير والاختبار ، وتحليل حالة الكود ، والحصول على تحليلات للمشاريع. وأخيرًا ، يوفر اتجاه webdev نشر الإصدارات على خوادم تحديث GUS و FLUS ، بالإضافة إلى ترخيص المنتجات باستخدام خدمة LicenseLab. لدعم خط أنابيب الإنتاج ، قمنا بإعداد وصيانة العديد من خدمات الدعم المختلفة للمطورين (يمكنك الاستماع إلى قصص حول بعضها في اللقاءات القديمة: и). نقوم أيضًا بتطوير أدوات الأتمتة الداخلية ، بما في ذلك .
على مدى السنوات الخمس الماضية ، تراكمت أعمالنا كثيرًا من نفس النوع والعمليات الروتينية ، ويأتي مطورونا من الأقسام الأخرى أساسًا مما يسمى مهام نموذجيةلا يتسبب حلها آليًا كليًا أو جزئيًا في صعوبات لفناني الأداء ولا يتطلب قدرًا كبيرًا من العمل. جنبا إلى جنب مع المجالات الرائدة ، قمنا بتحليل مثل هذه المهام وتمكنا من تحديد فئات العمل الفردية ، أو مراحل الإنتاج، وقسمت المراحل إلى خطوات غير قابلة للتجزئة ، وتجمع عدة مراحل سلسلة عملية الإنتاج.
أبسط مثال على سلسلة تكنولوجية هو مراحل تجميع ونشر واختبار كل منتج من منتجاتنا داخل الشركة. في المقابل ، على سبيل المثال ، تتكون مرحلة الإنشاء من العديد من الخطوات النموذجية المنفصلة: تنزيل المصادر من GitLab ، وإعداد التبعيات ومكتبات الجهات الخارجية ، واختبار الوحدة وتحليل الكود الثابت ، وتنفيذ نص برمجي على GitLab CI ، ونشر العناصر الأثرية في المستودع على المصنع وتوليد ملاحظات الإصدار من خلال أداة ChangelogBuilder الداخلية الخاصة بنا.
يمكنك أن تقرأ عن مهام DevOps النموذجية في مقالاتنا الأخرى على Habré: ""و"".
تتشكل العديد من سلاسل الإنتاج النموذجية عملية التصنيع. النهج القياسي لوصف العمليات هو استخدام نماذج IDEF0 وظيفية.
مثال على نمذجة عملية التصنيع CI
لقد أولينا اهتمامًا خاصًا لتطوير المشاريع القياسية لنظام تكامل مستمر. هذا جعل من الممكن تحقيق توحيد المشاريع ، وتسليط الضوء على ما يسمى ب الافراج عن مخطط البناء مع الترقيات.
وإليك كيف يعمل. تبدو جميع المشاريع نموذجية: فهي تتضمن تكوين التجميعات التي تقع في مستودع اللقطات في Artifactory ، وبعد ذلك يتم نشرها واختبارها على مقاعد الاختبار ، ثم ترقيتها إلى مستودع الإصدار. خدمة Artifactory هي نقطة توزيع واحدة لجميع القطع الأثرية للبناء بين الفرق والخدمات الأخرى.
إذا قمنا بتبسيط وتعميم مخطط الإصدار الخاص بنا إلى حد كبير ، فإنه يتضمن الخطوات التالية:
- تجميع المنتج عبر منصة،
- النشر لاختبار المقاعد ،
- إجراء الاختبارات الوظيفية وغيرها ،
- الترويج للبنى المختبرة لتحرير المستودعات في Artifactory ،
- نشر إصدار يبني على خوادم التحديث ،
- تسليم التجميعات والتحديثات للإنتاج ،
- بدء التثبيت والتحديث للمنتج.
على سبيل المثال ، ضع في اعتبارك النموذج التكنولوجي لمخطط الإصدار النموذجي هذا (المشار إليه فيما يلي ببساطة النموذج) في شكل نموذج IDEF0 وظيفي. إنه يعكس المراحل الرئيسية لعملية CI الخاصة بنا. تستخدم نماذج IDEF0 ما يسمى ب تدوين ICOM (آلية التحكم في المدخلات والمخرجات) لوصف الموارد المستخدمة في كل مرحلة ، بناءً على القواعد والمتطلبات التي يتم تنفيذها ، وما هو الناتج ، وما هي الآليات أو الخدمات أو الأشخاص الذين ينفذون مرحلة معينة.
سيؤدي النقر فوق الصورة إلى فتحها بالحجم الكامل
كقاعدة عامة ، من الأسهل تحليل وتفصيل وصف العمليات في النماذج الوظيفية. ولكن مع نمو عدد العناصر ، يصبح من الصعب أكثر فأكثر فهم شيء ما فيها. ولكن في التطوير الحقيقي ، هناك أيضًا مراحل مساعدة: المراقبة ، وإصدار الشهادات للمنتج ، وأتمتة سير العمل ، وغيرها. وبسبب مشكلة القياس ، تخلينا عن هذا الوصف.
ولادة الأمل
في أحد الكتب ، صادفنا خرائط سوفيتية قديمة تصف العمليات التكنولوجية (والتي ، بالمناسبة ، لا تزال مستخدمة اليوم في العديد من المؤسسات والجامعات المملوكة للدولة). انتظر ، انتظر ، لأن لدينا أيضًا سير عمل! .. هناك مراحل ونتائج ومقاييس ومتطلبات ومؤشرات وما إلى ذلك ... لماذا لا نحاول تطبيق جداول التدفق على خطوط أنابيب منتجاتنا أيضًا؟ كان هناك شعور: "هذا هو! لقد وجدنا الخيط الصحيح ، حان الوقت لسحبه جيدًا!
في جدول بسيط ، قررنا تسجيل المنتجات حسب الأعمدة والمراحل التكنولوجية وخطوات خط أنابيب المنتج بالصفوف. المعالم هي شيء كبير ، مثل خطوة بناء المنتج. والخطوات هي شيء أصغر وأكثر تفصيلاً ، مثل خطوة تنزيل الكود المصدري إلى خادم الإنشاء أو خطوة تجميع الكود.
عند تقاطعات صفوف وأعمدة الخريطة ، نضع الحالات لمرحلة معينة ومنتج معين. بالنسبة للحالات ، تم تحديد مجموعة من الحالات:
- لا توجد معلومات - أو غير مناسب. من الضروري تحليل الطلب على مرحلة في المنتج. إما أن التحليل قد تم بالفعل ، ولكن المرحلة الحالية ليست ضرورية أو غير مبررة اقتصاديًا.
- مؤجل - أو غير ذي صلة في الوقت الحالي. هناك حاجة إلى مرحلة في خط الأنابيب ، لكن لا توجد قوى للتنفيذ هذا العام.
- المقرر. ومن المقرر تنفيذ المرحلة هذا العام.
- مُنفّذ. يتم تنفيذ المرحلة في خط الأنابيب بالحجم المطلوب.
بدأ ملء الجدول كل مشروع على حدة. أولاً: تم تصنيف مراحل وخطوات المشروع الواحد وتسجيل أوضاعها. ثم أخذوا المشروع التالي وأصلحوا الأوضاع فيه وأضافوا المراحل والخطوات التي كانت مفقودة في المشاريع السابقة. نتيجة لذلك ، حصلنا على مراحل وخطوات خط أنابيب الإنتاج بالكامل وحالاتها في مشروع معين. اتضح شيئًا مشابهًا لمصفوفة كفاءة خطوط أنابيب المنتج. أطلقنا على مثل هذه المصفوفة خريطة تكنولوجية.
بمساعدة الخريطة التكنولوجية ، ننسق بشكل معقول مع الفرق خطط العمل للعام والأهداف التي نريد تحقيقها معًا: المراحل التي نضيفها إلى المشروع هذا العام ، والمراحل التي نتركها لاحقًا. أيضًا ، أثناء العمل ، قد يكون لدينا تحسينات في المراحل التي أكملناها لمنتج واحد فقط. ثم نوسع خريطتنا ونقدم هذا التحسين كمرحلة أو خطوة جديدة ، ثم نحلل لكل منتج ونكتشف جدوى تكرار التحسين.
قد يعترضون علينا: "هذا كله ، بالطبع ، جيد ، فقط مع مرور الوقت ، سيصبح عدد الخطوات والمراحل كبيرًا بشكل مانع. كيف تكون؟
لقد قدمنا أوصافًا قياسية وكاملة إلى حد ما للمتطلبات لكل مرحلة وخطوة ، بحيث يفهمها الجميع داخل الشركة بنفس الطريقة. بمرور الوقت ، مع إدخال التحسينات ، قد يتم استيعاب الخطوة في مرحلة أو خطوة أخرى ، ثم "تنهار". في الوقت نفسه ، تتناسب جميع المتطلبات والفروق الدقيقة التكنولوجية مع متطلبات مرحلة أو خطوة التعميم.
كيف تقيم تأثير تكرار الحلول؟ نحن نستخدم نهجًا بسيطًا للغاية: ننسب تكاليف رأس المال الأولية لتنفيذ مرحلة جديدة إلى التكاليف السنوية العامة للمنتج ، ثم نقسمها على الكل عند التكرار.
تم بالفعل عرض أجزاء من التطوير كمعالم وخطوات على الخريطة. يمكننا التأثير على خفض تكلفة المنتج من خلال إدخال الأتمتة للمراحل النموذجية. بعد ذلك ، نأخذ في الاعتبار التغييرات في الخصائص النوعية والمقاييس الكمية والأرباح التي تحصل عليها الفرق (في ساعات العمل أو ساعات المدخرات الآلية).
الخريطة التكنولوجية لعملية الإنتاج
إذا اتخذنا جميع مراحلنا وخطواتنا ، وقمنا بترميزها بالعلامات وقمنا بتوسيعها في سلسلة واحدة ، فسوف يتضح أنها طويلة جدًا وغير مفهومة (فقط "ذيل الثعبان" الذي تحدثنا عنه في بداية المقالة) :
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]هذه هي مراحل بناء المنتجات [إنشاء] ، ونشرها لاختبار الخوادم [النشر] ، واختبار [اختبار] ، وتعزيز البنيات لإصدار المستودعات بناءً على نتائج اختبار [الترويج] ، وإنشاء ونشر التراخيص [الترخيص] ، والنشر [ انشر] على خادم تحديث GUS والتسليم إلى خوادم تحديث FLUS ، وتثبيت وتحديث مكونات المنتج على البنية التحتية للعميل باستخدام Product Configuration Management [تثبيت] ، بالإضافة إلى مجموعة القياس عن بعد [القياس عن بعد] من المنتجات المثبتة.
بالإضافة إلى ذلك ، يمكن التمييز بين المراحل المنفصلة: مراقبة حالة البنية التحتية [InfMonitoring] ، إصدار كود المصدر [SourceCodeControl] ، إعداد بيئة البناء [الإعداد] ، إدارة المشروع [سير العمل] ، تزويد الفرق بأدوات الاتصال [الاتصالات] ، شهادة المنتج [ الشهادة] وضمان الاكتفاء الذاتي لعمليات CI [CISelfSufficiency] (على سبيل المثال ، استقلال التجميعات عن الإنترنت). لن يتم حتى النظر في العشرات من الخطوات في عملياتنا ، لأنها محددة للغاية.
سيكون من الأسهل بكثير فهم وعرض عملية الإنتاج بأكملها إذا تم تقديمها في النموذج الخريطة التكنولوجية؛ هذا هو الجدول الذي تتم فيه كتابة مراحل الإنتاج الفردية والخطوات المتحللة للنموذج في صفوف ، وفي الأعمدة وصف لما تم القيام به في كل مرحلة أو خطوة. ينصب التركيز الرئيسي على الموارد التي توفر كل مرحلة ، وتحديد مجالات المسؤولية.
الخريطة بالنسبة لنا هي نوع من المصنفات. إنه يعكس الأجزاء التكنولوجية الكبيرة لإنتاج المنتجات. بفضل ذلك ، أصبح من السهل على فريق الأتمتة لدينا التفاعل مع المطورين والتخطيط المشترك لتنفيذ مراحل الأتمتة ، بالإضافة إلى فهم تكاليف العمالة والموارد (البشرية والأجهزة) المطلوبة لهذا الغرض.
داخل شركتنا ، يتم إنشاء الخريطة تلقائيًا من قالب jinja كملف HTML عادي ، ثم يتم تحميلها على خادم GitLab Pages. يمكن عرض لقطة شاشة مع مثال لخريطة تم إنشاؤها بالكامل .
سيؤدي النقر فوق الصورة إلى فتحها بالحجم الكامل
باختصار ، الخريطة التكنولوجية هي صورة عامة لعملية الإنتاج ، والتي تعكس بوضوح الكتل المصنفة ذات الوظائف النموذجية.
هيكل خريطة الطريق الخاصة بنا
تتكون الخريطة من عدة أجزاء:
- منطقة العنوان - يوجد هنا وصف عام للخريطة ، ويتم تقديم المفاهيم الأساسية ، ويتم تحديد الموارد والنتائج الرئيسية لعملية الإنتاج.
- لوحة القيادة - هنا يمكنك التحكم في عرض البيانات للمنتجات الفردية ، ويتم توفير ملخص للمراحل والخطوات المنفذة بشكل عام لجميع المنتجات.
- الخريطة التكنولوجية - وصف جدولي للعملية التكنولوجية. على الخريطة:
- يتم إعطاء جميع المراحل والخطوات ورموزها ؛
- يتم إعطاء وصف قصير وكامل للمراحل ؛
- يشار إلى موارد المدخلات والخدمات المستخدمة في كل مرحلة ؛
- يشار إلى نتائج كل مرحلة وخطوة منفصلة ؛
- يشار إلى منطقة المسؤولية لكل مرحلة وخطوة ؛
- تم تحديد الموارد التقنية ، مثل HDD (SSD) ، وذاكرة الوصول العشوائي ، ووحدة المعالجة المركزية الافتراضية ، وساعات العمل اللازمة لدعم العمل في هذه المرحلة ، سواء في الوقت الحالي - حقيقة ، أو في المستقبل - خطة ؛
- لكل منتج ، يُشار إلى المراحل أو الخطوات التكنولوجية الخاصة به التي تم تنفيذها أو المخطط لها للتنفيذ أو غير ذات الصلة أو التي لم يتم تنفيذها.
اتخاذ القرار على أساس الخريطة التكنولوجية
بعد فحص الخريطة ، يمكن اتخاذ بعض الإجراءات - اعتمادًا على دور الموظف في الشركة (مدير التطوير ، مدير المنتج ، المطور أو المختبِر):
- فهم المراحل المفقودة في منتج أو مشروع حقيقي ، وتقييم الحاجة إلى تنفيذها ؛
- تحديد مجالات المسؤولية بين العديد من الإدارات إذا كانت تعمل في مراحل مختلفة ؛
- الاتفاق على عقود في مداخل ومخارج المراحل.
- دمج مرحلة عملك في عملية التطوير الشاملة ؛
- تقييم أكثر دقة للحاجة إلى الموارد التي توفر كل مرحلة من المراحل.
تلخيص كل ما سبق
التوجيه متعدد الاستخدامات وقابل للتوسيع وسهل الصيانة. من الأسهل بكثير تطوير والحفاظ على وصف للعمليات في هذا النموذج مقارنة بنموذج IDEF0 الأكاديمي الصارم. بالإضافة إلى ذلك ، فإن الوصف الجدولي أبسط وأكثر دراية وأفضل تنظيماً من النموذج الوظيفي.
من أجل التنفيذ الفني للخطوات ، لدينا أداة داخلية خاصة CrossBuilder - أداة طبقة بين أنظمة CI والخدمات والبنية التحتية. لا يحتاج المطور إلى قطع دراجته: في نظام CI الخاص بنا ، يكفي تشغيل أحد البرامج النصية (ما يسمى بالمهمة) لأداة CrossBuilder ، والتي ستنفذها بشكل صحيح ، مع مراعاة ميزات بنيتنا التحتية .
نتائج
تبين أن المقالة طويلة جدًا ، لكن هذا أمر لا مفر منه عند وصف نمذجة العمليات المعقدة. في النهاية ، أود أن أصلح أفكارنا الرئيسية بإيجاز:
- الهدف من تنفيذ أفكار DevOps في شركتنا هو تقليل تكلفة إنتاج وصيانة منتجات الشركة باستمرار من الناحية الكمية (ساعات عمل أو ساعات عمل ، وحدة المعالجة المركزية الافتراضية ، ذاكرة الوصول العشوائي ، القرص).
- تتمثل طريقة تقليل التكلفة الإجمالية للتطوير في تقليل تكلفة أداء المهام التسلسلية النموذجية: مراحل وخطوات العملية التكنولوجية.
- المهمة النموذجية هي المهمة التي يكون حلها آليًا كليًا أو جزئيًا ، ولا يسبب صعوبات لفناني الأداء ولا يتطلب تكاليف عمالة كبيرة.
- تتكون عملية الإنتاج من مراحل ، وتنقسم المراحل إلى خطوات غير قابلة للتجزئة ، وهي مهام نموذجية ذات نطاق ونطاق مختلفين.
- من المهام النموذجية المتباينة ، وصلنا إلى سلاسل تكنولوجية معقدة ونماذج متعددة المستويات لعملية الإنتاج ، والتي يمكن وصفها بنموذج IDEF0 وظيفي أو خريطة تكنولوجية أبسط.
- الخريطة التكنولوجية هي تمثيل جدولي لمراحل وخطوات عملية الإنتاج. أهم شيء: الخريطة تسمح لك برؤية العملية برمتها في أجزاء كبيرة مع إمكانية تفصيلها.
- بناءً على الخريطة التكنولوجية ، من الممكن تقييم الحاجة إلى إدخال مراحل في منتج معين ، وتحديد مجالات المسؤولية ، والاتفاق على العقود عند مدخلات ومخرجات المراحل ، وتقييم الحاجة إلى الموارد بشكل أكثر دقة.
في المقالات التالية ، سنصف بمزيد من التفصيل الأدوات التقنية المستخدمة لتنفيذ مراحل تكنولوجية معينة على خريطتنا.
مؤلفو المقالات:
- - رئيس الأتمتة (DevOps) في شركة Positive Technologies
- - نائب رئيس قسم الأتمتة (DevOps) في شركة Positive Technologies
المصدر: www.habr.com