# چطور Monorepo را روی سکوی ابری گردو دیپلوی کنیم؟

> برای هر برنامه داخل Monorepo یک سرویس جدا روی سکوی ابری (PaaS) گردو بسازید. همه سرویس‌ها می‌توانند به یک مخزن و شاخه متصل باشند؛ «پوشهٔ ریشه» محل تشخیص و ساخت هر سرویس را تعیین می‌کند و «مسیرهای تحت نظر» مانع انتشار بی‌دلیل سرویس‌های دیگر می‌شود.

آخرین بازبینی: ۱۴۰۵/۰۶/۱۵

## مدل واقعی Monorepo در گردو

هر برنامه یک سرویس مستقل با «دستور ساخت»، «دستور اجرا»، «متغیرها»، دامنه، تعداد نمونه و نسخه‌های انتشار جداست. برای نمونه:

```text
repo/
├── apps/
│   ├── web/
│   └── api/
├── packages/
│   └── shared/
├── package.json
└── pnpm-lock.yaml
```

## فیلدهای پیکربندی ساخت

- **پوشهٔ ریشه:** پوشه سرویس نسبت به ریشه مخزن، مانند `apps/api`. تشخیص «استک» و اجرای «دستور ساخت» از این پوشه انجام می‌شود.
- **مسیر Dockerfile:** مسیر نسبت به ریشه مخزن، مانند `apps/api/Dockerfile`. Dockerfile صریح همیشه اولویت دارد.
- **زمینهٔ ساخت:** فقط برای Dockerfile استفاده می‌شود. مقدار `.` اجازه می‌دهد فایل‌های ریشه و بسته‌های مشترک با `COPY` در دسترس باشند. مقدار پیش‌فرض «پوشهٔ ریشه» است.
- اگر Dockerfile وجود نداشته باشد، Nixpacks یا سازنده داخلی استک روی «پوشهٔ ریشه» اجرا می‌شود و «زمینهٔ ساخت» سفارشی نادیده گرفته می‌شود.

## نمونه workspace دارای package مشترک

```text
پوشهٔ ریشه:       apps/api
مسیر Dockerfile:  apps/api/Dockerfile
زمینهٔ ساخت:       .
مسیرهای تحت نظر:
  apps/api/**
  packages/shared/**
  pnpm-lock.yaml
```

## مسیرهای تحت نظر

- مسیر `apps/api` به‌صورت prefix عمل می‌کند.
- `*` فقط داخل یک segment تطبیق می‌دهد.
- `**` می‌تواند چند segment را پوشش دهد.
- `?` یک نویسه غیر separator را تطبیق می‌دهد.
- لیست خالی یعنی هر push روی branch متصل deploy ایجاد می‌کند.
- dependencyهای مشترک، lockfile و configهای ریشه را جداگانه اضافه کنید.
- اگر push بسیار بزرگ فهرست قابل اتکای فایل‌ها نداشته باشد، گردو برای جلوگیری از جاافتادن نسخه، سرویس را دوباره می‌سازد.

## deploy محلی با Gerdoo CLI

```bash
cd repo
gerdoo deploy . \
  --name api \
  --root-dir apps/api \
  --dockerfile apps/api/Dockerfile \
  --build-context . \
  --port 8080
```

## به‌روزرسانی سرویس Git با CLI

```bash
gerdoo service update api \
  --root-dir apps/api \
  --dockerfile apps/api/Dockerfile \
  --build-context . \
  --watch-path 'apps/api/**' \
  --watch-path 'packages/shared/**' \
  --watch-path pnpm-lock.yaml
```

## چک‌لیست

1. برای هر سرویس «پوشهٔ ریشه» و مسیر بررسی سلامت مستقل تعریف کنید.
2. وابستگی مشترک و lockfile را به «مسیرهای تحت نظر» تمام مصرف‌کنندگان اضافه کنید.
3. متغیرهای مشترک را در پروژه یا محیط نگه دارید.
4. تغییر فقط web و سپس تغییر package مشترک را جداگانه آزمایش کنید.
5. سازنده، Dockerfile و زمینه انتخاب‌شده را در لاگ ساخت بررسی کنید.
6. در بخش «استقرارها»، بازگشت به نسخه قبلی و ارتباط داخلی هر سرویس را آزمایش کنید.

## منابع

- [سکوی ابری گردو](https://gerdoo.cloud/products/paas)
- [همه راهنماهای استقرار](https://gerdoo.cloud/guides)
- [مستندات PaaS](https://gerdoo.cloud/support/docs/paas)
- [مستندات CLI](https://gerdoo.cloud/support/docs/cli)
- [Gerdoo Agents](https://gerdoo.cloud/support/docs/cli/agents)