رفتن به محتوا
پروژهvivid-visual-platformنوعSpecificationنسخه0.1وضعیتپیش‌نویس

معماری DevOps

این سند چارچوب عملیاتی توسعه و استقرار پلتفرم Vivid Visual را توضیح می‌دهد. هدف، تحویل پایدار با کمترین ریسک برای ماژول‌های درآمدی و آموزشی است.

اصل بنیادی: همه‌چیز Container

Section titled “اصل بنیادی: همه‌چیز Container”

تمام سرویس‌های پلتفرم — Angular SSR، داشبورد، APIهای ASP.NET Core، workerهای Python و ابزارهای جانبی — به‌صورت Docker image بسته‌بندی می‌شوند. هر سرویس یک Dockerfile چندمرحله‌ای دارد تا image نهایی کوچک، امن و قابل تکرار باشد. وابستگی‌های build در مرحله جدا از runtime نگه داشته می‌شوند و اسکن امنیتی image پیش از ورود به محیط staging اجباری است.

مرحلهخروجیتوضیح
Buildباینری و artifactکامپایل Angular، build و تست .NET، تست Python
Quality Gateتایید کیفیتlint، unit test، پوشش حداقلی تست، scan وابستگی
PackageDocker imagetag نسخه‌دار، push به رجیستری خصوصی
DeployRelease در K8sاعمال Helm chart در staging، سپس production پس از تایید

هر merge به شاخه اصلی، یک artifact قابل ردیابی تولید می‌کند. نسخه image، commit hash و زمان build در metadata release ثبت می‌شود تا در صورت incident بتوان دقیقاً به build قبلی بازگشت.

در محیط توسعه، Skaffold خط لوله build و deploy را برای تیم فنی ساده می‌کند: تغییر کد → build خودکار image → sync به کلاستر dev/staging داخلی. این رویکرد زمان بین commit و مشاهده نتیجه را کوتاه می‌کند و از ناهماهنگی «روی لپ‌تاپ کار می‌کند» جلوگیری می‌کند.

Skaffold در production استفاده نمی‌شود؛ محیط عملیاتی فقط از imageهای نسخه‌دار و releaseهای Helm تاییدشده تغذیه می‌شود.

هر سرویس یا گروه سرویس مرتبط یک Helm chart دارد. فایل values برای هر محیط (dev، staging، prod) جدا نگه داشته می‌شود:

  • replica و resource limit
  • endpoint دیتابیس و کش (بدون secret خام در repo)
  • feature flag و تنظیمات ماژول

Helm release history امکان rollback سریع را فراهم می‌کند. تغییرات زیرساختی حساس (Ingress، TLS، NetworkPolicy) از طریق chartهای مشترک platform مدیریت می‌شوند.

Dev — توسعه روزانه، داده مصنوعی، دسترسی محدود تیم فنی.

Staging — کپی نزدیک به production برای UAT، تست یکپارچه، smoke test و آزمایش migration.

Prod — سرویس‌دهی واقعی کاربران Vivid Visual، مانیتورینگ کامل، backup فعال، سیاست انتشار سخت‌گیرانه.

کانفیگ محیط از کد جدا نگهداری می‌شود (ConfigMap/Secret در K8s، نه hardcode در image). Rollback باید کمتر از ۱۵ دقیقه قابل اجرا باشد. مهاجرت دیتابیس پیش از switch ترافیک در Blue/Green اجرا می‌شود. هیچ secret در repository یا image عمومی قرار نمی‌گیرد.

جزئیات دقیق فایل‌های Skaffold، نام رجیستری، آدرس سرورها، توپولوژی شبکه داخلی و runbookهای عملیاتی در اختیار تیم پیمانکار (Rebati) نگهداری می‌شود و جزء تحویل قراردادی مشتری محسوب نمی‌گردد. مشتری خروجی قابل مشاهده (پایداری، SLA، گزارش انتشار) را دریافت می‌کند؛ نه دستورالعمل‌های داخلی خط تولید.