مشكلة تطبيق ليلة الجمعة
أمضى مديرُ شركةٍ نعرفه أمسيةَ جمعةٍ مع مساعد ذكاء اصطناعي، وبحلول منتصف الليل كان بين يديه أداة داخلية نافعة فعلًا: تتبّع مهام مُصمَّم تمامًا على شكل عمل فريقه، لأنه يعرف هذا العمل أفضل من أي مورّد خارجي. وكان يعمل بامتياز — على حاسوبه المحمول.
كانت خيارات يوم الاثنين كلها سيئة. أن يطلب خادمًا من قسم تقنية المعلومات وينتظر أسابيع حتى تزحف التذكرة في مسارها. أو أن يدفع ببيانات الشركة إلى منصة هواةٍ أجنبية. أو أن يستأجر خادم VPS خامًا فيصبح مسؤولًا بين ليلة وضحاها عن TLS والنسخ الاحتياطي والترقيعات والجدران النارية. الكود كان جيدًا. ما كان ينقصه هو الطريق.
لماذا لا تناسبه مسارات النشر المعتادة
كل مسار سائد يفترض شيئًا لا يملكه هذا الباني. النشر عبر Git يفترض مستودعًا وسير عمل بالفروع. والنشر عبر الصور يفترض سجل حاويات وإتقانًا لـ Docker يكفي لتغذيته. وكلاهما يفترض أن مَن يُطلق البرمجية مهندسُ نشرٍ ولو بدوام جزئي.
أما ما يملكه الباني المستعين بالذكاء الاصطناعي فأبسط من ذلك: مجلد فيه كود يعمل. فليكن هذا بالضبط ما يبدأ منه الطريق — المجلد. راجع النشر من Git إن كان لديك مستودع فعلًا؛ فالطريقان ينتهيان عند المنصة نفسها.
المجلد يكفي
ثبّت أداة سطر أوامر صغيرة واحدة، وشغّل أمرًا واحدًا داخل مجلد المشروع، ويتولى cdnctl الباقي: اللغة وإطار العمل، والمنفذ، ووجود Dockerfile من عدمه (ويستطيع توليده)، بل وحتى أي وكلاء برمجة ذكاء اصطناعي مُهيَّؤون في المشروع — لأن الوكيل الذي كتب التطبيق هو غالبًا من سيواصل إطلاقه.
$ cdnctl init
Proje : gorev-takip (node/express, port 3000)
Agent : claude-code (claude on PATH), cursor
Paket : ✓ Large (max 5 app)
Karne : 2 HATA, 2 uyarı — ayrıntı: cdnctl check
Yazıldı : cdnctl.yaml, AGENTS.md
→ Önce `cdnctl check` hatalarını düzeltin (deploy sonrası site açılmaz).
بطاقة تقييم قبل أن يغادر كودك الجهاز
تفشل التطبيقات المولَّدة بالذكاء الاصطناعي في الإنتاج لحفنةٍ من الأسباب المتكررة جدًا، وكلها ظاهرة في المصدر قبل النشر. يعمل cdnctl check بالكامل على جهازك — لا يُرفَع أي كود — ويرفض أن يُطلق تطبيقًا معروف العطب. والنتائج الأربع أدناه ليست افتراضية: إنها الأعطال ذاتها التي كُتب بها تطبيقنا التجريبي، والتُقطت من أول تشغيل.
$ cdnctl check
[ERROR] bind-localhost (server.js:61)
The app binds to 127.0.0.1 — unreachable inside a container.
→ Bind to 0.0.0.0 (just drop the host argument).
[ERROR] secret-in-code (server.js:10)
A hard-coded secret (API key/token/password).
→ Move it to --secret KEY=VALUE; read it via process.env.
[WARNING] sqlite-single-pod
SQLite loses data on restart / multiple replicas.
→ Mount a persistent disk or switch to a managed database.
[WARNING] no-healthcheck
No /health route — the platform can’t tell your app is alive.
أمر واحد إلى رابط مباشر
بعد الإصلاحات، يصبح النشر أمرًا واحدًا. خلف الكواليس يُؤرشَف مصدرك، ويُرفَع عبر TLS، ويُبنى صورةَ حاويةٍ داخل بيئة معزولة، ويُدفَع إلى مساحة السجل الخاصة بحسابك، ويُشغَّل خلف نطاق فرعي حقيقي بـ HTTPS — ولا شيء من ذلك يحتاج انتباهك. يستغرق التشغيل الأول نحو دقيقة؛ وكل إصدار لاحق هو الأمر الواحد نفسه.
$ cdnctl deploy
→ archiving source (gorev-takip)
→ uploading (0.1 MB)
→ starting build (Kaniko, isolated sandbox)
build: running
build: success (41 s)
→ creating the app
→ assigning a subdomain
→ first deploy
→ waiting for the app to come up
✓ LIVE: https://ca…….cdn.com.tr
الأمان والمتانة إعدادات افتراضية، لا أعباء
الأجزاء التي جعلت طريق الـ VPS مخيفًا هي هنا مهمة المنصة. تُصدَر شهادة TLS وتُجدَّد نيابةً عنك. وتجري عمليات البناء في بيئة معزولة، وتسكن الصور مساحةَ سجلٍّ تخص حسابك وحده. ويتيح فحص الصحة للمنصة إعادة تشغيل تطبيقك لحظةَ توقفه عن الاستجابة. وحين تلتقط بطاقة التقييم قاعدة بيانات ملفية، تدلّك على الأقراص الدائمة وعلى MySQL/PostgreSQL المُدارتين — فلا تلتهم إعادةُ تشغيل pod بياناتك أبدًا.
وكيلك الذكي يستطيع تنفيذ هذا المسار كله بنفسه
يكتب cdnctl init قسمَ نشرٍ داخل AGENTS.md (وداخل CLAUDE.md عند وجوده)، فيعرف الوكيل الذي بنى التطبيق الأوامرَ الدقيقة في دورته التالية. يحصل الوكلاء على مخرجات قابلة للقراءة الآلية عبر --json، وعلى خادم MCP عبر cdnctl mcp، والأهم: على رمزهم الخاص المخصّص للنشر فقط — يستطيع الرفع والبناء والإطلاق، ولا يستطيع مطلقًا لمس DNS أو الفوترة أو بقية حسابك. كلمة مرور لوحتك لا تغادرك أبدًا. التفاصيل في صفحات مساعدة cdnctl. وللاطلاع على النموذج الأمني الكامل — حدود الرمز، وتهيئة MCP، والحدود المُختبَرة — راجع امنح وكيلك صلاحية النشر بأمان.
أي طريق طريقُك؟
ثلاثة طرق، ومنصة واحدة. إن كنت تحفظ الكود في مستودع وتريد النشر بالدفع (push)، فاسلك النشر من Git. وإن كنت تبني الصور بنفسك وتشغّل ملف compose، فانظر استضافة Docker. أما إن كان ما لديك مجلدًا يعمل — موقف ليلة الجمعة — فهذا الطريق بُني لك: ثبّت cdnctl، وشغّل init، ثم deploy، وأرسل الرابط إلى فريقك.
الأسئلة الشائعة
هل أحتاج إلى GitHub أو أي استضافة git؟
لا. ينتقل المصدر أرشيفًا مباشرةً من مجلد مشروعك؛ وgit لا يدخل المسار أصلًا. وإن تبنّيت مستودعًا لاحقًا فطريق git موجود، ويبقى التطبيق كما هو.
هل أحتاج إلى معرفة Docker؟
لا. إن لم يكن في المشروع ملف Dockerfile، فبإمكان cdnctl init توليد ملفٍ معقول مما يكتشفه. والبناء نفسه يجري على المنصة، لا على جهازك.
إلى أين يذهب كودي فعليًا؟
يُرفَع الأرشيف عبر TLS إلى حسابك، ويُبنى مرة واحدة داخل بيئة معزولة، وتُخزَّن الصورة الناتجة في مساحة سجل خاصة لا يستخدمها إلا حسابك. لا شيء يُشارَك، ولا شيء يعمل خارج نطاقك (namespace).
كم التكلفة؟
أي باقة تتضمن منصة الحاويات — وكل الباقات القياسية تتضمنها. يخبرك cdnctl إن كان حسابك يفتقدها ويضع رابط صفحة الشراء؛ يكتمل الدفع في المتصفح ويواصل cdnctl من حيث توقف.
كيف أُطلق تحديثًا؟
شغّل cdnctl deploy مرة أخرى. تبني المنصة الصورة الجديدة وتبدّلها؛ وتواصل النسخة القديمة الخدمة حتى تقوم الجديدة.