العقود العامة ، وكيفية ضمان اتساقها

  • هل يتكون نظامك من العديد من الخدمات المترابطة؟
  • لا يزال تحديث رمز الخدمة يدويًا عند تغيير واجهة برمجة التطبيقات العامة؟
  • غالبًا ما تقوض التغييرات في خدماتك عمل الآخرين ، ويكرهك المطورون الآخرون لهذا الأمر؟

إذا أجبت بنعم مرة واحدة على الأقل ، فمرحبا بك!

شروط


العقود والمواصفات العامة - واجهات عامة يمكنك من خلالها التفاعل مع الخدمة. في النص يقصدون نفس الشيء.

عن ماذا تتحدث المقالة


تعرف على كيفية تقليل الوقت المستغرق في تطوير خدمات الويب باستخدام أدوات لوصف موحد للعقود وإنشاء التعليمات البرمجية تلقائيًا.

يتيح لك الاستخدام الصحيح للتقنيات والأدوات الموضحة أدناه طرح ميزات جديدة بسرعة وعدم كسر الميزات القديمة.

كيف تبدو المشكلة


هناك نظام يتكون من عدة خدمات. يتم تعيين هذه الخدمات لفرق مختلفة.



تعتمد خدمات المستهلك على مزود الخدمة.
يتطور النظام ، ويغير مزود الخدمة ذات يوم عقوده العامة.



إذا لم تكن خدمات المستهلك جاهزة للتغيير ، فعندئذ يتوقف النظام عن العمل بشكل كامل.



كيفية حل هذه المشكلة


سيقوم فريق خدمة الموردين بإصلاح كل شيء


يمكن القيام بذلك إذا كان فريق الموردين يمتلك مجال الموضوع للخدمات الأخرى ولديه حق الوصول إلى مستودعات git الخاصة بهم. سيعمل هذا فقط في المشاريع الصغيرة عندما يكون هناك عدد قليل من الخدمات التابعة. هذا هو الخيار الأرخص. إذا أمكن ، يجب عليك استخدامه.

قم بتحديث رمز خدمتك إلى فريق المستهلك


لماذا ينكسر الآخرون ، لكن هل نصلح؟

ومع ذلك ، فإن السؤال الرئيسي هو كيفية إصلاح خدمتك ، كيف يبدو العقد الآن؟ تحتاج إلى معرفة رمز خدمة الموفر الجديد أو الاتصال بفريقهم. نقضي وقتًا في دراسة الرمز والتفاعل مع فريق آخر.

فكر في ما يجب فعله لمنع ظهور المشكلة


الخيار الأكثر منطقية على المدى الطويل. اعتبره في القسم التالي.

كيفية منع ظهور مشكلة


يمكن تمثيل دورة حياة تطوير البرمجيات في ثلاث مراحل: التصميم والتنفيذ والاختبار.

يجب توسيع كل خطوة على النحو التالي:

  1. في مرحلة التصميم تحديد العقود بشكل معلن ؛
  2. أثناء التنفيذ ، نقوم بإنشاء رمز الخادم والعميل بموجب العقود ؛
  3. عند الاختبار ، نتحقق من العقود ونحاول أن نأخذ في الاعتبار احتياجات العملاء (CDC).

يتم شرح كل خطوة بشكل أكبر كمثال لمشكلتنا.

كيف تبدو المشكلة معنا




هذا ما يبدو عليه نظامنا البيئي.
الدوائر هي خدمات والأسهم هي قنوات اتصال بينهما.

Frontend هو تطبيق عميل يستند إلى الويب.

تؤدي معظم الأسهم إلى خدمة التخزين. يقوم بتخزين المستندات. هذه اهم خدمة بعد كل شيء ، منتجنا هو نظام إدارة إلكتروني للوثائق.

إذا قامت هذه الخدمة بتغيير عقودها ، فسوف يتوقف النظام على الفور عن العمل.



تتم كتابة مصادر نظامنا بشكل أساسي في c # ، ولكن هناك أيضًا خدمات في Go و Python. في هذا السياق ، لا يهم ما تفعله الخدمات الأخرى في الشكل.



كل خدمة لها تنفيذ العميل الخاص بها للعمل مع خدمة التخزين. عند تغيير العقود ، يجب عليك تحديث الرمز يدويًا في كل مشروع.

أود الابتعاد عن التحديث اليدوي نحو التلقائي. سيساعد ذلك على زيادة معدل تغير رمز العميل وتقليل الأخطاء. الأخطاء هي أخطاء إملائية في عنوان URL ، والأخطاء بسبب الإهمال ، وما إلى ذلك.

ومع ذلك ، لا يؤدي هذا الأسلوب إلى إصلاح الأخطاء في منطق الأعمال العميل. يمكنك ضبطه يدويًا فقط.

من مشكلة إلى مهمة


في حالتنا ، يلزم تنفيذ إنشاء تلقائي لرمز العميل.
عند القيام بذلك ، ينبغي مراعاة ما يلي:

  • جانب الخادم - تمت كتابة وحدات التحكم بالفعل ؛
  • المتصفح هو عميل للخدمة ؛
  • تتواصل الخدمات عبر HTTP.
  • يجب ضبط الجيل. على سبيل المثال ، لدعم JWT.

الأسئلة


في سياق حل المشكلة ، أثيرت الأسئلة:

  • الأداة التي تختارها ؛
  • كيفية الحصول على العقود ؛
  • مكان وضع العقود ؛
  • مكان وضع رمز العميل ؛
  • عند أي نقطة للقيام بالجيل.

فيما يلي إجابات لهذه الأسئلة.

الأداة التي تختارها


يتم تقديم أدوات للعمل مع العقود في اتجاهين - RPC و REST.



يمكن فهم RPC على أنه مجرد مكالمة عن بُعد ، بينما تتطلب REST شروطًا إضافية لأفعال HTTP وعناوين URL.

يتم عرض الاختلافات في استدعاء RPC و REST هنا.
RPC - استدعاء الإجراء البعيدREST Representational State Transfer
, HTTP- URL
Restaurant:8080/Orders/PlaceOrderPOSTRestaurant:8080/Orders
Restaurant:8080/Orders/GetOrder?OrderNumber=1GETRestaurant:8080/Orders/1
Restaurant:8080/Orders/UpdateOrderPUTRestaurant:8080/Orders/1


أدوات


يوضح الجدول مقارنة بين أدوات العمل مع REST و RPC.
الخصائصOpenapiWsdlتقطيرgRPC
نوعراحةRpc
منصةلا يعتمد
لسانلا يعتمد
تسلسل التنمية *كود أولا ، المواصفات أولاكود أولا ، المواصفات أولاالمواصفات أولاًكود أولا ، المواصفات أولا
بروتوكول النقلHTTP / 1.1أي (يتطلب REST HTTP)خاصةHTTP / 2
رأيتخصيصإطار العمل
تعليقعتبة دخول منخفضة ، الكثير من الوثائقتكرار XML ، SOAP ، إلخ.عتبة دخول عالية ، وثائق قليلةمتوسط ​​عتبة الإدخال ، وثائق أفضل
الرمز أولاً - أولاً نكتب جزء الخادم ، ثم نحصل على عقود عليه. وهو ملائم عندما تتم كتابة جانب الخادم بالفعل. لا حاجة لوصف العقود يدويًا.

المواصفات أولاً - أولاً نحدد العقود ، ثم نحصل على جزء العميل وجزء الخادم منها. إنه ملائم في بداية التطوير عندما لا يوجد كود حتى الآن.

إخراج

WSDL غير مناسب بسبب تكراره.

Apache Thrift غريب للغاية ويصعب تعلمه.

يتطلب GRPC صافي Core 3.0 و net Standard 2.1. في وقت التحليل ، تم استخدام صافي Core 2.2 و net Standard 2.0. لا يوجد دعم GRPC في المتصفح خارج الصندوق ، مطلوب حل إضافي. يستخدم GRPC تسلسل ثنائي Protobuf و HTTP / 2. وبسبب هذا ، فإن نطاق الأدوات المساعدة لاختبار واجهات برمجة التطبيقات مثل Postman وما إلى ذلك ، يضيق. قد يتطلب اختبار الحمل من خلال بعض JMeter جهدًا إضافيًا. غير مناسب ، التحول إلى GRPC يتطلب الكثير من الموارد.

لا يتطلب OpenAPI تحديثات إضافية. يأسر وفرة من الأدوات التي تدعم العمل مع REST وهذه المواصفات. نختارها.

أدوات للعمل مع OpenAPI


يوضح الجدول مقارنة بين الأدوات للعمل مع OpenAPI.
أدواتاختالNSwagأدوات Openapitools
إصدارات المواصفات المدعومةيمكن إنشاء مواصفات بتنسيق OpenApi v2 و v3
كود الدعم الأوليوجديوجدلا
لغات الخادم المدعومةلاج #كثيرا من
لغات العملاء المدعومةلاC # ، TypeScript ، AngularJS ، Angular (v2 +) ، window.fetch APIكثيرا من
إعدادات الجيللايوجديوجد
رأيحزمة نقتحزمة Nuget + فائدة منفصلةفائدة منفصلة
استنتاج

Swashbuckle غير مناسب ، لأن يسمح لك بالحصول على المواصفات فقط. لإنشاء رمز العميل ، تحتاج إلى استخدام حل إضافي.

OpenApiTools هي أداة مثيرة للاهتمام مع مجموعة من الإعدادات ، ولكنها لا تدعم التعليمات البرمجية أولاً. ميزته هي القدرة على توليد كود الخادم بعدة لغات.

NSwag مريحة لأنها حزمة Nuget. من السهل الاتصال عند بناء مشروع. يدعم كل ما نحتاجه: نهج الشفرة الأولى وإنشاء رمز العميل في c #. نختارها.

مكان ترتيب العقود. كيفية الوصول إلى الخدمات للعقود


فيما يلي حلول لتنظيم تخزين العقد. يتم سرد الحلول من أجل زيادة التعقيد.

  • مجلد مشروع خدمة مقدم الخدمة هو الخيار الأسهل. إذا كنت بحاجة إلى تشغيل النهج ، فاختره.
  • يعد المجلد المشترك خيارًا صالحًا إذا كانت المشاريع المطلوبة في نفس المستودع. على المدى الطويل ، سيكون من الصعب الحفاظ على سلامة العقود في المجلد. قد يتطلب هذا أداة إضافية لحساب الإصدارات المختلفة من العقود ، وما إلى ذلك.
  • مستودع منفصل للمواصفات - إذا كانت المشاريع في مستودعات مختلفة ، فيجب وضع العقود في مكان عام. العيوب هي نفسها المجلد المشترك.
  • من خلال واجهة برمجة تطبيقات الخدمة (swagger.ui ، swaggerhub) - خدمة منفصلة تتعامل مع إدارة المواصفات.

قررنا استخدام أبسط خيار - لتخزين العقود في مجلد المشروع الخاص بمزود الخدمة. هذا يكفي بالنسبة لنا في هذه المرحلة ، فلماذا تدفع أكثر؟

في أي نقطة تولد


الآن أنت بحاجة إلى أن تقرر عند أي نقطة لتنفيذ إنشاء التعليمات البرمجية.
إذا تم تقاسم العقود ، يمكن لخدمات المستهلك الحصول على العقود وإنشاء رمز نفسها إذا لزم الأمر.

قررنا وضع العقود في المجلد مع مشروع مزود الخدمة. وهذا يعني أنه يمكن إجراء التوليد بعد تجميع مشروع خدمة المورد نفسه.

مكان وضع رمز العميل


سيتم إنشاء رمز العميل عن طريق العقد. يبقى لمعرفة مكان وضعها.
يبدو أنها فكرة جيدة لوضع رمز العميل في مشروع StorageServiceClientProxy منفصل. سيتمكن كل مشروع من توصيل هذا التجميع.

فوائد هذا الحل:

  • رمز العميل قريب من خدمته ومحدّث باستمرار ؛
  • يمكن للمستهلكين استخدام الارتباط بالمشروع داخل مستودع واحد.

سلبيات:

  • لن يعمل إذا كنت بحاجة إلى إنشاء عميل في جزء آخر من النظام ، على سبيل المثال ، مستودع مختلف. يتم حلها باستخدام مجلد مشترك على الأقل للعقود ؛
  • يجب أن يكتب المستهلكون بنفس اللغة. إذا كنت بحاجة إلى عميل بلغة أخرى ، فأنت بحاجة إلى استخدام OpenApiTools.

نحن نربط NSwag


سمات المراقب


تحتاج إلى إخبار NSwag بكيفية إنشاء المواصفات الصحيحة لوحدات التحكم الخاصة بنا.

للقيام بذلك ، تحتاج إلى ترتيب السمات.

[Microsoft.AspNetCore.Mvc.Routing.Route("[controller]")]  //  url
[Microsoft.AspNetCore.Mvc.ApiController] //     
public class DescriptionController : ControllerBase {
[NSwag.Annotations.OpenApiOperation("GetDescription")] //    
[Microsoft.AspNetCore.Mvc.ProducesResponseType(typeof(ConversionDescription), 200)] //    200  
[Microsoft.AspNetCore.Mvc.ProducesResponseType(401)] //    401
[Microsoft.AspNetCore.Mvc.ProducesResponseType(403)] //    403
[Microsoft.AspNetCore.Mvc.HttpGet("{pluginName}/{binaryDataId}")] //  url
public ActionResult<ConversionDescription> GetDescription(string pluginName, Guid binaryDataId) { 
 // ... 
}

افتراضيًا ، لا يمكن لـ NSwag إنشاء المواصفات الصحيحة للتطبيق / دفق الثماني من نوع MIME. على سبيل المثال ، يمكن أن يحدث هذا عند نقل الملفات. لإصلاح ذلك ، تحتاج إلى كتابة السمة والمعالج لإنشاء المواصفات.

[Microsoft.AspNetCore.Mvc.Route("[controller]")]
[Microsoft.AspNetCore.Mvc.ApiController]
public class FileController : ControllerBase {
[NSwag.Annotations.OpenApiOperation("SaveFile")]
[Microsoft.AspNetCore.Mvc.ProducesResponseType(401)]
[Microsoft.AspNetCore.Mvc.ProducesResponseType(403)]
[Microsoft.AspNetCore.Mvc.HttpPost("{pluginName}/{binaryDataId}/{fileName}")]
[OurNamespace.FileUploadOperation] //  
public async Task SaveFile() { // ... }

معالج لتوليد المواصفات لعمليات الملف


الفكرة هي أنه يمكنك كتابة السمة والمعالج الخاص بك للتعامل مع هذه السمة.

نعلق السمة على وحدة التحكم ، وعندما تلتقي بها NSwag ، ستعالجها باستخدام معالجنا.

لتنفيذ ذلك ، توفر NSwag فئتي OpenApiOperationProcessorAttribute و IOperationProcessor.

في مشروعنا جعلنا ورثتنا:

  • FileUploadOperationAttribute: OpenApiOperationProcessorAttribute
  • FileUploadOperationProcessor: IOperationProcessor

اقرأ المزيد حول استخدام المعالجات هنا.

تكوين NSwag للمواصفات وإنشاء التعليمات البرمجية


في التكوين 3 أقسام رئيسية:

  • وقت التشغيل - يحدد وقت تشغيل .net. على سبيل المثال ، NetCore22 ؛
  • documentGenerator - يصف كيفية إنشاء المواصفات ؛
  • codeGenerators - يحدد كيفية إنشاء التعليمات البرمجية وفقًا للمواصفات.

تحتوي NSwag على مجموعة من الإعدادات ، وهي مربكة في البداية.

للراحة ، يمكنك استخدام استوديو NSwag. باستخدامه ، يمكنك أن ترى في الوقت الحقيقي كيف تؤثر الإعدادات المختلفة على نتيجة إنشاء التعليمات البرمجية أو المواصفات. بعد ذلك ، حدد الإعدادات المحددة يدويًا في ملف التكوين.

اقرأ المزيد حول إعدادات التكوين هنا

نقوم بإنشاء المواصفات ورمز العميل عند تجميع مشروع مزود الخدمة


لذلك بعد تجميع مشروع مقدم الخدمة ، يتم إنشاء المواصفات والرمز ، قم بما يلي:

  1. أنشأنا مشروع WebApi للعميل.
  2. كتبنا تهيئة لـ Nswag CLI - Nswag.json (الموضحة في القسم السابق).
  3. كتبنا هدف PostBuild داخل مشروع مقدم خدمة csproj.

<Target Name="GenerateWebApiProxyClient“ AfterTargets="PostBuildEvent">
<Exec Command="$(NSwagExe_Core22) run nswag.json”/>

  • $ (NSwagExe_Core22) تشغيل nswag.json - تشغيل الأداة المساعدة NSwag ضمن .bet runtine netCore 2.2 مع تكوين nswag.json

يقوم الهدف بما يلي:

  1. تقوم NSwag بإنشاء مواصفات من تجميع خدمة البائع.
  2. تقوم NSwag بإنشاء رمز العميل وفقًا للمواصفات.

بعد كل تجميع لمشروع مقدم الخدمة ، يتم تحديث مشروع العميل.
مشروع العميل ومقدم الخدمة ضمن نفس الحل.
يتم التجميع كجزء من الحل. تم تكوين الحل الذي يجب تجميع مشروع العميل بعد مشروع خدمة المورد.

كما تسمح لك NSwag بتخصيص المواصفات / إنشاء التعليمات البرمجية بشكل حتمي من خلال واجهة برمجة التطبيقات للبرنامج.

كيفية إضافة دعم لـ JWT


نحن بحاجة لحماية خدمتنا من الطلبات غير المصرح بها. لهذا ، سنستخدم الرموز المميزة لـ JWT. يجب إرسالها في رؤوس كل طلب HTTP حتى يتمكن مزود الخدمة من التحقق منها وتحديد ما إذا كان سيتم تنفيذ الطلب أم لا.

مزيد من المعلومات حول JWT هنا jwt.io .

تتلخص المهمة في الحاجة إلى تعديل رؤوس طلب HTTP الصادر.
للقيام بذلك ، يمكن لمولد رمز NSwag إنشاء نقطة امتداد - أسلوب CreateHttpRequestMessageAsync. يوجد داخل هذه الطريقة وصول إلى طلب HTTP قبل إرساله.

مثال على الرمز
protected Task<HttpRequestMessage> CreateHttpRequestMessageAsync(CancellationToken cancellationToken) {
      var message = new HttpRequestMessage();

      if (!string.IsNullOrWhiteSpace(this.AuthorizationToken)) {
        message.Headers.Authorization =
          new System.Net.Http.Headers.AuthenticationHeaderValue(BearerScheme, this.AuthorizationToken);
      }

      return Task.FromResult(message);
    }


استنتاج


اخترنا الخيار مع OpenAPI ، لأنه إنه سهل التنفيذ ، كما أن أدوات العمل مع هذه المواصفات متطورة للغاية.

استنتاجات بشأن OpenAPI و GRPC:

OpenAPI

  • المواصفات مطولة ؛
  • , ;
  • ;
  • .

GRPC

  • , URL, HTTP ..;
  • OpenAPI;
  • ;
  • ;
  • HTTP/2.

وبالتالي ، تلقينا مواصفات استنادًا إلى الرمز المكتوب بالفعل لوحدات التحكم. للقيام بذلك ، كان من الضروري تعليق السمات الخاصة على وحدات التحكم.

بعد ذلك ، بناءً على المواصفات المستلمة ، قمنا بتطبيق إنشاء رمز العميل. الآن لا نحتاج إلى تحديث رمز العميل يدويًا.

أجريت دراسات في مجال عقود الإصدار والاختبار. ومع ذلك ، لم يكن من الممكن اختبار كل شيء في الممارسة العملية بسبب نقص الموارد.

إصدار العقود العامة


لماذا اصدار العقود العامة؟


بعد التغييرات في مزودي الخدمة ، يجب أن يظل النظام بأكمله في حالة تشغيلية متسقة.

يجب تجنب التغييرات العاجلة في واجهة برمجة التطبيقات العامة حتى لا يتم كسر العملاء.

خيارات الحل


بدون اصدار عقود عامة


يقوم فريق مقدم الخدمة نفسه بإصلاح خدمات المستهلك.



لن ينجح هذا النهج إذا لم يتمكن فريق مقدم الخدمة من الوصول إلى مستودعات خدمة العملاء أو يفتقر إلى الكفاءات. إذا لم تكن هناك مثل هذه المشاكل ، فيمكنك الاستغناء عنها.



استخدام إصدار العقود العامة


يترك فريق مقدم الخدمة النسخة السابقة من العقود.



لا يحتوي هذا النهج على عيوب النهج السابق ، ولكنه يضيف صعوبات أخرى.
عليك أن تقرر ما يلي:

  • أي أداة تستخدم ؛
  • متى يتم تقديم إصدار جديد ؛
  • كم من الوقت للحفاظ على الإصدارات القديمة.

الأداة التي تستخدم


يوضح الجدول ميزات OpeanAPI و GRPC المرتبطة بالإصدار.
gRPCOpenapi
سمة الإصدارعلى مستوى protobuf ، توجد حزمة سمات [packageName].على مستوى المواصفات ، هناك سمات basePath (لعنوان URL) والإصدار
سمة موقوفة للطرقنعم ، ولكن لم يتم أخذها في الاعتبار من قبل منشئ الشفرات تحت C #نعم ، تم وضع علامة عليه على أنه قديم
، NSwag غير مدعوم بالرمز أولاً ، تحتاج إلى كتابة المعالج الخاص بك
سمة موقوفة للمعلماتتم وضع علامة على أنها قديمةنعم ، تم وضع علامة عليه على أنه قديم
، NSwag غير مدعوم بالرمز أولاً ، تحتاج إلى كتابة المعالج الخاص بك
يعني الاستنكار أن واجهة برمجة التطبيقات هذه لم تعد تستحق الاستخدام.

تدعم كلتا الأداتين الإصدار والسمات الموقوفة.

إذا كنت تستخدم OpenAPI وأسلوب الكود الأول ، فستحتاج مرة أخرى إلى كتابة المعالجات لإنشاء المواصفات الصحيحة.

متى يتم تقديم نسخة جديدة


يجب تقديم الإصدار الجديد عندما لا تحافظ التغييرات على العقود على التوافق العكسي.

كيفية التحقق من أن التغييرات تنتهك التوافق بين الإصدارات الجديدة والقديمة من العقود؟


كم من الوقت للحفاظ على الإصدارات


لا توجد إجابة صحيحة لهذا السؤال.

لإزالة دعم الإصدار القديم ، تحتاج إلى معرفة من يستخدم خدمتك.

سيكون سيئًا إذا تمت إزالة الإصدار ، ويستخدمه شخص آخر. من الصعب بشكل خاص إذا كنت لا تتحكم في عملائك.

إذن ما الذي يمكن عمله في هذه الحالة؟

  • إبلاغ العملاء بأن الإصدار القديم لن يكون مدعومًا بعد الآن. في هذه الحالة ، قد نفقد دخل العميل ؛
  • دعم المجموعة الكاملة من الإصدارات. تكلفة دعم البرمجيات آخذة في الازدياد ؛
  • للإجابة على هذا السؤال ، عليك أن تسأل الشركة - هل يتجاوز الدخل من العملاء القدامى تكلفة دعم الإصدارات القديمة من البرنامج؟ هل يمكن أن يكون أكثر ربحية أن تطلب من العملاء الترقية؟

النصيحة الوحيدة في هذه الحالة هي إيلاء المزيد من الاهتمام للعقود العامة من أجل تقليل وتيرة التغييرات.

إذا تم استخدام العقود العامة في نظام مغلق ، يمكنك استخدام نهج CDC. حتى نتمكن من معرفة متى توقف العملاء عن استخدام الإصدارات القديمة من البرنامج. بعد ذلك ، يمكنك إزالة دعم الإصدار القديم.

استنتاج


استخدم الإصدار فقط إذا كنت لا تستطيع الاستغناء عنه. إذا قررت استخدام الإصدار ، عند تصميم العقود ، ضع في الاعتبار توافق الإصدار. يجب تحقيق التوازن بين تكلفة دعم الإصدارات القديمة والفوائد التي تقدمها. من المفيد أيضًا تحديد متى يمكنك التوقف عن دعم الإصدار القديم.

اختبار العقود و مراكز السيطرة على الأمراض


هذا القسم مضاء سطحيًا ، مثل لا توجد شروط مسبقة جدية لتطبيق هذا النهج.

العقود الموجهة للمستهلكين (CDC)


إن CDC هي الإجابة على السؤال حول كيفية التأكد من أن المورد والمستهلك يستخدمان نفس العقود. هذه هي نوع من اختبارات التكامل تهدف إلى التحقق من العقود.
الفكرة كالتالي:

  1. يصف المستهلك العقد.
  2. ينفذ المورد هذا العقد في المنزل.
  3. يستخدم هذا العقد في عملية CI لدى المستهلك والمورد. إذا تم انتهاك العملية ، فقد توقف شخص عن الامتثال للعقد.

حلف


PACT هي أداة تنفذ هذه الفكرة.

  1. يكتب المستهلك الاختبارات باستخدام مكتبة PACT.
  2. يتم تحويل هذه الاختبارات إلى ملف - قطعة أثرية. أنه يحتوي على معلومات حول العقود.
  3. يستخدم الموفر والمستهلك ملف الاتفاقية لإجراء الاختبارات.

أثناء اختبارات العملاء ، يتم إنشاء كعب مزود ، وأثناء اختبارات المورد ، يتم إنشاء كعب عميل. يستخدم كلا من هذه بذرة ملف ميثاق.

يمكن تحقيق سلوك إنشاء كعب روتين مماثل من خلال Swagger Mock Validator bitbucket.org/atlassian/swagger-mock-validator/src/master .

روابط مفيدة حول ميثاق





كيف يمكن تضمين CDC في CI


  • نشر Pact + Pact broker بنفسك ؛
  • شراء حل جاهز Pact Flow SaaS.

استنتاج


هناك حاجة إلى ميثاق لضمان الامتثال للعقد. سيظهر ذلك عندما تنتهك التغييرات في العقود توقعات خدمات المستهلكين.

هذه الأداة مناسبة عندما يتكيف المورد مع العميل - العميل. هذا ممكن فقط داخل نظام معزول.

إذا كنت تقدم خدمة للعالم الخارجي ولا تعرف من هم عملاؤك ، فإن Pact ليست لك.

All Articles