heroku · mtawil · Jan 6, 2026
@@ -0,0 +1,14 @@
+## XII. عمليات الإدارة (Admin processes)
+### تشغيل مهام الإدارة/الصيانة كعمليات لمرة واحدة
+
+[تشكيلة العمليات](./concurrency) هي مصفوفة العمليات التي تستخدم للقيام بالعمل المنتظم للتطبيق (مثل التعامل مع طلبات الويب) أثناء تشغيله. بشكل منفصل، سيرغب المطورون غالبًا في القيام بمهام إدارية أو صيانة لمرة واحدة للتطبيق، مثل:
+
+* تشغيل ترحيل قاعدة البيانات (مثل `manage.py migrate` في Django، `rake db:migrate` في Rails).
+* تشغيل وحدة تحكم (تُعرف أيضًا باسم غلاف [REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop)) لتشغيل شيفرة عشوائية أو فحص نماذج التطبيق مقابل قاعدة البيانات الحية. توفر معظم اللغات REPL عن طريق تشغيل المترجم دون أي وسائط (مثل `python` أو `perl`) أو في بعض الحالات يكون لها أمر منفصل (مثل `irb` لـ Ruby، `rails console` لـ Rails).
+* تشغيل نصوص برمجية لمرة واحدة تم الالتزام بها في مستودع التطبيق (مثل `php scripts/fix_bad_records.php`).
+
+يجب تشغيل عمليات الإدارة لمرة واحدة في بيئة مماثلة لـ [العمليات طويلة الأمد](./processes) العادية للتطبيق. يتم تشغيلها مقابل [إصدار](./build-release-run)، باستخدام نفس [قاعدة الشيفرة](./codebase) و [الإعدادات](./config) كأي عملية تعمل مقابل ذلك الإصدار. يجب تضمين شيفرة الإدارة مع شيفرة التطبيق لتجنب مشاكل المزامنة.
+
+يجب استخدام نفس تقنيات [عزل الاعتمادية](./dependencies) على جميع أنواع العمليات. على سبيل المثال، إذا كانت عملية ويب Ruby تستخدم الأمر `bundle exec thin start`، فيجب أن يستخدم ترحيل قاعدة البيانات `bundle exec rake db:migrate`. وبالمثل، يجب أن يستخدم برنامج Python الذي يستخدم Virtualenv `bin/python` المضمن لتشغيل كل من خادم ويب Tornado وأي عمليات إدارة `manage.py`.
+
+تفضل العوامل الاثني عشر بشدة اللغات التي توفر غلاف REPL جاهزًا، والتي تجعل من السهل تشغيل نصوص برمجية لمرة واحدة. في النشر المحلي، يستدعي المطورون عمليات الإدارة لمرة واحدة عن طريق أمر shell مباشر داخل دليل سحب التطبيق. في نشر الإنتاج، يمكن للمطورين استخدام ssh أو آلية تنفيذ أوامر عن بعد أخرى توفرها بيئة تنفيذ ذلك النشر لتشغيل مثل هذه العملية.
@@ -0,0 +1,8 @@
+خلفية
+==========
+
+لقد شارك المساهمون في هذا المستند بشكل مباشر في تطوير ونشر مئات التطبيقات، وشهدوا بشكل غير مباشر تطوير وتشغيل وتوسيع مئات الآلاف من التطبيقات من خلال عملنا على منصة <a href="http://www.heroku.com/" target="_blank">Heroku</a>.
+
+يقوم هذا المستند بتجميع كل خبراتنا وملاحظاتنا حول مجموعة واسعة من تطبيقات "البرمجيات كخدمة" في الواقع. إنه خلاصة للممارسات المثالية لتطوير التطبيقات، مع إيلاء اهتمام خاص لديناميكيات النمو الطبيعي للتطبيق بمرور الوقت، وديناميكيات التعاون بين المطورين الذين يعملون على قاعدة الشيفرة للتطبيق، و <a href="http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/" target="_blank">تجنب تكلفة تقادم البرمجيات</a>.
+
+دافعنا هو رفع الوعي ببعض المشاكل المنهجية التي رأيناها في تطوير التطبيقات الحديثة، لتوفير مفردات مشتركة لمناقشة تلك المشاكل، وتقديم مجموعة من الحلول المفاهيمية الواسعة لتلك المشاكل مع المصطلحات المصاحبة. التنسيق مستوحى من كتب مارتن فاولر *<a href="https://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC" target="_blank">أنماط معماريات تطبيقات المؤسسات (Patterns of Enterprise Application Architecture)</a>* و *<a href="https://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C" target="_blank">إعادة الهيكلة (Refactoring)</a>*.
@@ -0,0 +1,14 @@
+## IV. الخدمات المساندة (Backing services)
+### معاملة الخدمات المساندة كموارد مرفقة
+
+*الخدمة المساندة* هي أي خدمة يستهلكها التطبيق عبر الشبكة كجزء من عمله الطبيعي. تشمل الأمثلة مخازن البيانات (مثل [MySQL](http://dev.mysql.com/) أو [CouchDB](http://couchdb.apache.org/))، وأنظمة المراسلة/الطوابير (مثل [RabbitMQ](http://www.rabbitmq.com/) أو [Beanstalkd](https://beanstalkd.github.io))، وخدمات SMTP للبريد الإلكتروني الصادر (مثل [Postfix](http://www.postfix.org/))، وأنظمة التخزين المؤقت (مثل [Memcached](http://memcached.org/)).
+
+تتم إدارة الخدمات المساندة مثل قاعدة البيانات تقليديًا بواسطة نفس مسؤولي الأنظمة الذين ينشرون وقت تشغيل التطبيق. بالإضافة إلى هذه الخدمات المدارة محليًا، قد يكون للتطبيق أيضًا خدمات مقدمة ومدارة بواسطة أطراف ثالثة. تشمل الأمثلة خدمات SMTP (مثل [Postmark](http://postmarkapp.com/))، وخدمات جمع المقاييس (مثل [New Relic](http://newrelic.com/) أو [Loggly](http://www.loggly.com/))، وخدمات الأصول الثنائية (مثل [Amazon S3](http://aws.amazon.com/s3/))، وحتى خدمات المستهلك التي يمكن الوصول إليها عبر واجهة برمجة التطبيقات (API) (مثل [Twitter](http://dev.twitter.com/)، [Google Maps](https://developers.google.com/maps/)، أو [Last.fm](http://www.last.fm/api)).
+
+**لا تميز شيفرة تطبيق العوامل الاثني عشر بين الخدمات المحلية وخدمات الطرف الثالث.** بالنسبة للتطبيق، كلاهما موارد مرفقة، يتم الوصول إليها عبر عنوان URL أو معرف موارد/بيانات اعتماد أخرى مخزنة في [الإعدادات](./config). يجب أن تكون [عملية نشر](./codebase) تطبيق العوامل الاثني عشر قادرة على استبدال قاعدة بيانات MySQL محلية بأخرى مدارة بواسطة طرف ثالث (مثل [Amazon RDS](http://aws.amazon.com/rds/)) دون أي تغييرات في شيفرة التطبيق. وبالمثل، يمكن استبدال خادم SMTP محلي بخدمة SMTP تابعة لطرف ثالث (مثل Postmark) دون تغييرات في الشيفرة. في كلتا الحالتين، يحتاج فقط رابط المورد في الإعدادات إلى التغيير.
+
+كل خدمة مساندة متميزة هي *مورد*. على سبيل المثال، قاعدة بيانات MySQL هي مورد؛ قاعدتا بيانات MySQL (تستخدمان للتقسيم (sharding) في طبقة التطبيق) تتأهلان كموردين متميزين. يعامل تطبيق العوامل الاثني عشر قواعد البيانات هذه كـ *موارد مرفقة*، مما يشير إلى اقترانها المرن بعملية النشر المرفقة بها.
+
+<img src="/images/attached-resources.png" class="full" alt="نشر إنتاج مرتبط بأربع خدمات مساندة." />
+
+يمكن إرفاق الموارد وفصلها عن عمليات النشر حسب الرغبة. على سبيل المثال، إذا كانت قاعدة بيانات التطبيق تعاني من مشاكل بسبب مشكلة في الأجهزة، فقد يقوم مسؤول التطبيق بتشغيل خادم قاعدة بيانات جديد تمت استعادته من نسخة احتياطية حديثة. يمكن فصل قاعدة بيانات الإنتاج الحالية، وإرفاق قاعدة البيانات الجديدة -- كل ذلك دون أي تغييرات في الشيفرة البرمجية.
@@ -0,0 +1,18 @@
+## V. البناء، الإصدار، التشغيل (Build, release, run)
+### الفصل الصارم بين مراحل البناء والتشغيل
+
+يتم تحويل [قاعدة الشيفرة](./codebase) إلى عملية نشر (غير تطويرية) عبر ثلاث مراحل:
+
+* *مرحلة البناء* هي تحويل يحول مستودع الشيفرة إلى حزمة قابلة للتنفيذ تُعرف باسم *build* (البناء). باستخدام نسخة من الشيفرة عند تعديل محدد (commit) بواسطة عملية النشر، تجلب مرحلة البناء [الاعتماديات](./dependencies) وتقوم بتجميع الثنائيات والأصول.
+* تأخذ *مرحلة الإصدار* البناء الذي أنتجته مرحلة البناء وتجمعه مع [الإعدادات](./config) الحالية لعملية النشر. يحتوي *الإصدار* الناتج على كل من البناء والإعدادات ويكون جاهزًا للتنفيذ الفوري في بيئة التنفيذ.
+* *مرحلة التشغيل* (المعروفة أيضًا باسم "وقت التشغيل") تشغل التطبيق في بيئة التنفيذ، عن طريق إطلاق مجموعة من [عمليات](./processes) التطبيق مقابل إصدار محدد.
+
+![تتحول الشيفرة إلى بناء، والذي يتم دمجه مع الإعدادات لإنشاء إصدار.](/images/release.png)
+
+**يستخدم تطبيق العوامل الاثني عشر فصلاً صارمًا بين مراحل البناء والإصدار والتشغيل.** على سبيل المثال، من المستحيل إجراء تغييرات على الشيفرة في وقت التشغيل، حيث لا توجد طريقة لنقل تلك التغييرات مرة أخرى إلى مرحلة البناء.
+
+توفر أدوات النشر عادةً أدوات إدارة الإصدار، وأبرزها القدرة على التراجع (roll back) إلى إصدار سابق. على سبيل المثال، تخزن أداة النشر [Capistrano](https://github.com/capistrano/capistrano/wiki) الإصدارات في دليل فرعي يسمى `releases`، حيث يكون الإصدار الحالي عبارة عن رابط رمزي (symlink) لدليل الإصدار الحالي. يجعل أمر `rollback` الخاص بها من السهل التراجع بسرعة إلى إصدار سابق.
+
+يجب أن يكون لكل إصدار دائمًا معرف إصدار فريد، مثل الطابع الزمني للإصدار (مثل `2011-04-06-20:32:17`) أو رقم متزايد (مثل `v100`). الإصدارات عبارة عن سجل للإضافة فقط ولا يمكن تغيير الإصدار بمجرد إنشائه. أي تغيير يجب أن ينشئ إصدارًا جديدًا.
+
+يبدأ مطورو التطبيق عمليات البناء كلما تم نشر شيفرة جديدة. تنفيذ وقت التشغيل، على العكس من ذلك، يمكن أن يحدث تلقائيًا في حالات مثل إعادة تشغيل الخادم، أو إعادة تشغيل عملية معطلة بواسطة مدير العمليات. لذلك، يجب إبقاء مرحلة التشغيل بأقل عدد ممكن من الأجزاء المتحركة، حيث يمكن أن تتسبب المشاكل التي تمنع التطبيق من التشغيل في تعطله في منتصف الليل عندما لا يكون هناك مطورون متاحون. يمكن أن تكون مرحلة البناء أكثر تعقيدًا، حيث تكون الأخطاء دائمًا في المقدمة للمطور الذي يقود عملية النشر.
@@ -0,0 +1,17 @@
+## I. قاعدة الشيفرة (Codebase)
+### قاعدة شيفرة واحدة يتم تتبعها في أنظمة إدارة الإصدارات، والعديد من عمليات النشر
+
+يتم دائمًا تتبع تطبيق "العوامل الاثني عشر" في نظام التحكم في الإصدار، مثل [Git](http://git-scm.com/)، [Mercurial](https://www.mercurial-scm.org/)، أو [Subversion](http://subversion.apache.org/). تُعرف نسخة قاعدة بيانات تتبع الإصدارات باسم *مستودع الشيفرة*، وغالبًا ما يتم اختصارها إلى *code repo* أو مجرد *repo*.
+
+*قاعدة الشيفرة* هي أي مستودع فردي (في نظام تحكم مركزي مثل Subversion)، أو أي مجموعة من المستودعات التي تشترك في نقطة بداية مشتركة (في نظام تحكم لامركزي مثل Git).
+
+![قاعدة شيفرة واحدة ترتبط بالعديد من عمليات النشر](/images/codebase-deploys.png)
+
+هناك دائمًا علاقة واحد لواحد بين قاعدة الشيفرة والتطبيق:
+
+* إذا كان هناك العديد من قواعد الشيفرة، فهو ليس تطبيقًا -- بل هو نظام موزع. كل مكون في النظام الموزع هو تطبيق، ويمكن لكل منها الامتثال بشكل فردي للعوامل الاثني عشر.
+* مشاركة تطبيقات متعددة لنفس الشيفرة البرمجية هو انتهاك للعوامل الاثني عشر. الحل هنا هو تحويل الشيفرة المشتركة إلى مكتبات يمكن تضمينها من خلال [مدير الاعتماديات](./dependencies).
+
+توجد قاعدة شيفرة واحدة فقط لكل تطبيق، ولكن سيكون هناك العديد من عمليات النشر للتطبيق. *النشر* هو نسخة قيد التشغيل من التطبيق. عادة ما يكون هذا موقع إنتاج، وموقع تجربة واحد أو أكثر. بالإضافة إلى ذلك، يمتلك كل مطور نسخة من التطبيق تعمل في بيئة التطوير المحلية الخاصة به، وكل منها مؤهل أيضًا كعملية نشر.
+
+قاعدة الشيفرة هي نفسها عبر جميع عمليات النشر، على الرغم من أن الإصدارات المختلفة قد تكون نشطة في كل عملية نشر. على سبيل المثال، لدى المطور بعض التعديلات (commits) التي لم يتم نشرها بعد في بيئة التجربة؛ بيئة التجربة لديها بعض التعديلات التي لم يتم نشرها بعد في بيئة الإنتاج. لكنهم جميعًا يتشاركون نفس قاعدة الشيفرة، مما يجعلهم قابلين للتعريف كعمليات نشر مختلفة لنفس التطبيق.
@@ -0,0 +1,14 @@
+## VIII. التزامن (Concurrency)
+### التوسع عبر نموذج العمليات
+
+يتم تمثيل أي برنامج كمبيوتر، بمجرد تشغيله، بعملية واحدة أو أكثر. اتخذت تطبيقات الويب مجموعة متنوعة من أشكال تنفيذ العمليات. على سبيل المثال، تعمل عمليات PHP كعمليات فرعية لـ Apache، يتم تشغيلها عند الطلب حسب الحاجة حسب حجم الطلبات. تتخذ عمليات Java النهج المعاكس، حيث يوفر JVM عملية ضخمة شاملة تحجز كتلة كبيرة من موارد النظام (وحدة المعالجة المركزية والذاكرة) عند بدء التشغيل، مع إدارة التزامن داخليًا عبر الخيوط (threads). في كلتا الحالتين، تكون العملية (العمليات) الجارية مرئية بشكل ضئيل فقط لمطوري التطبيق.
+
+![يتم التعبير عن التوسع كعمليات قيد التشغيل، ويتم التعبير عن تنوع أعباء العمل كأنواع عمليات.](/images/process-types.png)
+
+**في تطبيق العوامل الاثني عشر، العمليات هي عناصر من الدرجة الأولى.** تأخذ العمليات في تطبيق العوامل الاثني عشر إشارات قوية من [نموذج عمليات يونكس لتشغيل خدمات النظام الخفية (daemons)](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). باستخدام هذا النموذج، يمكن للمطور هندسة تطبيقه للتعامل مع أعباء العمل المتنوعة عن طريق تعيين كل نوع من العمل إلى *نوع عملية*. على سبيل المثال، قد تتم معالجة طلبات HTTP بواسطة عملية ويب، والمهام الخلفية طويلة الأمد بواسطة عملية عامل (worker).
+
+لا يستبعد هذا العمليات الفردية من التعامل مع تعدد الإرسال الداخلي الخاص بها، عبر خيوط داخل VM وقت التشغيل، أو النموذج غير المتزامن/المدفوع بالأحداث الموجود في أدوات مثل [EventMachine](https://github.com/eventmachine/eventmachine)، [Twisted](http://twistedmatrix.com/trac/)، أو [Node.js](http://nodejs.org/). لكن VM الفردي يمكن أن ينمو فقط إلى حد معين (توسع رأسي)، لذلك يجب أن يكون التطبيق قادرًا أيضًا على الامتداد عبر عمليات متعددة تعمل على أجهزة مادية متعددة.
+
+تبرز قوة نموذج العملية حقًا عندما يحين وقت التوسع. تعني طبيعة [لا تشارك شيئًا، القابلة للتقسيم أفقيًا لعمليات تطبيق العوامل الاثني عشر](./processes) أن إضافة المزيد من التزامن هي عملية بسيطة وموثوقة. تُعرف مصفوفة أنواع العمليات وعدد العمليات من كل نوع بـ *تشكيلة العمليات*.
+
+عمليات تطبيق العوامل الاثني عشر [لا يجب أن تعمل كخدمات خفية (daemonize) أبدًا](http://dustin.github.com/2010/02/28/running-processes.html) أو تكتب ملفات PID. بدلاً من ذلك، اعتمد على مدير عمليات نظام التشغيل (مثل [systemd](https://www.freedesktop.org/wiki/Software/systemd/)، أو مدير عمليات موزع على منصة سحابية، أو أداة مثل [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) في التطوير) لإدارة [تدفقات الإخراج](./logs)، والاستجابة للعمليات المعطلة، والتعامل مع عمليات إعادة التشغيل والإغلاق التي يبدأها المستخدم.