لقد أنشأنا أداة تدمج Docker و Maven لمساعدة مئات المطورين لدينا على إدارة بيئات التطوير المعقدة بمئات الخدمات ، بأقل جهد ممكن. هذه هي قصة كيف أصبحت فكرة مجنونة حقيقة واقعة. هذه هي قصة
Carnotzet .
بدأ كل شيء منذ حوالي خمس سنوات (تاريخ النشر تقريبًا 3 أغسطس 2017) ، تطورت Swissquote وسرعان ما تطورت. في ذلك الوقت ، كان لدينا حوالي 70 مطورًا يعملون في مشاريع جافا كبيرة الحجم (تقريبًا متجانسة) ، والتي تتطلب من كل منهم قضاء يوم إلى يومين لتهيئة بدء المشروع محليًا. نحن نكره إضاعة الوقت في المهام المتكررة! لذلك ، تقرر تحسين هذه العملية باستخدام Vagrant and Chef لأتمتة نشر بيئة التطوير المحلية الخاصة بنا. يمثل هذا بداية مشروع Sandbox الأول (Sandbox ، تقريبًا)
نود أن نشارك بيئات تطوير واختبار خفيفة الوزن وقابلة للتكرار ومعزولة ومحمولة.
لفترة من الوقت ، كان كل شيء على نحو سلس. يمكن للمطورين ببساطة تنزيل المشروع وتنفيذ "المبشر" والبدء في العمل. استخدمنا هذا النهج لمدة عامين تقريبا ، ونحن سعداء للغاية.
بعد ذلك ، أصبح العمل على هذه التطبيقات الكبيرة أكثر صعوبة بسبب حقيقة أن منطق الأعمال أصبح أكثر تعقيدًا (وضع العلامات البيضاء على منصة التداول الخاصة بنا). وقررنا أن نفعل ما فعلته معظم المنظمات في عام 2014: تقسيم المنطق إلى خدمات ميكروية.
سارت الأمور على ما يرام ، وبحلول عام 2016 ، كان لدينا حوالي 150 خدمة (صغيرة ، تقريبية) في الإنتاج. لكن البرامج النصية للشيف المستخدمة لتكوين الأجهزة الافتراضية قد نمت وأصبحت خارجة عن نطاق السيطرة. أصبحت بيئات التطوير أكثر تعقيدًا بالنسبة لبعض التطبيقات مع حوالي 30 تبعيات. اكتشفنا أيضًا أن معرفة الشيف لم تكن جزءًا من مجموعة المهارات القياسية لمطورينا. لهذا السبب ، قام الكثير من الناس ببساطة بعمل النص ، في بعض الأحيان ، من خلال نسخ أمثلة سيئة. في محاولة لعدم كسر التكوين الخاص بالفرق الأخرى ، قاموا بإنشاء وجبات خفيفة لفترة طويلة لتلبية احتياجاتهم الخاصة بالفريق ، ونتيجة لذلك ، لم يعد كود تهيئة بيئة التطوير عامًا.
كان علينا إصلاحه.
تم تحديد نقاط الضعف التالية في صندوق الرمال:
- بحاجة الى معرفة الشيف. وبالنسبة للمطورين الحاليين ، وبالنسبة للمبتدئين ، كان تعلم هذا الإطار متعة كبيرة.
أيضا ، هذا كان زائدا فقط لتطوير / اختبار البيئة. - لم يكن هناك طريقة لسهولة التجريد / التكوين أو إعادة استخدام جزء من تكوين البيئة. وأدى ذلك إلى حقيقة أن الناس اضطروا إلى الخوض في جميع التفاصيل والفروق الدقيقة في تكوين التبعية لمشاريعهم ، والتي كانت تدعمها عادة الفرق الأخرى. هذا أدى إلى خلاف وتفاعل غير ضروري بين الفرق.
من أجل إصلاح النقطة الأولى ، تقرر التبديل إلى استخدام Docker. له حد دخول أدنى ويوفر أيضًا مزايا أخرى ، مثل التقييس ودعم PaaS ونشر أسهل عبر بيئات متعددة.
نظرنا أيضًا في استخدام عامل الإرساء فقط. بدا الأمر واعداً للغاية ، لكن على الرغم من اسمه ، فقد افتقر إلى أشياء مثل إمكانية التكوين ، وفي الوقت نفسه التجريد وإعادة الاستخدام. هذه هي الجوانب التي نحتاجها. لقد حلمنا أن نكون قادرين على أخذ بيئة التطوير / الاختبار الحالية ، وإضافة خدمة واحدة إليها ، وإعادة اختيار جزء من تكوينه بشكل اختياري. أردنا تحقيق هذا دون الحاجة إلى نسخ تكوين الخدمة المضافة أو الخوض في تفاصيل التبعيات متعدية وتكوينها.
عندها كانت لدينا هذه الفكرة: "ماذا لو أخذنا Maven ، نظام إدارة التبعية الذي نستخدمه لبناء تطبيقات جافا لدينا ، والبدء في استخدامه لبناء بيئاتنا؟". سيسمح لنا ذلك باستخلاص التبعيات التعددية الخاصة بنا وتكوين الحزم وإنشاء نسخ منها وإعادة استخدامها. لن تكون هناك أيضًا حاجة لتعلم نظام جديد لإدارة التبعية.
بعد عدد من المحاولات ، توصلنا إلى الحل التالي:
- يمثل كل قطعة أثرية من Maven بيئة تعمل بكامل طاقتها والتي يمكن استخدامها كتبعية في بيئات أخرى. (يمكن تمثيل البيئة الدنيا بواسطة خدمة واحدة ، على سبيل المثال ، قاعدة بيانات)
- تحتوي ملفات JAR على التكوين. متغيرات البيئة ، ملفات تكوين التطبيق ، اسم Docker للصور ، إلخ.
- يمكن تجاوز هذا التكوين في الوحدات النمطية الموجودة أعلى التسلسل الهرمي التبعية ، إذا لزم الأمر.
- يمكن لمكتبة جافا رفع البيئة الكاملة (باستخدام عامل التأسيس تحت الغطاء) من وحدة Maven (GAV أو pom.xml)
يجعل Maven من الممكن توزيع وإصدار هذه القطع الأثرية ("الآثار البيئية") ويمكننا بسهولة مشاركة الكود المصدري بين الفرق. أصبحت العملية أكثر بساطة وبدأ المطورين في استخدام وحدات من الفرق الأخرى. وأيضا إنشاء والحفاظ على الخاصة بك.
على سبيل المكافأة ، يمكن استخدام جميع الأدوات التي تسهل العمل مع Maven هنا. على سبيل المثال ، يُظهر لنا رسم التبعية الذي تم إنشاؤه باستخدام IntelliJ IDEA الآن مخططًا للهندسة المعمارية لتفاعل تبعياتنا :)
هندسة
تطبيق مثال
التصويت من عامل إنشاءفي الوقت نفسه ، كانت هناك بعض الصعوبات في التنفيذ ، مثل إجبار جميع الفرق على حزم التطبيقات باستخدام Docker (dockerize) وتكوينات الحزم في وحدات Maven منفصلة. بكل المقاييس ، أصبح من الأسهل استيراد التطبيقات من الفرق الأخرى ودعم بيئات التطوير المعقدة.
بدأنا العمل في هذا الاتجاه منذ حوالي عام ، والآن لدينا حوالي 200 من هذه الوحدات المستخدمة للتطوير والاختبار. لقد توصلنا إلى استنتاج مفاده أن هذه المكتبة رائعة أيضًا لإدارة البيئة المؤقتة للاختبار الشامل على منصة CI الخاصة بنا.
نحن ندرس حاليًا كيفية إعادة استخدام هذه التقنية لإدارة بيئات UAT / التكامل الخاصة بنا من خلال إطلاق الحاويات في Kubernetes بدلاً من إنشاء عامل الإرساء ، وبالتالي ضمان التحديثات المتجددة ومرونة الحوسبة في بيئات أكبر بكثير.
آمل أن تكونوا سعداء لمعرفة أن مشروعنا قد تم افتتاحه بموجب ترخيص Apache 2.0 ومتاح على Github:
github.com/swissquote/carnotzetاستخدم :)