Files
crewAI/docs/edge/ar/enterprise/guides/deploy-to-amp.mdx
Lucas Gomide a237ebabba feat: adopt directory-based docs versioning with Edge channel (#6202)
* feat: adopt directory-based docs versioning with Edge channel

Switch docs.crewai.com from navigation-only versioning (every version
selector entry rendered the same docs/<lang>/* source files) to
Mintlify's directory-based versioning so each version selector entry
renders its own snapshot. Add an "Edge" channel under docs/edge/<lang>/*
that always reflects main HEAD for unreleased work, eliminating
pre-release leakage onto frozen release labels. External links to
canonical /<lang>/* URLs are preserved via wildcard redirects that
always land on the current default version.

Layout:
- docs/edge/<lang>/*         rolling source (you edit here)
- docs/edge/enterprise-api.*.yaml
- docs/v<X.Y.Z>/<lang>/*     frozen, immutable snapshots
- docs/v<X.Y.Z>/enterprise-api.*.yaml
- docs/images/               shared, append-only
- docs/docs.json             nav + redirects

URLs follow the Mintlify-idiomatic shape: /edge/<lang>/<page> for
Edge, /v<X.Y.Z>/<lang>/<page> for every frozen snapshot. The wildcard
redirects /<lang>/:slug* -> /<default>/<lang>/:slug* keep stale links
working, and every freeze rewrites them (plus all per-section/per-page
redirects) so destinations always resolve to the current default
without depending on a second redirect hop.

Release flow integration (devtools release):
- New module crewai_devtools.docs_versioning.freeze() materialises
  docs/v<X.Y.Z>/ from docs/edge/, rewrites openapi: refs inside the
  snapshot, inserts the version into every language block in
  docs.json, and refreshes all redirect destinations.
- _update_docs_and_create_pr() in cli.py now calls that freeze during
  Phase 2 of devtools release. Edge changelogs are updated first (so
  the snapshot freeze picks them up), then the snapshot is staged
  alongside docs.json, branched as docs/freeze-v<X.Y.Z>, and the PR
  is titled [docs-freeze] docs: snapshot and changelog for v<X.Y.Z>
  — the title prefix the new CI guard reads.
- The PR still gates tag, GitHub release, PyPI publish, and the
  enterprise release as before; no new PRs are added.
- Pre-releases (1.X.YaN, 1.X.YbN, ...) skip the snapshot — they ride
  Edge — and the docs PR title omits the [docs-freeze] prefix.
- docs_check (AI-generated docs scaffolding) writes to
  docs/edge/<lang>/* so newly-generated unreleased docs land in Edge
  and never accidentally touch a frozen snapshot.

Migration scripts (one-shot):
- scripts/docs/freeze_historical_versions.py reconstructs all 16
  historical snapshots (v1.10.0 .. v1.14.7) from git tags via
  git archive | tar, rewriting openapi: MDX refs so each snapshot
  reads its own enterprise-api YAML rather than the live one.
- scripts/docs/prefix_version_paths.py one-shot-migrates docs.json:
  rewrites every page path in 16 versioned blocks to point under
  docs/v<X.Y.Z>/, inserts a new Edge entry per language, tags
  v1.14.7 as Latest (default), prunes pages whose target file
  doesn't exist in the snapshot (e.g. docs/ar/ didn't exist before
  v1.12.0), and writes the wildcard + per-section redirects.
- scripts/docs/freeze_current_edge.py is now a thin CLI wrapper
  around docs_versioning.freeze for manual one-off freezes (e.g.
  retroactively snapshotting a forgotten release).

CI guards (.github/workflows/docs-snapshots.yml):
- Frozen snapshots under docs/v[0-9]*/ are immutable; only PRs whose
  title contains [docs-freeze] (i.e. release-cut PRs generated by
  devtools release or the manual wrapper) may modify them.
- Images under docs/images/ are append-only since snapshots share a
  single image directory. Deleting or renaming an image breaks every
  historical snapshot that still references it.

Restored docs/images/crewai-otel-export.png from PR #3673; it was
deleted in PR #4908 but v1.10.0 / v1.10.1 snapshots still reference
it. Restoring instead of editing the snapshots preserves historical
rendering fidelity and validates the new append-only rule
retroactively.

Tests:
- lib/devtools/tests/test_docs_versioning.py covers the freeze: file
  copy, openapi rewrite, version insertion, default demotion, redirect
  upserts, per-section redirect rewriting, idempotency, and invalid
  inputs.

Verified locally with mintlify broken-links: 0 broken links across
the full site (Edge + 16 frozen versions, 4 locales).

AGENTS.md (repo root) is the contributor guide for the new model;
RELEASING.md is the release-cut runbook; README's Contribution
section links to both.

Co-authored-by: Cursor <cursoragent@cursor.com>

* style: resolve linter issues

---------

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-17 11:56:59 -04:00

452 lines
16 KiB
Plaintext

---
title: "النشر على AMP"
description: "انشر طاقمك أو تدفقك على CrewAI AMP"
icon: "rocket"
mode: "wide"
---
<Note>
بعد إنشاء طاقم أو تدفق محلياً (أو عبر Crew Studio)، الخطوة التالية هي
نشره على منصة CrewAI AMP. يغطي هذا الدليل طرق نشر متعددة
لمساعدتك في اختيار النهج الأفضل لسير عملك.
</Note>
## المتطلبات المسبقة
<CardGroup cols={2}>
<Card title="مشروع جاهز للنشر" icon="check-circle">
يجب أن يكون لديك طاقم أو تدفق يعمل بنجاح محلياً.
اتبع [دليل التحضير](/ar/enterprise/guides/prepare-for-deployment) للتحقق من بنية مشروعك.
</Card>
<Card title="مستودع GitHub" icon="github">
يجب أن يكون الكود في مستودع GitHub (لطريقة تكامل
GitHub)
</Card>
</CardGroup>
<Info>
**الطواقم مقابل التدفقات**: يمكن نشر كلا نوعي المشاريع كـ "أتمتات" على CrewAI AMP.
عملية النشر هي نفسها، لكن لهما بنى مشاريع مختلفة.
راجع [التحضير للنشر](/ar/enterprise/guides/prepare-for-deployment) للتفاصيل.
</Info>
## الخيار 1: النشر باستخدام CrewAI CLI
يوفر CLI أسرع طريقة لنشر الطواقم أو التدفقات المطورة محلياً على منصة AMP.
يكتشف CLI تلقائياً نوع مشروعك من `pyproject.toml` ويبني وفقاً لذلك.
<Steps>
<Step title="تثبيت CrewAI CLI">
إذا لم تكن قد فعلت بالفعل، ثبّت CrewAI CLI:
```bash
pip install crewai[tools]
```
<Tip>
يأتي CLI مع حزمة CrewAI الرئيسية، لكن الإضافة `[tools]` تضمن حصولك على جميع اعتماديات النشر.
</Tip>
</Step>
<Step title="المصادقة مع منصة Enterprise">
أولاً، تحتاج لمصادقة CLI مع منصة CrewAI AMP:
```bash
# إذا كان لديك حساب CrewAI AMP بالفعل، أو تريد إنشاء واحد:
crewai login
```
عند تشغيل أي من الأمرين، سيقوم CLI بـ:
1. عرض رابط ورمز جهاز فريد
2. فتح متصفحك على صفحة المصادقة
3. طلب تأكيد الجهاز
4. إتمام عملية المصادقة
عند المصادقة الناجحة، سترى رسالة تأكيد في الطرفية!
</Step>
<Step title="إنشاء عملية نشر">
من مجلد مشروعك، شغّل:
```bash
crewai deploy create
```
سيقوم هذا الأمر بـ:
1. اكتشاف معلومات مستودع GitHub
2. تحديد متغيرات البيئة في ملف `.env` المحلي
3. نقل هذه المتغيرات بأمان إلى منصة Enterprise
4. إنشاء عملية نشر جديدة بمعرّف فريد
عند الإنشاء الناجح، سترى رسالة مثل:
```shell
Deployment created successfully!
Name: your_project_name
Deployment ID: 01234567-89ab-cdef-0123-456789abcdef
Current Status: Deploy Enqueued
```
</Step>
<Step title="مراقبة تقدم النشر">
تتبع حالة النشر بـ:
```bash
crewai deploy status
```
للسجلات المفصلة لعملية البناء:
```bash
crewai deploy logs
```
<Tip>
يستغرق النشر الأول عادة حوالي دقيقة واحدة.
</Tip>
</Step>
</Steps>
## أوامر CLI إضافية
يقدم CrewAI CLI عدة أوامر لإدارة عمليات النشر:
```bash
# عرض جميع عمليات النشر
crewai deploy list
# الحصول على حالة النشر
crewai deploy status
# عرض سجلات النشر
crewai deploy logs
# دفع التحديثات بعد تغييرات الكود
crewai deploy push
# إزالة عملية نشر
crewai deploy remove <deployment_id>
```
## الخيار 2: النشر مباشرة عبر واجهة الويب
يمكنك أيضاً نشر طواقمك أو تدفقاتك مباشرة عبر واجهة ويب CrewAI AMP بربط حساب GitHub. لا يتطلب هذا النهج استخدام CLI على جهازك المحلي. تكتشف المنصة تلقائياً نوع مشروعك وتتعامل مع البناء بشكل مناسب.
<Steps>
<Step title="الدفع إلى GitHub">
تحتاج لدفع طاقمك إلى مستودع GitHub. إذا لم تكن قد أنشأت طاقماً بعد، يمكنك [اتباع هذا الدليل](/ar/quickstart).
</Step>
<Step title="ربط GitHub بـ CrewAI AMP">
1. سجّل الدخول إلى [CrewAI AMP](https://app.crewai.com)
2. انقر على زر "Connect GitHub"
<Frame>
![زر ربط GitHub](/images/enterprise/connect-github.png)
</Frame>
</Step>
<Step title="اختيار المستودع">
بعد ربط حساب GitHub، ستتمكن من اختيار المستودع للنشر:
<Frame>
![اختيار المستودع](/images/enterprise/select-repo.png)
</Frame>
<Tip>
إذا كان Crew أو Flow داخل مجلد فرعي في monorepo، فوسّع **Advanced**
وعيّن دليل عمل قبل النشر. راجع
[النشر من Monorepo](/ar/enterprise/guides/monorepo-deployments).
</Tip>
</Step>
<Step title="تعيين متغيرات البيئة">
قبل النشر، ستحتاج لإعداد متغيرات البيئة للاتصال بمزود LLM أو خدمات أخرى:
1. يمكنك إضافة المتغيرات فردياً أو بشكل جماعي
2. أدخل متغيرات البيئة بتنسيق `KEY=VALUE` (واحد لكل سطر)
<Frame>
![تعيين متغيرات البيئة](/images/enterprise/set-env-variables.png)
</Frame>
<Info>
تستخدم حزم Python خاصة؟ ستحتاج لإضافة بيانات اعتماد السجل هنا أيضاً.
راجع [سجلات الحزم الخاصة](/ar/enterprise/guides/private-package-registry) للمتغيرات المطلوبة.
</Info>
</Step>
<Step title="نشر طاقمك">
1. انقر على زر "Deploy" لبدء عملية النشر
2. يمكنك مراقبة التقدم عبر شريط التقدم
3. يستغرق النشر الأول عادة حوالي دقيقة واحدة
<Frame>
![تقدم النشر](/images/enterprise/deploy-progress.png)
</Frame>
بمجرد اكتمال النشر، سترى:
- رابط طاقمك الفريد
- رمز Bearer لحماية API طاقمك
- زر "Delete" إذا كنت تحتاج لإزالة النشر
</Step>
</Steps>
## الخيار 3: إعادة النشر باستخدام API (تكامل CI/CD)
لعمليات النشر الآلية في خطوط أنابيب CI/CD، يمكنك استخدام CrewAI API لتشغيل إعادة نشر الطواقم الحالية. هذا مفيد بشكل خاص لـ GitHub Actions وJenkins أو سير عمل الأتمتة الأخرى.
<Steps>
<Step title="الحصول على رمز الوصول الشخصي">
انتقل إلى إعدادات حساب CrewAI AMP لإنشاء رمز API:
1. انتقل إلى [app.crewai.com](https://app.crewai.com)
2. انقر على **Settings** → **Account** → **Personal Access Token**
3. أنشئ رمزاً جديداً وانسخه بأمان
4. خزّن هذا الرمز كسر في نظام CI/CD
</Step>
<Step title="إيجاد UUID الأتمتة">
حدد موقع المعرّف الفريد لطاقمك المنشور:
1. انتقل إلى **Automations** في لوحة تحكم CrewAI AMP
2. اختر الأتمتة/الطاقم الحالي
3. انقر على **Additional Details**
4. انسخ **UUID** — يحدد هذا نشر طاقمك المحدد
</Step>
<Step title="تشغيل إعادة النشر عبر API">
استخدم نقطة نهاية Deploy API لتشغيل إعادة النشر:
```bash
curl -i -X POST \
-H "Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN" \
https://app.crewai.com/crewai_plus/api/v1/crews/YOUR-AUTOMATION-UUID/deploy
# HTTP/2 200
# content-type: application/json
#
# {
# "uuid": "your-automation-uuid",
# "status": "Deploy Enqueued",
# "public_url": "https://your-crew-deployment.crewai.com",
# "token": "your-bearer-token"
# }
```
<Info>
إذا تم إنشاء أتمتتك متصلة بـ Git أولاً، سيسحب API تلقائياً أحدث التغييرات من مستودعك قبل إعادة النشر.
</Info>
</Step>
<Step title="مثال تكامل GitHub Actions">
إليك سير عمل GitHub Actions مع مشغلات نشر أكثر تعقيداً:
```yaml
name: Deploy CrewAI Automation
on:
push:
branches: [ main ]
pull_request:
types: [ labeled ]
release:
types: [ published ]
jobs:
deploy:
runs-on: ubuntu-latest
if: |
(github.event_name == 'push' && github.ref == 'refs/heads/main') ||
(github.event_name == 'pull_request' && contains(github.event.pull_request.labels.*.name, 'deploy')) ||
(github.event_name == 'release')
steps:
- name: Trigger CrewAI Redeployment
run: |
curl -X POST \
-H "Authorization: Bearer ${{ secrets.CREWAI_PAT }}" \
https://app.crewai.com/crewai_plus/api/v1/crews/${{ secrets.CREWAI_AUTOMATION_UUID }}/deploy
```
<Tip>
أضف `CREWAI_PAT` و`CREWAI_AUTOMATION_UUID` كأسرار مستودع. لعمليات نشر PR، أضف تسمية "deploy" لتشغيل سير العمل.
</Tip>
</Step>
</Steps>
## التفاعل مع أتمتتك المنشورة
بمجرد اكتمال النشر، يمكنك الوصول إلى طاقمك عبر:
1. **REST API**: تنشئ المنصة نقطة نهاية HTTPS فريدة بهذه المسارات الرئيسية:
- `/inputs`: يعرض معاملات الإدخال المطلوبة
- `/kickoff`: يبدأ التنفيذ بالمدخلات المقدمة
- `/status/{kickoff_id}`: يتحقق من حالة التنفيذ
2. **واجهة الويب**: زر [app.crewai.com](https://app.crewai.com) للوصول إلى:
- **علامة تبويب Status**: عرض معلومات النشر وتفاصيل نقطة نهاية API ورمز المصادقة
- **علامة تبويب Run**: تمثيل مرئي لبنية طاقمك
- **علامة تبويب Executions**: سجل جميع عمليات التنفيذ
- **علامة تبويب Metrics**: تحليلات الأداء
- **علامة تبويب Traces**: رؤى التنفيذ المفصلة
### تشغيل عملية تنفيذ
من لوحة تحكم Enterprise، يمكنك:
1. النقر على اسم طاقمك لفتح تفاصيله
2. اختيار "Trigger Crew" من واجهة الإدارة
3. إدخال المدخلات المطلوبة في النافذة المنبثقة
4. مراقبة التقدم أثناء مرور التنفيذ عبر خط الأنابيب
### المراقبة والتحليلات
توفر منصة Enterprise ميزات مراقبة شاملة:
- **إدارة التنفيذ**: تتبع عمليات التشغيل النشطة والمكتملة
- **التتبعات**: تحليلات مفصلة لكل عملية تنفيذ
- **المقاييس**: استخدام الرموز وأوقات التنفيذ والتكاليف
- **عرض الجدول الزمني**: تمثيل مرئي لتسلسل المهام
### ميزات متقدمة
تقدم منصة Enterprise أيضاً:
- **إدارة متغيرات البيئة**: تخزين وإدارة مفاتيح API بأمان
- **اتصالات LLM**: تهيئة التكاملات مع مزودي LLM المختلفين
- **مستودع الأدوات المخصصة**: إنشاء ومشاركة وتثبيت الأدوات
- **Crew Studio**: بناء الطواقم عبر واجهة محادثة دون كتابة كود
## استكشاف أخطاء النشر وإصلاحها
إذا فشل النشر، تحقق من هذه المشكلات الشائعة:
### فشل البناء
#### ملف uv.lock مفقود
**العرض**: فشل البناء مبكراً مع أخطاء حل الاعتماديات
**الحل**: أنشئ ملف القفل وارفعه:
```bash
uv lock
git add uv.lock
git commit -m "Add uv.lock for deployment"
git push
```
<Warning>
ملف `uv.lock` مطلوب لجميع عمليات النشر. بدونه، لا يمكن للمنصة
تثبيت اعتمادياتك بشكل موثوق.
</Warning>
#### بنية المشروع الخاطئة
**العرض**: أخطاء "Could not find entry point" أو "Module not found"
**الحل**: تحقق من أن مشروعك يتطابق مع البنية المتوقعة:
- **JSON-first Crews**: أبقِ `crew.jsonc` أو `crew.json` و `agents/` في جذر المشروع
- **Crews كلاسيكية**: استخدم `src/project_name/main.py` مع دالة دخول `run()`
- **Flows**: استخدم `src/project_name/main.py` مع دالة دخول `kickoff()`
راجع [التحضير للنشر](/ar/enterprise/guides/prepare-for-deployment) لمخططات البنية المفصلة.
#### مُزخرف CrewBase مفقود في crew كلاسيكية
**العرض**: أخطاء "Crew not found" أو "Config not found" أو أخطاء تهيئة الوكيل/المهمة
**الحل**: في crews الكلاسيكية Python/YAML، تأكد من أن جميع فئات الـ crew تستخدم مُزخرف `@CrewBase`. لا تحتاج crews بنمط JSON-first إلى هذا المزخرف.
```python
from crewai.project import CrewBase, agent, crew, task
@CrewBase # This decorator is REQUIRED
class YourCrew():
"""Your crew description"""
@agent
def my_agent(self) -> Agent:
return Agent(
config=self.agents_config['my_agent'], # type: ignore[index]
verbose=True
)
# ... rest of crew definition
```
<Info>
ينطبق هذا على فئات crew الكلاسيكية المكتوبة في Python، بما في ذلك crews الكلاسيكية المضمنة داخل مشاريع Flow.
يتم التحقق من crews بنمط JSON-first من `crew.jsonc` و `agents/` بدلاً من ذلك.
</Info>
#### نوع pyproject.toml غير صحيح
**العرض**: نجاح البناء لكن فشل وقت التشغيل، أو سلوك غير متوقع
**الحل**: تحقق من أن قسم `[tool.crewai]` يتطابق مع نوع مشروعك:
```toml
# For Crew projects:
[tool.crewai]
type = "crew"
# For Flow projects:
[tool.crewai]
type = "flow"
```
### فشل وقت التشغيل
#### فشل اتصال LLM
**العرض**: أخطاء مفتاح API، "model not found"، أو فشل المصادقة
**الحل**:
1. تحقق من صحة تعيين مفتاح API لمزود LLM في متغيرات البيئة
2. تأكد من تطابق أسماء متغيرات البيئة مع ما يتوقعه الكود
3. اختبر محلياً بنفس متغيرات البيئة بالضبط قبل النشر
#### أخطاء تنفيذ الطاقم
**العرض**: يبدأ الطاقم لكن يفشل أثناء التنفيذ
**الحل**:
1. تحقق من سجلات التنفيذ في لوحة تحكم AMP (علامة تبويب Traces)
2. تحقق من أن جميع الأدوات لديها مفاتيح API المطلوبة مُهيأة
3. في crews بنمط JSON-first، تحقق من `crew.jsonc` والملفات المشار إليها داخل `agents/`
4. في crews الكلاسيكية، تأكد من صحة `agents.yaml` و `tasks.yaml`
<Card title="تحتاج مساعدة؟" icon="headset" href="mailto:support@crewai.com">
تواصل مع فريق الدعم للمساعدة في مشاكل النشر أو أسئلة حول
منصة AMP.
</Card>