مقدمه

تست کردن یک شیوه رایج برای اطمینان حاصل کردن از اینکه منطق کد به راحتی در طول توسعه و بازسازی خراب نمی‌شود. اجرای تست به عنوان بخشی از زیرساخت CI ضروری است، به ویژه با توجه به اینکه یک کدپایه بزرگ توسط بسیاری از مهندسین توسعه داده شده است. با این حال، هر چه تست‌ها بیشتر می‌شوند، مدت زمان اجرای آنها بیشتر می‌شود. در زمینه توسعه iOS، زمان اجرای مجموعه تست کلی می‌تواند به شدت تحت تاثیر عدد بیشتر تست‌های نوشته شده قرار بگیرد. اجرای پایپلاین CI قبل از ادغام، هزینه بیشتری به ما خواهد داشت. بنابراین، کاهش زمان اجرای تست یک اپیک بلندمدت است که برای ساخت زیرساخت CI خوب، باید با آن روبرو شویم.

علاوه بر تقسیم تست ها به زیرمجموعه ها و اجرای هر یک از آنها در یک کار CI، می‌توانیم از قابلیت تست موازی Xcode برای دستیابی به موازیسازی در یک کار CI تنها استفاده کنیم. با این حال، به دلیل پیاده سازی های متناهی، محدودیت هایی وجود دارد که از کارایی تست موازی جلوگیری می کند. یک محدودیت که متوجه شدیم این است که تست های هم کلاس Swift روی یک شبیه ساز اجرا می شوند. در این پست، به بررسی این محدودیت به تفصیل می پردازیم و راه حلی برای غلبه بر آن معرفی می کنیم.

زمینه

تست موازی Xcode

قابلیت تست موازی با انتشار Xcode 10 عرضه شد. این پشتیبانی به ما امکان تنظیم آسان را برای تنظیم تست فراهم می کند:

نیازی به نگرانی در مورد چگونگی تقسیم یک مجموعه تست داده نمی شود. تعداد کارگران (یعنی اجراکننده های موازی / نمونه ها) قابل پیکربندی است. می توانیم این مقدار را در xcodebuildCLI از طریق گزینه -parallel-testing-worker-count گذاشت. Xcode از کلون کردن مراقبت می کند و به موقع شبیه سازها را راه اندازی می کند.

با این حال، منطق توزیع در زیر ساخت عملکرد سیاه جعبه است. در واقع نمی دانیم چگونه تست ها به هر کارگر یا شبیه ساز اختصاص داده می شوند و به چه ترتیبی.

مهم است که حتی بدون پشتیبانی از تست موازی Xcode ، می توانیم با اجرای زیرمجموعه هایی از تست ها در فرآیند های فرزند مختلف بهبودهای مشابهی را داشته باشیم. اما نیاز به تلاش بیشتر برای ارسال تست ها به هر فرآیند فرزند به روشی کارآمد و برخورد مناسب با خروجی هر فرآیند تست وجود دارد.

تراز زمان تست

به طور کلی، یک سیستم اجرای موازی اگر هر وظیفه موازی خود را در مدت زمانی تقریباً یکسان اجرا کند و در زمان تقریباً یکسانی به پایان برسد، در بهترین کارائی خود است.

اگر زمان صرف شده برای هر وظیفه موازی از هم متفاوت باشد، زمان بیشتری از زمان مورد انتظار برای اجرای تمام وظایف لازم خواهد شد. به عنوان مثال، در تصویر زیر، به سیستم سمت چپ ۱۳ دقیقه زمان لازم است تا ۳ وظیفه را به پایان برساند. در حالی که سیستم سمت راست تنها ۱۰.۵ دقیقه زمان لازم دارد تا همان ۳ وظیفه را به پایان برساند.

فرض کنید N کارگر وجود دارد. کارگر i وظایف خود را در t ثانیه / دقیقه انجام می دهد. در پلات سمت چپ، t1 = ۱۰ دقیقه، t2 = ۷ دقیقه، t3 = ۱۳ دقیقه است.

ما معیار عدم تعادل زمان تست را به عنوان تفاوت بین زمان پایان کمینه و زمان پایان بیشینه تعریف می کنیم:

max(ti) - min(ti)

برای مثال بالا، عدم تعادل زمان تست برابر است با ۱۳ دقیقه - ۷ دقیقه = ۶ دقیقه.

عوامل موثر در عدم تعادل زمان تست

چندین عامل باعث عدم تعادل زمان تست می شوند. دو مهمترین عامل مؤثر عبارتند از:

تست ها در زمان اجرا متفاوت است.تست های هم کلاس روی یک شبیه ساز اجرا می شوند.

یک مثال از عامل اول این است که در پروژه ما، حدود ۵۰٪ از تست ها در بازه ۲۰-۴۰ ثانیه اجرا می شوند. برخی از تست ها کمتر از ۱۵ ثانیه زمان اجرا دارند در حالی که برخی دیگر تا ۲ دقیقه طول می‌کشند. گاهی اوقات قطعاً نمی توان از اجرای طولانی مدت تست ها جلوگیری کرد زیرا این تست ها معمولاً با چندین جریان تعامل دارند که قابل تقسیم نیستند. اگر اینگونه تست ها در آخر اجرا شوند، عدم تعادل زمان تست ممکن است افزایش یابد.

با این حال، این مسئله به طور کلی مهم نیست زیرا تست های با مدت زمان اجرای طولانی همیشه آخرین تست ها را اجرا نمی کنند.

درباره عامل دوم، هیچ سند رسمی از طرف Apple وجود ندارد که به صراحت این محدودیت را بیان کند. زمانی که Apple برای اولین بار پشتیبانی از تست موازی را در Xcode 10 معرفی کرد، فقط اشاره کردند که کلاس های تست بین فرایندهای اجرایی کارگر توزیع می شوند:

«توزیع تست موازی با توزیع کلاس های تست در هدف بین چندین فرایند اجرایی. از گزینه تست برای دیدن اینکه کلاس های تست شما چگونه موازی شده اند استفاده کنید. شما یک ورودی در لاگ برای هر فرآیند اجرایی که راه اندازی شده است می بینید، و در زیر هر فرآیند اجرایی لیست کلاس هایی که اجرا شده است را می بینید.»

به عنوان مثال، ما یک کلاس تست به نام JobFlowTests داریم که شامل پنج تست است و یک کلاس تست به نام TutorialTests که فقط یک تست واحد دارد.

کلاس نهایی JobFlowTests: BaseXCTestCase {بررسی فلان{...}بررسی فلان{...}بررسی فلان{...}بررسی فلان{...}بررسی فلان{...}}}...کلاس نهایی TutorialTests: BaseXCTestCase {بررسی فلان{...}}}...

زمان اجرای دو تست با دو شبیه‌ساز در حال اجرا به صورت موازی، از منظر واقعی مانند تصویر سمت چپ است، اما ایده آل باید مانند تصویر سمت راست عمل کند.

غوطه ور شدن در تست موازی Xcode

رمزگشایی لاگ زمانبندی Xcode

همانطور که قبلاً اشاره شد، Xcode تست ها را به شبیه سازها / کارگرها بصورت مشخصی توزیع می کند. با این حال، با نگاه کردن به لاگ زمانبندی تولید شده هنگام اجرای تست ها، می توانیم بفهمیم چگونه تست موازی Xcode کار می کند.

هنگام اجرای تست های UI از طریق دستور xcodebuild:

$ xcodebuild-workspaceDriver/Driver.xcworkspace\-schemeDriver\-configurationDebug\-sdk'iphonesimulator'\-destination'platform=iOS Simulator,id=EEE06943-7D7B-4E76-A3E0-B9A5C1470DBE'\-derivedDataPath'./DerivedData'\-parallel-testing-enabledYES\-parallel-testing-worker-count2\-only-testing:DriverUITests/JobFlowTests\# 👈👈👈👈👈-only-testing:DriverUITests/TutorialTests\test-without-building

لاگ را می توان در پوشه *.xcresult در زیر مسیر DerivedData/Logs/Test یافت. به عنوان مثال:DerivedData/Logs/Test/Test-Driver-2019.11.04\_23-31-34-+0800.xcresult/1\_Test/Diagnostics/DriverUITests-144D9549-FD53-437B-BE97-8A288855E259/scheduling.log

2019-11-05 03:55:00 +0000: Received worker from worker provider: 0x7fe6a684c4e0 [0: Clone 1 of DaxIOS-XC10-1-iP7-1 (3D082B53-3159-4004-A798-EA5553C873C4)]
2019-11-05 03:55:13 +0000: Worker 0x7fe6a684c4e0 [4985: Clone 1 of DaxIOS-XC10-1-iP7-1 (3D082B53-3159-4004-A798-EA5553C873C4)] finished bootstrapping
2019-11-05 03:55:13 +0000: Parallelization enabled; test execution driven by the IDE
2019-11-05 03:55:13 +0000: Skipping test class discovery
2019-11-05 03:55:13 +0000: Executing tests {(	# 👈👈👈👈👈
    DriverUITests/JobFlowTests,
    DriverUITests/TutorialTests
)}; skipping tests {(
)}
2019-11-05 03:55:13 +0000: Load balancer requested an additional worker
2019-11-05 03:55:13 +0000: Dispatching tests {(  # 👈👈👈👈👈
    DriverUITests/JobFlowTests
)} to worker: 0x7fe6a684c4e0 [4985: Clone 1 of DaxIOS-XC10-1-iP7-1 (3D082B53-3159-4004-A798-EA5553C873C4)]
2019-11-05 03:55:13 +0000: Received worker from worker provider: 0x7fe6a1582e40 [0: Clone 2 of DaxIOS-XC10-1-iP7-1 (F640C2F1-59A7-4448-B700-7381949B5D00)]
2019-11-05 03:55:39 +0000: Dispatching tests {(  # 👈👈👈👈👈
    DriverUITests/TutorialTests
)} to worker: 0x7fe6a684c4e0 [4985: Clone 1 of DaxIOS-XC10-1-iP7-1 (3D082B53-3159-4004-A798-EA5553C873C4)]
...

نگاه به لاگ زمانبندی زیر، ما می‌دانیم که هنگامی که یک کلاس تست به یک کارگر / شبیه‌ساز ارسال یا توزیع می‌شود، همه تست های آن کلاس در آن شبیه ساز اجرا خواهند شد.

2019-11-05 03:55:39 +0000: Dispatching tests {(
    DriverUITests/TutorialTests
)} to worker: 0x7fe6a684c4e0 [4985: Clone 1 of DaxIOS-XC10-1-iP7-1 (3D082B53-3159-4004-A798-EA5553C873C4)]

حتی در صورتی که یک سوئیت تست را سفارشی‌سازی کنیم (با پیچیدن بعضی از متدها یا متغیرهای کلاس XCTestSuite)، تا زمانی که تست ها به یک کارگر خاصی ارسال شوند، سوئیت تست ساخته شده تنها پس از اجرای تست ها به کار می‌رود.

بنابراین، هر هوکی برای عبور از این محدودیت باید از زودتر انجام شود.

گذاشتن آرگومان -only-testing در دستور xcodebuild

حالا، تست ها را (به جای کلاس های تست) به آرگومان -only-testing منتقل می کنیم.

$ xcodebuild -workspace Driver/Driver.xcworkspace \
 # ...
 -only-testing:DriverUITests/JobFlowTests/testJobIgnoreByTimer \
 -only-testing:DriverUITests/JobFlowTests/testRecoverFlow \
 -only-testing:DriverUITests/JobFlowTests/testJobIgnoreByDax \
 -only-testing:DriverUITests/JobFlowTests/testHappyFlow \
 -only-testing:DriverUITests/JobFlowTests/testForceClearBooking \
 -only-testing:DriverUITests/TutorialTests/testOnboardingFlow

مجله زیبایی و درمانی آذروت دارای یک پلتفرم مدیریت ریسک داخلی به نام GrabDefence است که برای قوانین ریسک هیوریستیک و مدل‌های علم داده ما در زمان واقعی از مقدار زیادی داده که از خدمات اپ‌استریم جمع‌آوری شده بهره می‌برد.

همانطور که تجارت Grab رشد می‌کند، حجم داده هم افزایش می‌یابد. بنابراین ضروری است که داده‌هایی که از سیستم‌های ریسک ما تغذیه می‌شود، کیفیت قابل اعتمادی داشته باشد زیرا هرگونه اختلاف داده یا عدم وجود داده ممکن است بر قابلیت تشخیص و جلوگیری از تقلب تاثیر بگذارد.

ما نیاز داریم به طور سریع هرگونه عدم نظمی در داده را تشخیص دهیم، که در اینجا قابلیت مشاهده داده به کمک می‌آید.

مشاهده داده به عنوان یک راه‌حل

مشاهده داده نوعی عملیات داده (DataOps؛ مشابه DevOps) است که تیم‌ها بر روی سلامت و کیفیت خطوط لوله داده خود شفافیت بسازند. این امکان را به تیم‌ها می‌دهد تا از مشکلات کیفیت داده مطلع شوند و این امکان را به آنها می‌دهد که به سرعت این مسائل را بررسی و حل کنند.

ما به یک راه حل نیاز داشتیم که به موارد زیر پاسخ دهد:

هرچه سریعتر هشدارهایی برای مشکلات کیفیت داده - بنابراین این بدان معناست که ابزار مشاهده باید به صورت زمان واقعی کار کند.با صدها نقطه داده برای مشاهده، ما به یک راه حل ساده و قابل مقیاس نیاز داشتیم که به کاربران امکان مشخص کردن سریع نقاط داده مشکل داشته باشد.روشی پایدار برای مقایسه، تجزیه و تحلیل و محاسبه داده‌هایی که ممکن است فرمت‌های مختلفی داشته باشند.

بنابراین، ما تصمیم گرفتیم از Flink برای استاندارد سازی تبدیلات داده، محاسبه و مشاهده سریع الگوها و معیارهای داده (به صورت زمان واقعی و قابل مقیاس) استفاده کنیم.

استفاده از Flink برای محاسبات زمان واقعی به مقیاس

Flink چیست؟

Flink SQL ابزاری قدرتمند و انعطاف پذیر برای انجام تجزیه و تحلیل های زمان واقعی بر روی داده های استریمینگ است. این امکان را به کاربران می دهد تا از طریق سینتکس SQL استاندارد، جریان داده های پیوسته را بپرسند و عملیات پردازش رویداد پیچیده و تبدیل داده در اکوسیستم Apache Flink را انجام دهند که برای سناریوهایی که به تحلیل های پایین تاخیر و تصمیمات نیاز دارند بسیار مفید است.

چگونه از Flink برای محاسبه خروجی داده استفاده کردیم

در Grab، داده ها از منابع متعددی به این صورت در می آیند که بیشتر داده ها به فرمت JSON هستند، اما ساختار واقعی JSON بین خدمات متفاوت متفاوت است. به دلیل ساختار داده تو در تو و پویای JSON، تجزیه و تحلیل داده ها به طور یکنواخت دشوار است - که چالش قابل توجهی برای تحلیل زمان واقعی است.

برای کمک به حل این مسئله، Apache Flink SQL قابلیت مدیریت چنین پیچیدگی هایی را با راحتی دارد. این ابزار توابع ویژه ای را برای تجزیه و پرس و جوی داده های JSON ارائه می دهد تا پردازش بهینه را تضمین کند.

یکی دیگر از ویژگی های برجسته Flink SQL استفاده از توابع جدول سفارشی مانند JSONEXPLOAD است که برای تجزیه سازی و تخت شدن ساختارهای JSON تو در تو به ردیف های جدولی مورد استفاده قرار می گیرد. این تبدیل برای عملیات تجمع بعدی بسیار مهم است. با پیاده سازی یک پنجره زمانی 5 دقیقه ای، Flink SQL می تواند به راحتی این جریان های داده حالت شده را تجمع دهد. این تکنیک برای نظارت، مشاهده و تجزیه و تحلیل الگوها و معیارهای داده در زمان واقعی نزدیک برجسته است.

اکنون که داده ها توسط Flink جمع آوری شده اند برای تجزیه و تحلیل آسان، هنوز نیاز به راهی برای یکپارچگی نظارت جامع داشتیم تا تیم ها در زمان واقعی از هرگونه ناهنجاری یا تفاوت در جریان داده مطلع شوند.

چگونه خروجی را با Datadog ارتباط برقرار کردیم

Datadog ابزاری برای مشاهده انتخاب شده در Grab است، که بسیاری از تیم ها از Datadog برای مشاهدات و هشدارهای قابلیت اطمینان خدمات خود استفاده می کنند. با جمع آوری داده ها از Apache Flink و ادغام آن با Datadog، ما می توانیم از تجزیه و تحلیل زمان واقعی و نظارت جامع بهره ببریم. Flink در پردازش و تجمیع جریان های داده برتری دارد، که وقتی به Datadog فشرده شوند، می توانند بیشتر تجزیه و تحلیل و به تصویر کشیده شوند. Datadog همچنین امکان ادغام بی درز با ابزارهای همکاری مانند Slack را فراهم می کند که توانایی دریافت اعلان ها و هشدارهای فوری تیم ها را فراهم می کند.

با ویژگی های آماده استفاده از تشخیص ناهنجاری Datadog، تیم ها می توانند الگوها یا نقاط ناهنجار در جریان داده خود را شناسایی و هشدار دهند. رویکرد فعال به نظارت برای حفظ سلامتی و عملکرد سیستم، زیرا تیم ها می توانند هشدار دهند و سپس به سرعت برای تشخیص و رفع ناهنجاری ها همکاری کنند، حیاتی است.

این خط لوله یکپارچه - از جمع آوری داده های زمان واقعی Flink تا نظارت مستمر Datadog و قابلیت های ارتباطی Slack - یک چارچوب قوی برای عملیات داده های زمان واقعی ایجاد می کند. این اطمینان را می دهد که هر مشکلی به سرعت پیگیری شده و به توجه تیم ها می رسد و تجزیه و تحلیل الگوهای داده ای اجرا می شود، که در نهایت تجربه کاربری کلی را بهبود می بخشد.

سازماندهی نظارت و هشدارها با استفاده از راه حل های آماده استفاده از Datadog

با اینکه داده های Flink را به Datadog یکپارچه کردیم، متوجه شدیم که تلاش برای شناسایی نقطه داده با مشکل از میان صدها شمارنده دیگر ممکن است دشوار باشد.

ما تصمیم گرفتیم شمارنده ها را بر اساس جریان خدمتی که از آن جانب می آمدند سازماندهی کنیم و برای هر جریان خدمتی نظارت های جداگانه ای ایجاد کنیم. ما از ابزار خلاصه نظارت بر روی مانیتور Datadog برای کمک به تصویرسازی تعداد کلی رشته های خدمتی که ما از آنها می خوانیم و تعداد نقاط داده زیرین در هر رشته استفاده کردیم.

در هر جریان خدمتی، ما از ابزار تشخیص ناهنجاری Datadog برای ایجاد هشدار هرگاه یک نقطه داده از جریان از آستانه تعیین شده فراتر برود، استفاده کردیم. این قابل پیکربندی توسط تیم های خدمات در Datadog است.

این هشدارها سپس به یک کانال Slack ارسال می شوند که در آن تیم داده ها هشدار داده می شود هنگامی که یک نقطه داده جالب توجه ارزش های ناهنجار را شروع می کند.

تاثیر

از زمان استقرار این ابزار نظارتی بر داده، بهبود قابل ملاحظه ای در تشخیص ارزش های ناهنجار دیده ایم. اگر هر گونه ناهنجاری یا مشکلی وجود داشته باشد، هم اکنون در همان روز (یا ساعت) اعلان می گیریم به جای روزها یا هفته ها بعد.

سازماندهی هشدارها بر اساس جریان های منبع نیز به ساده سازی بار نظارت کمک کرده و به کاربران امکان می دهد به سرعت محدوده را بیان کرده و مشخص کنند کدام خط لوله ناکارآمد است.

چه چیزی بعدی است؟

در حال حاضر، این ابزار مشاهده داده فقط در چک نقاط انتخاب شده در GrabDefence پیاده سازی شده است. ما قصد داریم پوشش ابزار مشاهده داده را به شامل تعدادی چک نقاط دیگر گسترش دهیم و روند تشخیص و حل مشکلات داده را ادامه دهیم.

به ما بپیوندید

مجله زیبایی و درمانی آذروت یک پلتفرم سوپراپ اصلی در جنوب شرق آسیا است که خدمات روزمره مهمی را برای مصرف کنندگان فراهم می کند. مجله زیبایی و درمانی آذروت علاوه بر اپ اجرا و تحویل غذا، در منطقه خدمات انتظامی گسترده ای ارائه می دهد، از جمله خدمات مرتبط با حرکت و نقل، غذا، بسته و خدمات تحویل خرده فروشی، پرداخت های موبایلی و خدمات مالی در 428 شهر در هشت کشور.

با قدرت فناوری و حمل و نقل توسط قلب، ماموریت ما پیشبرد جنوب شرق آسیا با ایجاد توانمندسازی اقتصادی برای همه بوده است. اگر این ماموریت شما را متقاعد کند، امروز به تیم ما بپیوندید!