لقد طورنا DevOps بأفضل ما نستطيع. كنا 8 أشخاص ، وكان Vasya هو الأروع على نظام Windows. فجأة ، غادر Vasya ، وكان لدي مهمة إطلاق مشروع جديد يتم توفيره من خلال تطوير Windows. عندما سكبت حزمة تطوير Windows بالكامل على الطاولة ، أدركت أن الوضع مؤلم ...
هكذا تبدأ القصة الكسندرا سينشينوفا في . عندما غادر متخصص Windows الرائد الشركة ، تساءل ألكساندر عما يجب فعله الآن. قم بالتبديل إلى Linux ، بالطبع! سيخبرنا ألكساندر كيف تمكن من إنشاء سابقة ونقل جزء من تطوير Windows إلى Linux باستخدام مثال مشروع تم تنفيذه لـ 100،000 مستخدم نهائي.
كيف يمكن تسليم مشروع بسهولة إلى RPM باستخدام TFS و Puppet و Linux .NET core؟ كيف تحافظ على إصدار قاعدة بيانات المشروع إذا سمع التطوير الكلمات Postgres و Flyway لأول مرة ، وكان الموعد النهائي بعد غد؟ كيف تتكامل مع Docker؟ كيف تحفز مطوري .NET على الابتعاد عن Windows والعصائر لصالح Puppet و Linux؟ كيف يتم حل النزاعات الأيديولوجية إذا لم تكن هناك قوة ولا رغبة ولا موارد لخدمة Windows في الإنتاج؟ حول هذا ، بالإضافة إلى نشر الويب ، والاختبار ، و CI ، وحول ممارسات استخدام TFS في المشاريع الحالية ، وبالطبع حول العكازات المكسورة وحلول العمل ، في نص تقرير ألكسندر.
لذا ، غادر فاسيا ، المهمة علي عاتقي ، المطورين ينتظرون بفارغ الصبر مع مذراة. عندما أدركت أخيرًا أنه لا يمكن إرجاع فاسيا ، بدأت العمل. بادئ ذي بدء ، لقد قدرت نسبة Win VM في أسطولنا. النتيجة لم تكن لصالح Windows.
نظرًا لأننا نعمل بنشاط على تطوير DevOps ، فقد أدركت أن هناك شيئًا ما يحتاج إلى التغيير في نهج إصدار تطبيق جديد. كان هناك حل واحد فقط - إن أمكن ، انقل كل شيء إلى Linux. ساعدتني Google - في ذلك الوقت ، تم نقل Net بالفعل إلى Linux ، وأدركت أن هذا هو الحل!
لماذا NET core بالاشتراك مع Linux؟
كان هنالك عدة أسباب لهذا. بين "دفع المال" و "عدم الدفع" ، ستختار الغالبية الخيار الثاني - مثلي. تبلغ تكلفة ترخيص MSDB حوالي 1 دولار ، وتبلغ تكلفة صيانة أسطول من أجهزة Windows الافتراضية مئات الدولارات. بالنسبة لشركة كبيرة ، هذه تكلفة كبيرة. لهذا مدخرات - السبب الأول. ليست الأهم ، لكنها واحدة من أهمها.
تستهلك الأجهزة الافتراضية التي تعمل بنظام التشغيل Windows موارد أكثر من تلك التي تستهلكها أجهزة Linux الأخرى - هم ثقيلون. نظرًا لحجم شركة كبيرة ، اخترنا Linux.
تم دمج النظام ببساطة في CI موجود. نحن نعتبر أنفسنا DevOps تقدمية ، ونستخدم Bamboo و Jenkins و GitLab CI ، لذلك معظمنا يعمل على Linux.
السبب الأخير هو مرافقة مريحة. لقد احتجنا إلى خفض عتبة الدخول لـ "المشرفين" - الأشخاص الذين يفهمون الجزء الفني ، ويضمنون الاستمرارية ويخدمون الخدمات من السطر الثاني. لقد كانوا بالفعل على دراية بمكدس Linux ، لذلك من الأسهل عليهم فهم المنتج الجديد ودعمه وصيانته ، بدلاً من إنفاق موارد إضافية للتعامل مع الوظائف المماثلة للبرامج لمنصة Windows.
متطلبات
اولا في المقام الاول اولا قبل كل شي - راحة الحل الجديد للمطورين. لم يكن جميعهم جاهزين للتغيير ، خاصة بعد الكلمة المنطوقة Linux. يرغب المطورون في Visual Studio و TFS المفضل لديهم مع اختبارات تلقائية للبناء وعصائر. كيف يتم التسليم إلى الإنتاج ليس مهمًا بالنسبة لهم. لذلك ، قررنا عدم تغيير العملية المعتادة وترك كل شيء دون تغيير لتطوير Windows.
بحاجة الى مشروع جديد تضمينها في CI الحالي. كانت القضبان موجودة بالفعل وكان يجب القيام بكل العمل مع مراعاة معايير نظام إدارة التكوين ومعايير التسليم المقبولة وأنظمة المراقبة.
سهولة الصيانة والتشغيل، كشرط للحد الأدنى للدخول لجميع المشاركين الجدد من مختلف الإدارات وقسم الدعم.
الموعد النهائي - أمس.
فوز فريق التطوير
ما الذي كان يفعله فريق Windows في ذلك الوقت؟
الآن أستطيع أن أقول ذلك بثقة خادم الهوية4 هو بديل مجاني رائع لـ ADFS بميزات مماثلة ، أو أيا كان جوهر إطار الكيان - جنة للمطور ، حيث لا يمكنك عناء كتابة نصوص SQL ، ولكن وصف الاستعلامات في قاعدة البيانات من حيث OOP. ولكن بعد ذلك ، عند مناقشة خطة العمل ، نظرت إلى هذه المجموعة على أنها مسمارية سومرية ، مع الاعتراف فقط بـ PostgreSQL و Git.
في ذلك الوقت ، استخدمنا بنشاط دمية كنظام إدارة التكوين. استخدمنا في معظم مشاريعنا جيت لاب CI, مرن، موازنة الخدمات عالية التحميل باستخدام HAProxy ، تتبع كل شيء Zabbix، حزم جرافانا и محب العمل, جيجروكان كل هذا يدور على قطع من الحديد HP c ESXi في في إم وير. يعلم الجميع - كلاسيكي من هذا النوع.
دعونا ننظر ونحاول فهم ما حدث قبل أن نبدأ كل هذه التدخلات.
ماذا حدث
TFS هو نظام قوي إلى حد ما لا يسلم فقط الكود من المطور إلى آلة الإنتاج النهائية ، ولكن لديه أيضًا مجموعة للتكامل المرن للغاية مع الخدمات المختلفة - لتوفير CI على مستوى النظام الأساسي.
في السابق ، كانت هذه فتحات تهوية صلبة. استخدمت TFS العديد من وكلاء البناء الذين قاموا ببناء العديد من المشاريع. كل وكيل لديه 3-4 عمال لموازنة المهام وتحسين العملية. علاوة على ذلك ، وفقًا لخطط الإصدار ، سلمت TFS النسخة المخبوزة حديثًا إلى خادم تطبيقات Windows.
إلى أين نريد أن نذهب
نحن نستخدم TFS للتسليم والتطوير ، ونقوم بتشغيل التطبيق على خادم Linux Application ، وهناك بعض السحر بينهما. هذا الصندوق السحري وهناك ملح العمل الذي ينتظرنا. قبل تفكيكها ، سأتخذ خطوة جانبًا وأقول بضع كلمات عن التطبيق.
مشروع
يوفر التطبيق وظائف للتعامل مع البطاقات مسبقة الدفع.
العميل
كان هناك نوعان من المستخدمين. الأول يتم الوصول إليها عن طريق تسجيل الدخول بشهادة SSL SHA-2. في ثان تم الوصول إليه عن طريق اسم المستخدم وكلمة المرور.
HAProxy
ثم ذهب طلب العميل إلى HAProxy ، والذي قام بحل المهام التالية:
- الإذن الأساسي
- إنهاء SSL ؛
- ضبط طلبات HTTP ؛
- طلب الترجمة.
ذهب التحقق من شهادة العميل على طول السلسلة. نحن - السلطة ويمكننا تحمل ذلك ، حيث نقوم بأنفسنا بإصدار الشهادات لعملاء الخدمة.
انتبه إلى النقطة الثالثة ، بعد قليل سنعود إليها.
الخلفية
تم التخطيط للخلفية لتكون على لينكس. تتفاعل الواجهة الخلفية مع قاعدة البيانات ، وتحمّل قائمة الامتيازات المطلوبة ، وبعد ذلك ، بناءً على الامتيازات التي يمتلكها المستخدم المصرح له ، توفر الوصول لتوقيع المستندات المالية وإرسالها للتنفيذ ، أو إنشاء نوع من التقارير.
التوفير مع HAProxy
بالإضافة إلى السياقين اللذين سار عليهما كل عميل ، كان هناك أيضًا سياق هوية. خادم الهوية4 يسمح لك فقط بتسجيل الدخول ، وهذا تناظرية مجانية وقوية لـ ADFS - خدمات اتحاد الدليل النشط.
تمت معالجة طلب الهوية في عدة خطوات. الخطوة الأولى - زبون ضرب الخلفية، التي تواصلت مع هذا الخادم وتحققت من وجود رمز مميز للعميل. إذا لم يتم العثور عليه ، عاد الطلب إلى السياق الذي جاء منه ، ولكن مع إعادة التوجيه ، وبإعادة التوجيه انتقل إلى الهوية.
الخطوة الثانية - تم الحصول على الطلب إلى صفحة التفويض في IdentityServer ، حيث تم تسجيل العميل ، وظهر الرمز الذي طال انتظاره في قاعدة بيانات IdentityServer.
خطوة ثالثة - تمت إعادة توجيه العميل مرة أخرى إلى السياق الذي جاءت منه.
يحتوي IdentityServer4 على ميزة: تقوم بإرجاع الاستجابة لطلب الإرجاع عبر HTTP. بغض النظر عن مدى صعوبة إعداد الخادم ، بغض النظر عن مدى استنارة الوثائق ، في كل مرة تلقينا طلب العميل الأولي بعنوان URL جاء عبر HTTPS ، وأرجع IdentityServer نفس السياق ، ولكن مع HTTP. لقد صدمنا! وقمنا بنقل كل هذا من خلال سياق الهوية إلى HAProxy ، وفي الرؤوس كان علينا تعديل بروتوكول HTTP إلى HTTPS.
ما هو التحسن وأين قمت بحفظه؟
لقد وفرنا المال باستخدام حل مجاني لترخيص مجموعة من المستخدمين ، والموارد ، لأننا لم نقم بإخراج IdentityServer4 كعقدة منفصلة في مقطع منفصل ، ولكننا استخدمناها مع الواجهة الخلفية على نفس الخادم حيث تعمل الواجهة الخلفية للتطبيق .
كيف ينبغي أن تعمل
لذلك ، كما وعدت - ماجيك بوكس. نحن نتفهم بالفعل أننا مضمونون للتحرك نحو Linux. لنقم بصياغة المهام المحددة التي يجب حلها.
مانيفست الدمى. لتقديم وإدارة تكوين الخدمة والتطبيق ، كان عليك كتابة وصفات رائعة. تُظهر لفة القلم الرصاص ببلاغة مدى سرعة وكفاءة القيام بذلك.
طريقة التوصيل. المعيار هو RPM. يدرك الجميع أنه لا توجد طريقة بدونها في Linux ، لكن المشروع نفسه بعد التجميع كان عبارة عن مجموعة من ملفات DLL القابلة للتنفيذ. كان هناك حوالي 150 منهم ، المشروع ثقيل للغاية. الحل الوحيد المتناسق هو تجميع هذا الثنائي في RPM ونشر التطبيق منه.
الإصدار. كان علينا الإفراج كثيرًا ، وكان علينا أن نقرر كيفية تشكيل اسم الحزمة. إنها مسألة مستوى التكامل مع TFS. كان لدينا وكيل بناء على Linux. عندما يرسل TFS مهمة إلى عامل - عامل - على وكيل البناء ، فإنه يمرر أيضًا مجموعة من المتغيرات إليه ، والتي تقع في بيئة عملية المعالج. يتم تمرير متغيرات البيئة هذه إلى اسم البنية واسم الإصدار والمتغيرات الأخرى. اقرأ المزيد عن هذا في قسم "إنشاء حزمة RPM".
إعداد TFS نزل إلى إنشاء خط الأنابيب. في السابق ، قمنا بجمع جميع مشاريع Windows على وكلاء Windows ، ولكن يظهر الآن وكيل Linux - وكيل البناء الذي يجب تضمينه في مجموعة البناء ، مع إثراء بعض الأدوات ، لتحديد نوع المشاريع التي سيتم بناؤها على عامل البناء هذا ، وتعديل خط الأنابيب بطريقة أو بأخرى.
IdentityServer. ADFS ليس طريقنا ، نحن نغرق في المصدر المفتوح.
لنستعرض المكونات.
الصندوق السحري
يتكون من أربعة أجزاء.
عامل بناء Linux. لينكس ، لأننا نبني له - إنه منطقي. تم تنفيذ هذا الجزء في ثلاث خطوات.
- قم بإعداد العمال وليس واحدًا ، حيث تم افتراض العمل الموزع على المشروع.
- قم بتثبيت .NET Core 1.x. لماذا 1.x عندما يكون الإصدار 2.0 متاحًا بالفعل في المستودع القياسي؟ لأنه عندما بدأنا التطوير ، كان الإصدار الثابت 1.09 ، وتقرر إنشاء المشروع من أجله.
- بوابة 2.x.
مستودع RPM. يلزم تخزين حزم RPM في مكان ما. كان من المفترض أن نستخدم نفس مستودع RPM الخاص بالشركة والمتاح لجميع مضيفي Linux. وهكذا فعلوا. تم تكوين خادم المستودع الرد التلقائي على الويب الذي قام بتنزيل حزمة RPM المطلوبة من الموقع المحدد. أبلغ وكيل الإنشاء عن إصدار حزمة الويب هوك.
جيت لاب. انتباه! لا يتم استخدام GitLab هنا من قبل المطورين ، ولكن بواسطة قسم العمليات للتحكم في إصدارات التطبيقات وإصدارات الحزم والتحكم في حالة جميع أجهزة Linux ويقوم بتخزين الوصفة - جميع قوائم الدمى.
دمية - يحل جميع النقاط المثيرة للجدل ويقدم بالضبط التكوين الذي نريده من Gitlab.
نبدأ في الغوص. كيف يتم تسليم DLL إلى RPM؟
تسليم DDL إلى RPM
لنفترض أن لدينا نجم روك لتطوير .NET. يستخدم Visual Studio ويقوم بإنشاء فرع تحرير. بعد ذلك ، يقوم بتحميله إلى Git ، و Git هنا هو كيان TFS ، أي أنه مستودع التطبيقات الذي يعمل معه المطور.
ثم يرى TFS أن التزامًا جديدًا قد وصل. أي تطبيق؟ في إعدادات TFS ، يوجد تسمية بالموارد التي يمتلكها وكيل الإنشاء هذا أو ذاك. في هذه الحالة ، يرى أننا نبني مشروع NET Core ويختار وكيل Linux Build من المجموعة.
يتلقى وكيل البناء المصادر ، ويقوم بتنزيل ما يلزم التبعيات من مستودع .NET ، npm ، إلخ. وبعد إنشاء التطبيق نفسه والتعبئة اللاحقة ، يتم إرسال حزمة RPM إلى مستودع RPM.
من ناحية أخرى ، يحدث ما يلي. يشارك مهندس قسم العمليات بشكل مباشر في إطلاق المشروع: يقوم بتغيير إصدارات الحزم في هييرا في المستودع حيث يتم تخزين وصفة التطبيق ، وبعد ذلك يتم تشغيل Puppet يم، يسحب حزمة جديدة من المستودع ، والإصدار الجديد من التطبيق جاهز للاستخدام.
بكلمات ، كل شيء بسيط ، ولكن ماذا يحدث داخل وكيل البناء نفسه؟
حزم DLL RPMs
تم استلام مصادر المشروع وبناء المهام من TFS. بناء وكيل يبدأ في بناء المشروع نفسه من المصادر. المشروع المجمع متاح كمجموعة dll، والتي يتم تعبئتها في أرشيف مضغوط لتقليل الحمل على نظام الملفات.
تم التخلص من أرشيف ZIP إلى دليل الإنشاء لحزمة RPM. بعد ذلك ، يقوم سكربت Bash بتهيئة متغيرات البيئة ، والعثور على نسخة البناء ، وإصدار المشروع ، والمسار إلى دليل الإنشاء ، وتشغيل RPM-build. عند اكتمال الإنشاء ، يتم نشر الحزمة إلى المستودع المحلي، والذي يقع في وكيل البناء.
علاوة على ذلك ، من وكيل البناء إلى الخادم في مستودع RPM تم إرسال طلب JSON مع اسم الإصدار والبناء. Webhook ، الذي ذكرته سابقًا ، يقوم بتنزيل هذه الحزمة نفسها من المستودع المحلي على وكيل الإنشاء ويجعل البنية الجديدة متاحة للتثبيت.
لماذا مثل هذا المخطط لتسليم حزمة إلى مستودع RPM؟ لماذا لا يمكنك دفع الحزمة المبنية على الفور إلى المستودع؟ الحقيقة هي أن هذا شرط لضمان الأمن. يحد هذا السيناريو من إمكانية قيام الأشخاص غير المصرح لهم بتحميل حزم RPM على خادم يمكن الوصول إليه من جميع أجهزة Linux.
إصدارات قاعدة البيانات
في استشارة التطوير ، اتضح أن الرجال كانوا أقرب إلى MS SQL ، ولكن في معظم المشاريع التي لا تعمل بنظام Windows ، استخدمنا بالفعل PostgreSQL مع القوة والرئيسية. نظرًا لأننا قررنا بالفعل التخلي عن كل ما يتم دفعه ، فقد بدأنا في استخدام PostgreSQL هنا أيضًا.
في هذا الجزء ، أريد أن أخبرك كيف قمنا بتقسيم قاعدة البيانات إلى الإصدار وكيف اخترنا بين Flyway و Entity Framework Core. ضع في اعتبارك إيجابياتهم وسلبياتهم.
سلبيات
Flyway يذهب في اتجاه واحد فقط ، نحن لا يمكننا التراجع هو عيب كبير. يمكنك المقارنة مع Entity Framework Core بطرق أخرى - من حيث راحة المطور. تتذكر أننا وضعنا هذا في المقدمة ، وكان المعيار الرئيسي هو عدم تغيير أي شيء لتطوير Windows.
لطيران لنا هناك حاجة إلى نوع من الغلافحتى لا يكتب الرجال استعلامات SQL. هم أقرب بكثير للعمل من حيث OOP. كتبنا تعليمات للعمل مع كائنات قاعدة البيانات ، وشكلنا استعلام SQL ونفذنا. الإصدار الجديد من قاعدة البيانات جاهز وملف - كل شيء على ما يرام ، كل شيء يعمل.
Entity Framework Core له ناقص - في ظل الأحمال الثقيلة يبني استعلامات SQL غير الأمثل، ويمكن أن يكون التراجع في قاعدة البيانات كبيرًا. ولكن نظرًا لعدم وجود خدمة محملة بشكل كبير ، فإننا لا نحسب الحمل بمئات RPS ، فقد قبلنا هذه المخاطر وفوضنا المشكلة للمستقبل.
الايجابيات
جوهر إطار الكيان يعمل خارج الصندوق وسهل التطويرو Flyway يندمج بسهولة في CI الحالي. لكننا نقوم بذلك بشكل ملائم للمطورين :)
إجراء Roll-on
ترى Puppet أن تغييرًا قادمًا في إصدار الحزم ، من بينها الإصدار المسؤول عن الترحيل. أولاً ، يقوم بتثبيت حزمة تحتوي على البرامج النصية للترحيل والوظائف المتعلقة بقاعدة البيانات. بعد ذلك ، يتم إعادة تشغيل التطبيق الذي يعمل مع قاعدة البيانات. يأتي بعد ذلك تثبيت المكونات المتبقية. يتم وصف الترتيب الذي يتم به تثبيت الحزم وتشغيل التطبيقات في بيان Puppet.
تستخدم التطبيقات بيانات حساسة ، مثل الرموز وكلمات مرور قاعدة البيانات ، يتم سحب كل هذا في التكوين من Puppet master ، حيث يتم تخزينها في شكل مشفر.
قضايا TFS
بعد أن قررنا وأدركنا أن كل شيء يعمل بالفعل بالنسبة لنا ، قررت أن أرى ما كان يحدث مع التجمعات في TFS بشكل عام لقسم تطوير Win في مشاريع أخرى - هل سنقوم / نفرج بسرعة أم لا ، ووجدت مشاكل كبيرة مع السرعة .
سيستغرق أحد المشاريع الرئيسية من 12 إلى 15 دقيقة - إنها فترة طويلة ، لا يمكنك العيش على هذا النحو. أظهر تحليل سريع انخفاضًا رهيبًا في الإدخال / الإخراج ، وهذا على المصفوفات.
بعد تحليل مكون بمكون ، حددت ثلاث بؤر. أولاً - مضاد الفيروسات كاسبيرسكي، الذي يقوم بمسح المصادر على جميع وكلاء Windows Build. ثانية - Windows مفهرس. لم يتم تعطيله ، وتم فهرسة كل شيء على وكلاء الإنشاء في الوقت الفعلي أثناء عملية النشر.
ثالث - تثبيت npm. اتضح أننا استخدمنا هذا السيناريو في معظم خطوط الأنابيب. لماذا هو سيء؟ يتم تشغيل إجراء تثبيت Npm عند إنشاء شجرة التبعية بتنسيق حزمة lock.json، حيث يتم إصلاح إصدارات الحزم التي سيتم استخدامها لبناء المشروع. الجانب السلبي هو أن Npm install يسحب أحدث إصدارات الحزم من الإنترنت في كل مرة ، وهذا كثير من الوقت في حالة وجود مشروع كبير.
يقوم المطورون أحيانًا بإجراء تجارب على جهاز محلي لاختبار أداء جزء معين أو مشروع بأكمله. في بعض الأحيان اتضح أن كل شيء كان رائعًا محليًا ، لكنهم جمعوه وطرحوه - لم ينجح شيء. نبدأ في فهم ماهية المشكلة - نعم ، إصدارات مختلفة من الحزم ذات التبعيات.
حل
- المصادر في استثناءات AV.
- تعطيل الفهرسة.
- اذهب إلى npm ci.
ميزة npm ci هي أننا اجمع شجرة التبعية مرة واحدة، ونحصل على فرصة توفيرها للمطور قائمة الحزم المحدثة، والتي يمكن أن يجربها محليًا بقدر ما يريد. هذا يوفر الوقت المطورين الذين يكتبون الكود.
ترتيب
الآن قليلا عن تكوين المستودع. تاريخيا استخدمنا رابطة لإدارة المستودعات ، بما في ذلك إعادة الشراء الداخلية. يأتي هذا المستودع الداخلي مع جميع المكونات التي نستخدمها للأغراض الداخلية ، على سبيل المثال ، المراقبة الذاتية.
نحن نستخدم أيضا NuGet، لأنه يخزن بشكل مؤقت أفضل من مديري الحزم الآخرين.
نتيجة
بعد أن قمنا بتحسين عوامل الإنشاء ، تم تقليل متوسط وقت الإنشاء من 12 دقيقة إلى 7.
إذا قمنا بحساب جميع الأجهزة التي يمكننا استخدامها لنظام التشغيل Windows ، ولكننا انتقلنا إلى Linux في هذا المشروع ، فقد وفرنا حوالي 10 دولار. وهذا فقط على التراخيص ، وإذا قمت بتضمين محتوى ، فسيكون هناك المزيد.
خطط
في الربع التالي ، خططنا للعمل على تحسين توصيل الكود.
التبديل إلى صورة Docker سابقة الإنشاء. TFS هو شيء رائع مع العديد من المكونات الإضافية التي تسمح لك بالاندماج في Pipeline ، بما في ذلك البناء على مشغل ، على سبيل المثال ، صورة Docker. نريد أن نجعل هذا الزناد على نفسه حزمة lock.json. إذا تغير تكوين المكونات المستخدمة لبناء المشروع بطريقة ما ، فإننا نبني صورة Docker جديدة. يتم استخدامه لاحقًا لنشر الحاوية مع التطبيق المدمج. الآن ليس هذا هو الحال ، لكننا نخطط للتحول إلى بنية الخدمات المصغرة في Kubernetes ، والتي تتطور بنشاط في شركتنا وتقدم حلول الإنتاج لفترة طويلة.
ملخص
أحث الجميع على التخلص من Windows ، لكن هذا ليس لأنني لا أستطيع طهيه. والسبب هو أن معظم الحلول مفتوحة المصدر مكدس لينكس. هل انت بخير انقاذ على الموارد. في رأيي ، المستقبل ينتمي إلى الحلول مفتوحة المصدر على Linux مع مجتمع قوي.
المتحدث الشخصي الكسندر سينشينوف .
هو مؤتمر حول تكامل عمليات التطوير والاختبار والتشغيل للمهنيين من المتخصصين. ما هو سبب المشروع الذي تحدث عنه الإسكندر؟ تم التنفيذ والعمل ، وتم إصدار إصدارين ناجحين في يوم الأداء. على في 27 و 28 مايو سيكون هناك المزيد من هذه الحالات من الممارسين. لا يزال بإمكانك القفز إلى آخر سيارة و أو ليس في عجلة من أمره تذكرة. نراكم في سكولكوفو!
المصدر: www.habr.com