استراتژی استقرار

استراتژی استقرار

استقرار Vivid Visual بر پایه Kubernetes در زیرساخت میزبانی‌شده داخل ایران طراحی شده است. همه سرویس‌ها Dockerize شده‌اند، با Helm به کلاستر منتقل می‌شوند و در مسیر توسعه از Skaffold برای تکرار سریع استفاده می‌شود.

نمای کلی خط استقرار

flowchart LR
  DEV[توسعه + Skaffold] --> BUILD[Build CI]
  BUILD --> IMG[Docker Image]
  IMG --> REG[رجیستری خصوصی]
  REG --> HELM[Helm Release]
  HELM --> K8S[کلاستر Kubernetes]
  K8S --> STG[Staging]
  STG --> PRD[Production]

زیرساخت استقرار در ایران

پلتفرم روی کلاستر Kubernetes اختصاصی مستقر می‌شود که روی سرورهای فیزیکی/اختصاصی داخل ایران ساماندهی شده است. این رویکرد اهداف زیر را پوشش می‌دهد:

• اقامت داده: داده‌های کاربران، تراکنش و محتوا در مرز ایران نگه داشته می‌شود.
• کنترل عملیاتی: تیم پیمانکار مالک topology کلاستر، سیاست backup و برنامه ظرفیت است.
• جداسازی محیط: namespace یا سگمنت شبکه جدا برای dev، staging و production.

توپولوژی پیشنهادی در سطح قرارداد:

لایه	نقش
Control Plane	مدیریت API، scheduler و etcd کلاستر
Worker Nodes	اجرای podهای سرویس‌های Angular، .NET و Python
Data Plane	PostgreSQL، Redis، Kafka، Elasticsearch (managed یا cluster داخلی)
Edge	Ingress/TLS و توزیع ترافیک عمومی

تعداد دقیق node، مشخصات سخت‌افزار، آدرس‌دهی شبکه و نحوه راه‌اندازی اولیه control plane جزئیات داخلی پیمانکار است و در مستندات مشتری منتشر نمی‌شود.

Docker و imageها

هر سرویس یک image مستقل دارد. imageها immutable هستند: پس از build تغییر نمی‌کنند؛ فقط tag جدید جایگزین می‌شود. قبل از deploy:

• اسکن آسیب‌پذیری image
• تست smoke در container staging
• ثبت نسخه در release notes داخلی

Helm و release management

استقرار production از طریق Helm انجام می‌شود، نه deploy دستی pod. هر release شامل chart version، image tag و checksum config است. در صورت خطا، helm rollback به revision پایدار قبلی اجرا می‌شود.

مدل انتشار: Rolling Deployment

کاربرد: سرویس‌های کم‌ریسک که توقف کوتاه یا تعویض تدریجی pod برایشان قابل قبول است.

نحوه کار: Kubernetes به‌تدریج podهای قدیمی را با نسخه جدید جایگزین می‌کند. maxUnavailable و maxSurge طوری تنظیم می‌شود که حداقل یک replica سالم همیشه در دسترس باشد. readiness probe قبل از دریافت ترافیک، سلامت pod را تایید می‌کند.

سرویس‌های مناسب:

• CMS و صفحات محتوایی
• Analytics و Reporting
• CRM (غیر از windowهای کمپین حساس)
• HR و Job Portal در ساعات کم‌ترافیک
• سرویس‌های پشتیبان و workerهای غیرحیاتی

مزایا: ساده، سریع، مصرف منابع کمتر از Blue/Green.

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

مدل انتشار: Blue/Green Deployment

کاربرد: ماژول‌های درآمدی و حیاتی که هر ثانیه downtime یا ناسازگاری نسخه می‌تواند مستقیماً روی درآمد اثر بگذارد.

نحوه کار: دو محیط موازی (Blue = فعال، Green = کاندید) نگه داشته می‌شود. نسخه جدید روی Green مستقر و با تست smoke، تست پرداخت آزمایشی و بررسی migration دیتابیس اعتبارسنجی می‌شود. سپس ترافیک production یک‌جا (یا به‌صورت کنترل‌شده) به Green منتقل می‌شود. Blue برای rollback فوری آماده می‌ماند.

سرویس‌های اجباری Blue/Green:

• Commerce Service (سبد، سفارش، پرداخت، اشتراک)
• Player Service در بازه‌های کمپین و فروش دوره
• API Gateway در انتشارهایی که قرارداد API را تغییر می‌دهند
• Learning Service هنگام تغییر سیاست دسترسی یا قیمت‌گذاری

پیش‌نیازهای اضافی Blue/Green:

• migration دیتابیس backward-compatible
• تست end-to-end پرداخت در staging با درگاه آزمایشی
• هماهنگی با تیم محصول برای freeze کوتاه تغییرات قیمت

جدول تصمیم انتشار

سرویس	مدل	دلیل
Commerce	Blue/Green	حساسیت مستقیم درآمد
Learning	Blue/Green در release بزرگ	دسترسی دوره و قیمت
Player	Blue/Green در کمپین	تجربه پخش و Upsell
CRM	Rolling	ریسک متوسط، rollback سریع کافی است
CMS	Rolling	محتوا، بدون تراکنش مالی
Analytics	Rolling	تأخیر چند دقیقه‌ای قابل تحمل
AI Worker	Rolling	صف async، بدون مسیر همزمان کاربر

نقش Skaffold در مسیر توسعه

Skaffold ابزار توسعه است، نه ابزار production. تیم فنی با آن روی کلاستر dev/staging داخلی iterate می‌کند: build image محلی یا remote، deploy خودکار، log و port-forward. این کار از ناهماهنگی بین Dockerfile و محیط واقعی جلوگیری می‌کند.

مشتری یا تیم محصول Vivid Visual نیازی به دانستن پروفایل Skaffold ندارد؛ خروجی نهایی همان image تاییدشده CI و Helm release است.

پیش‌نیاز هر انتشار

• عبور pipeline از تست خودکار (unit، integration حیاتی)
• تایید smoke test در staging با داده نزدیک به production
• تایید سلامت migration و backup اخیر دیتابیس
• بررسی changelog و تایید Product Owner برای ماژول‌های درآمدی
• وجود runbook rollback و مسئول on-call

پس از انتشار

• ۳۰ دقیقه اول: پایش error rate، latency p95 و saturation pod
• ۲۴ ساعت اول: KPI فروش، نرخ تکمیل دوره، نرخ خطای پرداخت
• ۷۲ ساعت: مقایسه با baseline قبل از release
• در صورت افت شاخص حیاتی: rollback فوری به revision یا محیط Blue

مهاجرت از WordPress / WooCommerce به پلتفرم جدید

سایت عملیاتی فعلی Vivid Visual بر پایه WordPress با WooCommerce و افزونه‌های جانبی (LMS، لایسنس، SEO، فرم‌ها و …) است. راه‌اندازی پلتفرم جدید بدون از دست رفتن کاربر، سفارش، محتوا و لایسنس‌های پلیر/دوره‌ای که قبلاً توزیع شده، نیازمند برنامه مهاجرت جدا از deploy معمولی است.

اهداف مهاجرت

• انتقال کاربران به Keycloak با حفظ هویت مبتنی بر ایمیل
• انتقال entitlementهای خرید (دوره، اشتراک، لایسنس پلیر)
• انتقال محتوای وب (صفحات، مقالات، رسانه) به CMS جدید
• حفظ SEO با redirect 301 از URLهای قدیمی
• cutover کنترل‌شده با امکان rollback به WP در بازه محدود

فاز ۰ — کشف و موجودی (۲ تا ۳ هفته)

قبل از هر ETL، موجودی دقیق سیستم فعلی ثبت می‌شود:

حوزه	منابع معمول در WP	خروجی کشف
کاربران	wp_users، wp_usermeta	تعداد، نقش‌ها، duplicate email
فروش	WooCommerce orders، subscriptions	SKUها، وضعیت پرداخت، اشتراک فعال
آموزش	LearnDash / Tutor / MemberPress / سفارشی	دوره‌ها، پیشرفت، enrollment
لایسنس	EDD License، WC Software Add-on، custom	کلیدها، فعال‌سازی، انقضا
محتوا	posts، pages، media library	حجم، ساختار، shortcodeها
پلیر	CDN/S3 فعلی، meta ویدیو	مسیر فایل، DRM فعلی

خروجی: سند Mapping تأییدشده + لیست افزونه‌های واقعاً استفاده‌شده (نه فقط نصب‌شده).

نمای کلی خط مهاجرت

flowchart TD
  WP[WordPress + WooCommerce] --> DISC[کشف و استخراج]
  DISC --> STG[Staging PostgreSQL]
  DISC --> KC[Keycloak Staging]
  STG --> VAL[اعتبارسنجی و Reconciliation]
  KC --> VAL
  VAL --> UAT[UAT با کاربران نمونه]
  UAT --> CUT[Cutover Blue/Green]
  CUT --> NEW[پلتفرم Vivid Visual]
  WP -.->|آرشیو read-only 30 روز| ARCH[WP Archive]

استخراج داده — مسئولیت‌ها

کارفرما (Vivid Visual) داده خام یا export استاندارد را فراهم می‌کند:

• دسترسی read-only به دیتابیس WP (یا dump امن)
• دسترسی پنل WooCommerce برای گزارش سفارش/اشتراک
• استخراج فایل CSV لایسنس طبق قالب سند ۱۴ (پلیر) و ۳۱ (کاربران)
• فهرست URLهای مهم برای redirect
• تایید نگاشت محصول قدیمی → محصول جدید (SKU mapping)

Rebati ETL، پاک‌سازی، import به staging، تست و cutover را اجرا می‌کند. اسکریپت‌ها و runbook داخلی جزء تحویل عمومی نیستند.

مهاجرت دیتابیس (MySQL WP → PostgreSQL)

دامنه WP/WC	جدول/منبع	مقصد PostgreSQL
مشتری	wc_customer_lookup / users	commerce.customers + legacy_user_id
سفارش	wc_orders	commerce.orders (وضعیت تاریخی)
محصول	wc_products	commerce.products
اشتراک	wcs_subscriptions	commerce.subscriptions
دوره	LMS tables	learning.courses + enrollments
پیشرفت	LMS progress meta	learning.lesson_progress
لایسنس	license plugin tables	commerce.licenses + legacy_licenses
CRM (در صورت افزونه)	leads meta	crm.leads

اصول:

• import اولیه در staging؛ production فقط پس از reconciliation
• هر رکورد legacy دارای external_id از WP (order_id، user_id، license_key)
• سفارش‌های قدیمی read-only هستند؛ سفارش جدید فقط در سیستم جدید ثبت می‌شود

مهاجرت کاربران → Keycloak

جزئیات در سند ۳۱ (احراز هویت). خلاصه cutover:

1. import کاربران به realm production Keycloak
2. ارسال ایمیل «حساب شما منتقل شد — رمز جدید تنظیم کنید»
3. غیرفعال کردن فرم login در WP (یا maintenance mode)
4. فعال‌سازی OIDC در دامنه اصلی

مهاجرت لایسنس پلیر و دسترسی توزیع‌شده

جزئیات در سند ۱۴ (پلیر). خلاصه:

• کارفرما کلیدهای فعال را extract می‌کند
• Rebati validate می‌کند: تعداد active قبل = بعد
• API پلیر در grace period هر دو منبع را می‌پذیرد
• پس از ۹۰ روز، فقط منبع جدید (مگر استثناء قراردادی)

مهاجرت محتوا و رسانه

• صفحات و مقالات: HTML → Markdown/بلاک CMS (دستی + نیمه‌خودکار)
• تصاویر و فایل‌ها: media library → S3 با حفظ نام یا mapping
• ویدیوهای دوره: انتقال به bucket پلیر جدید؛ به‌روزرسانی URL در lesson
• shortcodeهای WP: جایگزین با کامپوننت Angular یا حذف تدریجی

SEO و URL

• جدول redirect 301 از /old-path به /new-path در Ingress
• حفظ slugهای مهم در صورت امکان
• ثبت در Search Console پس از cutover
• sitemap جدید در Angular SSR

برنامه Cutover (پیشنهادی)

روز	فعالیت
T-14	freeze تغییرات محصول/قیمت در WP
T-7	import نهایی staging + UAT کامل
T-3	اعلام به کاربران (ایمیل + بنر سایت)
T-0 شب	WP به read-only، import نهایی delta، switch DNS به Green
T+1	پایش 24/7: login، پرداخت، پخش، لایسنس
T+7	گزارش reconciliation رسمی
T+30	خاموش کردن grace legacy (در صورت پایداری)

Cutover ماژول Commerce و Player با Blue/Green انجام می‌شود؛ WP تا ۳۰ روز به‌صورت آرشیو زنده می‌ماند.

Rollback مهاجرت

اگر در ۴۸ ساعت اول شاخص حیاتی شکست بخورد:

1. برگرداندن DNS به WP (Blue)
2. توقف OIDC در وب جدید
3. اعلام به کاربران
4. تحلیل root cause قبل از تلاش مجدد

آنچه در این سند نیست (اجرای داخلی Rebati)

• کوئری‌های SQL دقیق هر افزونه
• اسکریپت ETL و ترتیب transaction
• نمونه credential و اتصال دیتابیس
• ابزار one-off برای parse shortcode

محرمانه — خارج از مستندات تحویلی

موارد زیر عمداً در این سند نیامده‌اند و در اختیار تیم پیمانکار (Rebati) نگهداری می‌شوند:

• مشخصات دقیق سرورها و IPهای داخلی
• دستورات bootstrap کلاستر و hardening سطح OS
• محتوای کامل values/secret و runbook داخلی
• تنظیمات دقیق Skaffold profile و hookهای اختصاصی خط لوله
• «دستور پخت» اتوماسیون‌های خاص تیم (secret recipe)

این محدودیت عمدی است: مشتری شفافیت در چه چیزی مستقر می‌شود و چه تضمینی دارد را می‌بیند؛ جزئیات اجرایی که امنیت یا مزیت رقابتی عملیاتی را تحت تأثیر قرار می‌دهد، منتشر نمی‌شود.