زیرساخت کامل DevOps برای توسعه Firmware تعبیه‌شده

آنچه یاد خواهید گرفت:

• چگونه مخزن gitlab خود را به‌درستی برای GitLab پیکربندی کنید؟
• چگونه یک فرآیند CI راه‌اندازی کنید که برای توسعه firmware تعبیه‌شده مناسب باشد؟
• چگونه فایل‌های خود را سازمان‌دهی کنید و ساختار دایرکتوری را در CI از نظر یکپارچگی بررسی کنید؟
• چگونه از منابع، گزینه‌های پیکربندی و توضیحات سخت‌افزار خود، مستندات زیبا تولید کنید؟
• چگونه با CMock، تست‌های واحد و یکپارچه‌سازی را به پروژه تعبیه‌شده اضافه کنید؟
• چگونه پشتیبانی از شبیه‌سازی را اضافه کنید، firmware تعبیه شده خود را در تست های سیستمی بر اساس نیازمندی‌های کاربر ارزیابی کنید و این تست ها را در CI اجرا کنید؟

پیش‌نیازهای دوره

• درک اولیه از git و برنامه‌نویسی C
• درک اولیه از python
• تمایل به یادگیری درباره راه‌اندازی درست CI

توضیحات دوره

این آموزش به شما کمک می‌کند فرآیند تحویل مداوم را برای firmware خود پیاده‌سازی کنید.

در واقع، این دوره همچنین یک «راهنمای جامع شروع کار با Zephyr RTOS» است.

این دوره چه تفاوتی با راهنمای شروع کار موجود Zephyr دارد؟ این آموزش برای توسعه اپلیکیشن firmware سفارشی شما در یک مخزن سفارشی خارج از Zephyr طراحی شده است - در حالی که راهنمای Zephyr بر شروع کار روی خود Zephyr تمرکز دارد - که کاری نیست که شما هر روز انجام می‌دهید. بنابراین، تمرکز این راهنما تفاوت بزرگی دارد.

آنچه شامل می‌شود

این آموزش به 6 بخش تقسیم شده است:

• بررسی - یک بررسی سریع از دوره، مشابه همین صفحه
• راه‌اندازی مخزن - در این بخش از ابتدا شروع می‌کنیم و به شما نشان می‌دهیم چگونه مخزن را به‌درستی پیکربندی کنید.
• راه‌اندازی GitLab CI - در این بخش یک pipeline پایه CI برای مخزن firmware خود ایجاد می‌کنیم که به ما اجازه می‌دهد کل فرآیند build را به‌صورت خودکار اجرا کنیم.
• ساختار دایرکتوری - یک ساختار دایرکتوری جامع ایجاد می‌کنیم که بتواند هر چیزی را که بعداً ممکن است به پروژه اضافه کنیم، در خود جای دهد.
• تولید مستندات - در این بخش یک ابزار تولید مستندات از Zephyr اضافه می‌کنیم که یک راهنمای مرجع زیبا برای پروژه ما تولید می‌کند.
• زیرساخت تست - در این بخش یک زیرساخت تست خودکار با استفاده از renode و CMock می‌سازیم.
• تولید نسخه نهایی - در این بخش یک release شامل همه فایل‌ها تولید می‌کنیم - مستندات، لیست اقلام نرم‌افزاری و firmware

راه‌اندازی مخزن

در این بخش یک مخزن اولیه را از ابتدا راه‌اندازی می‌کنیم. مزیت شروع از ابتدا این است که چگونگی تنظیم کل مخزن را یاد می‌گیرید. هرچند از ساختاری مشابه Zephyr پیروی می‌کنیم، اما از یک مخزن از پیش آماده شروع نمی‌کنیم. در عوض، از صفر آغاز می‌کنیم.

در این بخش موضوعات زیر پوشش داده می‌شوند:

• افزودن اولین اسکریپت‌های robot framework که به‌عنوان «تعریف انجام‌شدن» برای این مرحله عمل می‌کنند.
• افزودن فایل‌های موردنیاز: فایل‌های CMake، فایل‌های Kconfig، فایل CODEOWNERS، فایل gitignore و سایر موارد
• افزودن یک pre-commit hook که پیش از هر commit، بررسی‌های لازم را روی فایل‌های تغییر‌یافته اجرا می‌کند.
• افزودن یک اسکریپت init برای مخزن که پس از checkout، مخزن محلی و سیستم را راه‌اندازی می‌کند.

راه‌اندازی GitLab CI

پس از راه‌اندازی مخزن، حالا باید gitlab را پیکربندی کنیم تا بتوانیم به کار با merge requests منتقل شویم. برای این کار، موارد زیر را انجام می‌دهیم:

• پیکربندی یک پایپ لاین CI از طریق .gitlab-ci.yml
• ایجاد یک قالب تسک مناسب (برای ساخت taskها در gitlab)
• ساخت ایمیج های docker تا بتوانیم پایپ لاین را به‌صورت محلی از طریق gitlab-runner اجرا کنیم.
• افزودن قالب merge request
• پیکربندی مخزن برای trunk-based development
• افزودن بررسی برای اطمینان از اینکه عنوان merge request شامل ارجاع قابل کلیک به ticket در حال حل است.
• افزودن اسکریپت‌های بررسی انطباق Zephyr تا بتوان پیش از merge کردن، محتوای یک merge request را اعتبارسنجی و بررسی کرد.

ساختار دایرکتوری

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

این موارد شامل:

• افزودن یک اپلیکیشن نمونه - تا یک الگو برای شروع داشته باشید.
• افزودن یک board سفارشی - تا بتوانیم اپلیکیشن را برای سخت‌افزار سفارشی build کنیم.
• افزودن دایرکتوری کتابخانه cmake - این بخش بعداً محل قرار دادن اسکریپت‌های کمکی cmake خواهد بود.
• افزودن یک device driver نمونه - تا برای دایرکتوری‌های device driver یک الگو داشته باشیم.
• افزودن پوشه مستندات - بعداً docs را در آن قرار می‌دهیم.
• افزودن دایرکتوری include سراسری - برای رابط‌های عمومی کتابخانه‌ها و driverها که در سراسر پروژه firmware قابل مشاهده‌اند.
• افزودن یک کتابخانه نمونه - تا راهی برای افزودن کتابخانه‌های مشترک بین چند اپلیکیشن داشته باشیم.
• افزودن sampleهای نمونه - تا بعداً بتوانیم آن‌ها را در renode بوت کنیم و user storyها را اجرا کنیم.

تولید مستندات

وقتی ساختار کامل دایرکتوری در جای خود قرار گرفت، زمان آن است که تولید مستندات را اضافه کنیم. در این ماژول، از تولیدکننده مستندات Zephyr استفاده می‌کنیم تا در یک مخزن خارجی - مانند مخزنی که کد firmware ما در آن قرار دارد - به‌درستی کار کند.

این کار شامل موارد زیر است:

• انتقال doc generator و اسکریپت‌های سازگارکننده، تا مستندات پروژه ما را بسازند.
• افزودن اسکریپت‌های robot framework برای بررسی ساختار فصل‌ها - تا مطمئن شویم مستندات تقریباً از همان ساختار پیروی می‌کنند.
• پیوند دادن بخش‌های مستندات به یکدیگر تا بتوانیم یک خروجی PDF یا HTML واحد تولید کنیم.
• افزودن فرآیند build مستندات به CI و واداشتن همه چیز به عبور از تمام بررسی‌های CI که قبلاً راه‌اندازی کرده‌ایم.

زیرساخت تست

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

Zephyr فقط از تست‌های یکپارچه‌سازی و به‌صورت محدود از تست‌های واحد پشتیبانی می‌کند - بنابراین باید این قابلیت را اضافه کنیم. تست‌های سیستم برای این طراحی شده‌اند که firmware نهایی را بگیرند، آن را در یک شبیه‌ساز اجرا کنند (در این آموزش از renode استفاده می‌کنیم) و سناریوهای کاربری را روی آن اجرا کنند - این کار یکپارچگی کل سیستم را بررسی می‌کند.

• افزودن unity - تا بتوانیم ZTest را کنار بگذاریم و از یک framework تست استاندارد استفاده کنیم.
• افزودن CMock - تا بتوانیم هر تابعی را در تست‌های واحد mock کنیم و امکان بررسی یکپارچگی منطقی کد را داشته باشیم.
• افزودن پشتیبانی renode - تا بتوانیم firmware خود را از طریق renode شبیه‌سازی کنیم و سناریوها را با syntax مربوط به robot framework بنویسیم.
• بررسی پوشش کد - تا اجازه ندهیم هیچ فایل منبعی ادغام شود مگر اینکه به‌طور کامل تست شده باشد.

تولید نسخه نهایی

در این بخش همه چیزهایی را که تا اینجا اضافه کرده‌ایم جمع‌بندی می‌کنیم و یک release نهایی می‌سازیم. این کار شامل موارد زیر است:

• افزودن تولید software BoM - تا فهرستی از فایل‌هایی که در باینری گنجانده شده‌اند داشته باشیم.
• افزودن کد برای تولید یک آرشیو release نهایی

این دوره برای چه کسانی مناسب است؟

• مهندسان firmware تعبیه‌شده
• متخصصان نرم‌افزار تعبیه‌شده
• سرپرستان تیم و مدیران پروژه‌های تعبیه‌شده
• توسعه‌دهندگان firmware