نحن نصنع مشروعًا سحابيًا للتنمية - منصة يمكنها تبسيط الحياة للمطورين والمطورين والمختبرين وقادة الفرق وغيرهم من المتخصصين المشاركين في عملية التطوير قدر الإمكان. هذا المنتج ليس الآن وليس للغد ، والحاجة إليه يتم تشكيلها للتو.
الفكرة الرئيسية هي أنه يمكنك نشر خط الأنابيب باستخدام أدوات تم تكوينها مسبقًا ، ولكن في نفس الوقت مع إمكانية إجراء عدد من الإعدادات ، كل ما عليك القيام به هو نشر الرمز.
من أين يأتي هذا الانحراف؟ نرى اتجاها واضحا بأن سرعة نشر المشاريع الجديدة تؤثر الآن على السوق. تعتمد التجارة على سرعة تسليم الإصدارات. من مدى سرعة إصلاح الأخطاء ، ومدى سرعة مشاركة المنافذ الجديدة. في بداية عام 2018 ، أجرت شركة "451 للأبحاث" العالمية مسحًا للتقنيات التي ستكون لها أولوية في التطوير. تتضمن العشرة الأوائل تقنيات إنشاء الحاويات وإدارتها ، بالإضافة إلى بنية التطبيقات والخدمات الصغيرة بدون خادم ، وتتجاوز حتى موضوع الضجيج مثل blockchain.
والآن لدينا سؤالان لك.
الرسم البياني من المسح:
هل هو ضروري؟
إن استخدام الحاويات في تطوير منتج جديد له مزاياه وعيوبه. يجب تحديد ما إذا كان سيتم استخدام هذه التكنولوجيا أم لا على أساس المهام المحددة. بالنسبة لعدد من المهام ، لا يمكن الاستغناء عن استخدام الحاويات ، وبالنسبة للبعض ، فهي ببساطة غير ضرورية. على سبيل المثال ، بالنسبة للمواقع ذات حركة المرور المنخفضة ، ستكون البنية البسيطة لخادمين كافية تمامًا. ولكن إذا تم التخطيط لنمو كبير في التنمية ، بالإضافة إلى زيادة كبيرة في عدد الزوار في وقت قصير ، فمن الجدير في هذه الحالة النظر في البنية التحتية باستخدام الحاويات.
استخدام الحاويات له مزايا عديدة:
- يتم تشغيل كل تطبيق بمعزل في الحاوية الخاصة به ، مما يقلل من المشكلات المتعلقة بالتكوين.
- يتم تحقيق أمان التطبيق أيضًا عن طريق عزل كل حاوية.
- نظرًا لأن الحاويات تستخدم نواة نظام التشغيل ، فلا حاجة الآن إلى نظام التشغيل الضيف ، حيث يتم تحرير كمية كبيرة من الموارد.
- أيضًا ، نظرًا لاستخدام نواة نظام التشغيل ولأنك لا تحتاج إلى الاعتماد على برنامج Hypervisor ، تتطلب الحاويات موارد أقل بكثير مقارنة بالتكديس الأخرى.
- مرة أخرى ، نظرًا لحقيقة أن الحاويات لا تتطلب نظام تشغيل ضيف ، فمن السهل ترحيلها من خادم إلى آخر.
- نظرًا لحقيقة أن كل تطبيق يعمل في حاوية معزولة ، فمن السهل التحويل من الجهاز المحلي إلى السحابة ؛
- إن بدء وإيقاف الحاوية "رخيصة" للغاية بسبب استخدام نواة نظام التشغيل.
فيما يتعلق بكل ما سبق ، نعتقد أن تكنولوجيا الحاوية هي حاليًا المكدس الأسرع والأكثر كفاءة في استخدام الموارد والأكثر أمانًا. نظرًا لمزايا الحاويات ، يمكن أن يكون لديك نفس البيئة سواء على الجهاز المحلي أو في الإنتاج ، مما يسهل عملية التكامل المستمر والتسليم المستمر.
فوائد الحاويات مقنعة للغاية بحيث سيتم استخدامها بالتأكيد لفترة طويلة قادمة.
ما علاقة السحابة بالتنمية؟
في العالم المثالي للمطور ، يجب أن يتم طرح أي رمز تنفيذ في الإنتاج بنقرة زر واحدة ، كما لو كان عن طريق السحر.
كان لدينا بهذه الطريقة: هناك Gitlabchik مع المهام ومصدر. عندما تحتاج إلى جمع شيء ما - GitLab Runner. نحن نعمل على Git Flow ، جميع الميزات في فروع منفصلة. عندما يدخل الفرع إلى المستودع ، يتم تشغيل الاختبارات على هذا الرمز في GitLab. في حالة اجتياز الاختبارات ، يمكن لمطور سلسلة المحادثات هذه تقديم طلب دمج ، في الواقع طلب لمراجعة التعليمات البرمجية. بعد المراجعة ، يتم قبول الفرع ودمجه في فرع dev ، وتجري الاختبارات من خلاله مرة أخرى. عند النشر ، يقوم GitLab Runner بتجميع حاوية Docker ولفها إلى خادم التدريج ، حيث يمكن النقر عليها وابتهاج. وإليكم الكمامه الأولى - ننظر من خلال الكود بأيدينا للامتثال للوظيفة وهذا أول شيء نقوم بإصلاحه. بعد ذلك ، نقوم بحقن الشفرة في فرع الإصدار. وبالنسبة لها ، فإننا نطرح إصدارًا منفصلاً ومنتجًا مسبقًا من حلنا ، والذي يشاهده عملاؤنا التجاريون. بعد تثبيت الإصدار مسبقًا على المنتج المسبق ، نوجهه إلى الإنتاج ويتحول إلى عقد المنتج. هناك ملاحظات إصدار تم إنشاؤها تلقائيًا وتقارير الأخطاء. كانت سرعة التجميع أكثر من 30 دقيقة ، والآن أصبح حجمها أقل. لقد اخترنا مجموعة من الأدوات لأنفسنا ونفكر الآن في كيفية عمل نفس SaaS الجاهزة.
بالنسبة لنا ، فإن عملية الإصدار النموذجي للإصدار هي كما يلي:
- تحديد أهداف لتنفيذ الميزات الجديدة
- توطين التعليمات البرمجية
- عمل التغييرات حسب المهام. كتابة الاختبارات الآلية قبل البناء.
- التحقق من الكود ، سواء اليدوي والاختبار الذاتي
- دمج الرمز في فرع مطور
- بناء فرع مطور
- نشر البنية التحتية للاختبار
- نشر الإصدار على البنية التحتية للاختبار
- إجراء الاختبارات والوظائف والتكامل وما إلى ذلك.
- في حالة وجود أخطاء ، قم بإنهائها على الفور في فرع dev
- ترحيل فرع مطور إلى فرع رئيسي
فيما يلي رسم تخطيطي يتضمن تفاصيل عن عمليتنا:
في الواقع ، السؤال الأول - من فضلك قل لنا أين أشعلت أي نوع من أشعل النار وكيف كان عالميًا أم لا هذا المخطط. إذا كنت تستخدم سير عمل مختلفًا جدًا عن هذا ، فأضف بضع كلمات ، لماذا ، من فضلك.
ما نوع المنتج الذي نخططه؟
قررنا عدم نسخ أمازون في هذا الصدد ، ولكن لإجراء تنميتنا مع مراعاة خصوصيات السوق. إبداء تحفظ على الفور أن جميع الحسابات هي رأينا الشخصي بناء على تحليلنا. نحن منفتحون على حوار بناء ومستعدون لتغيير خارطة الطريق للمنتج.
عند تحليل خط الأنابيب الحالي من Amazon ، توصلنا إلى استنتاج مفاده أن لديها قدرات هائلة ، ولكن التركيز على فرق الشركات الكبيرة جدًا. يبدو لنا أنه من أجل طرح خدمة صغيرة في Docker ، فهي طويلة بشكل غير معقول ، أكثر مما لو تم ، على سبيل المثال ، طرحها في Kubernetes ، لأنه يوجد مكان لتكوين التكوينات الداخلية ، وتحديد الاتفاقيات الداخلية ، إلخ. وكل هذا يحتاج إلى فهمه لفترة طويلة.
من ناحية أخرى ، هناك ، على سبيل المثال ، Heroku ، حيث يمكنك النشر بنقرة واحدة. ولكن نظرًا لحقيقة أن المشاريع ، كقاعدة عامة ، يتم تشفيرها تمامًا ، مع الخدمات الصغيرة التابعة لجهات خارجية ، في مرحلة ما يصبح من الضروري طرح صور مرسى مخصصة مع خدمات DBaaS وكل هذا لا يتناسب مع Herocku لأنه إما باهظ الثمن إما غير مريح.
نريد إيجاد خيار آخر. المتوسط الذهبي. اعتمادًا على نوع المشروع والمهام ، توفر لك مجموعة من الأدوات التي تم تكوينها مسبقًا والمدمجة بالفعل في خط أنابيب واحد ، مع ترك كل من إمكانية حدوث تغيير عميق في الإعدادات والقدرة على استبدال الأدوات نفسها.
لذا ماذا سيكون؟
النظام البيئي ، والذي يتضمن بوابة ومجموعة من الأدوات والخدمات لتقليل تفاعل المطورين مع مستوى البنية التحتية. يمكنك تحديد المعلمات البيئية غير المرتبطة بالبيئة المادية:
- بيئة التطوير (نظام إدارة التكوين ، نظام إعداد المهام ، مستودع لتخزين التعليمات البرمجية والتحف ، تعقب المهام)
- CI - التكامل المستمر (التجميع والبنية التحتية والتنظيم)
- ضمان الجودة - ضمان الجودة (الاختبار والمراقبة وتسجيل الدخول)
- انطلاق - تكامل البيئة / حلقة التجريبي
- الإنتاج - الدائرة الإنتاجية
باختيار الأدوات ، ركزنا على أفضل الممارسات في السوق.
سنقوم ببناء البنية التحتية مع Stage و Prod باستخدام Docker و Kubernetes مع ميزة إزالة الغبار المتوازية.
سيحدث هذا بشكل متكرر - في المرحلة الأولى ، تم التخطيط لخدمة تسمح لك بأخذ ملف Docker من المشروع ، ثم جمع الحاوية المطلوبة ووضعها على Kubernetes.
كما نخطط لإيلاء اهتمام خاص للخدمة لرصد عملية التطوير والتسليم المستمر. ماذا نعني بهذه الخدمة؟ هذه فرصة لإنشاء نموذج KPI هرمي مع مؤشرات مثل النسبة المئوية للتغطية بواسطة اختبارات الوحدة ، ومتوسط الوقت لإزالة حادثة أو عيب ، ومتوسط الوقت من الالتزام إلى التسليم ، إلخ.
جمع بيانات المصدر من أنظمة مختلفة - أنظمة إدارة الاختبار ، إدارة المهام ، مكونات CI / CD ، أدوات مراقبة الأشعة تحت الحمراء ، إلخ.
وأهم شيء هو أن تظهر بشكل ملائم متاح للتحليل السريع - لوحات العدادات مع إمكانية التعمق والتحليل المقارن للمؤشرات.
ماذا نريد ان نفعل
في الواقع ، أود حقًا أن أسمع منك كل هذا وخططنا للخطوات. الآن هم:
- البنية التحتية والتنظيم - Docker & Kubernetes
- إعداد المهام ، تخزين التعليمات البرمجية والقطع الأثرية ، تعقب المهام - Gitlab ، Redmine ، S3
- الإنتاج والتطوير - الشيف / Ansible
- الجمعية - جنكينز
- اختبار - السيلينيوم ، LoadRunner
- المراقبة والتسجيل - Prometheus & ELK
- بالمناسبة ، كيف ترى ما إذا كان سيكون هناك خيار داخل النظام الأساسي - إذا أردت ، اختر Jenkins ، لا تريد - GitLab Runner؟
- أو لا يهم ما هو بالداخل ، الشيء الرئيسي هو أن كل شيء تم بناؤه واختباره ونشره بشكل صحيح؟
كيف يمكن للمرء أن يساعد؟
سيتم تطوير المنتج للمطورين المحليين. إذا أخبرتنا الآن بكيفية القيام بذلك ، فمن المحتمل أنه سيتم تضمينه في الإصدار.
من فضلك قل لي ما المداخن التي تستخدمها الآن. يمكنك - في التعليقات أو عن طريق البريد الإلكتروني إلى team@ts-cloud.ru.
UPD: من أجل الراحة ، قمنا بعمل استبيان قصير في نموذج Google -
هنا .
علاوة على ذلك ، سنبقيك على اطلاع على التطورات - وفي مرحلة ما سنمنح المشاركين المساعدين الوصول إلى بيتا (في الواقع ، الوصول المجاني إلى موارد الحوسبة الجيدة للسحابة في مقابل التعليقات).