نمای کلی سامانه

zev از سه سرویس تشکیل شده که جداگانه ساخته و مستقر می‌شوند و از طریق HTTP با هم حرف می‌زنند. ## کلاینت: `zev` یک فایل اجرایی بومی که با Zig نوشته شده است. انبار اشیای محلی روی دیسک را در `.zev/` نگه می‌دارد، مرحله‌بندی و کامیت را کاملاً بدون اینترنت انجام می‌دهد و فقط وقتی صراحتاً بخواهید با سرور ریموت حرف می‌زند (`zev push`، `zev pull`، `zev clone`). هیچ بخشی از تاریخچهٔ کامیت محلی به شبکه نیاز ندارد. ## سرور: `zev-api` یک سرور HTTP دست‌نویس به زبان Zig که فراداده (کاربران، مخزن‌ها، ارجاع‌ها، کنترل دسترسی) را در PostgreSQL و داده‌های بلاب را در یک انبار اشیای نشانی‌دهی محتوایی روی دیسک نگه می‌دارد. یک API از نوع JSON ارائه می‌دهد که احراز هویت، مدیریت مخزن و اشیا، همگام‌سازی آگاه از قطعه‌ها، جست‌وجوی معنایی و پین‌کردن منشأ را پوشش می‌دهد. احراز هویت در CLI با توکن دسترسی شخصی (PAT) است و یک دست‌دادن اولیهٔ چالش و پاسخ با امضای کلید عمومی اعتماد را برقرار می‌کند، بی‌آنکه کلید خصوصی هرگز ارسال شود. ## سرویس CI: `zev-ci` سرویسی جدا که به رویدادهای وب‌هوک `zev-api` گوش می‌دهد و گام‌های خط‌لوله را در کانتینرهای Docker ایزوله و مقاوم‌سازی‌شده اجرا می‌کند: به‌طور پیش‌فرض بدون دسترسی شبکه، با سامانهٔ فایل ریشهٔ فقط‌خواندنی، توانایی‌های حذف‌شده و محدودیت منابع. ابزار همراهش، `zev-ci-local`، همان تعریف خط‌لوله را دقیقاً در همان نوع جعبهٔ شنی روی دستگاه خود توسعه‌دهنده اجرا می‌کند، پس گامی که محلی موفق شود در CI تولیدی هم همان‌طور رفتار می‌کند. ## چگونه کنار هم قرار می‌گیرند یک روند معمول: توسعه‌دهنده با `zev` به‌صورت محلی کامیت می‌کند (بدون شبکه)، به `zev-api` ارسال می‌کند (اشیا و قطعه‌ها از طریق HTTP همگام می‌شوند)، این کار یک وب‌هوک به `zev-ci` می‌فرستد و آن خط‌لولهٔ مخزن را در یک کانتینر اجرا و نتیجه را به `zev-api` گزارش می‌دهد. هر یک از این سه سرویس پیش از اتصال به بقیه، جداگانه ساخته و ادعاهای اصلی‌اش راستی‌آزمایی شد: درستی مدل اشیا پیش از افزودن قطعه‌بندی روی آن اثبات شد، و درستی قطعه‌بندی هم پیش از ساختن لایهٔ حافظه‌دار CI روی آن.