heroku · Erfankam · Apr 27, 2024 · Apr 28, 2024 · Apr 29, 2024 · Apr 30, 2024
@@ -9,3 +9,4 @@ gem 'maruku'
 gem 'i18n'
 gem 'rack-ssl-enforcer'
 gem 'rexml'
+gem 'rtl'
@@ -18,6 +18,7 @@ GEM
     rack-ssl-enforcer (0.2.9)
     rexml (3.3.2)
       strscan
+    rtl (0.6.0)
     ruby2_keywords (0.0.5)
     sinatra (3.2.0)
       mustermann (~> 3.0)
@@ -40,6 +41,7 @@ DEPENDENCIES
   maruku
   rack-ssl-enforcer
   rexml
+  rtl
   sinatra
   thin
 

@@ -0,0 +1,14 @@
+## XII. فرآیندهای مدیریتی
+### وظایف مدیریتی/نگهداری را با پردازه‌های یکبار مصرف اجرا کنید
+
+[مدل پردازش](./concurrency) آرایه‌ای از پردازه‌هایی است که برای انجام کارهای عادی برنامه (مانند رسیدگی به درخواست‌های وب) در حین اجرا استفاده می شود. به طور جداگانه، توسعه‌دهندگان اغلب مایلند کارهای مدیریتی یا نگهداری نرم‌افزار را برای برنامه انجام دهند، مانند:
+
+* اجرای مهاجرت‌های پایگاه‌داده (به عنوان مثال `manage.py migrate` در Django و `rake db:migrate` در Rails).
+* اجرای یک خط فرمان (که به عنوان پوسته [REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop) نیز شناخته می شود) برای اجرای کد دلخواه یا بازرسی مدل‌های برنامه در برابر پایگاه‌داده‌ی عملیاتی. اکثر زبان‌ها با اجرای مفسر بدون هیچ آرگومان (مانند `python` یا `perl`) یک REPL ارائه می‌کنند یا در برخی موارد دارای یک فرمان جداگانه هستند (مانند `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` استفاده کند. به همین ترتیب، یک برنامه‌ی پایتون با استفاده از Virtualenv باید از `bin/python` آن کتابخانه برای اجرای هر دو وب سرور Tornado و هر فرآیند مدیریتی `manage.py` استفاده کند.
+
+دوازده-سازه به شدت طرفدار زبان‌هایی است که پوسته REPL بدون نیاز به ابزار جانبی ارائه می‌دهند و اجرای اسکریپت‌های یکباره را آسان می کنند. در یک استقرار داخلی، توسعه‌دهندگان فرآیندهای مدیریت یکباره را با یک فرمان پوسته مستقیم در مسیر پوشه‌ی وارسی برنامه فراخوانی می‌کنند. در استقرار عملیاتی، توسعه‌دهندگان می‌توانند از 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">الگوهای معماری برنامه‌های کاربردی سازمانی</a >* و *<a href="https://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C" target="_blank">بازسازی</a>* الهام گرفته شده است.
@@ -0,0 +1,15 @@
+## IV. خدمات پشتیبان
+### سرویس‌های پشتیبان را به عنوان منابع پیوست تلقی کنید
+
+*سرویس پشتیبان* هر سرویسی است که برنامه از طریق شبکه به عنوان بخشی از عملکرد عادی خود استفاده می‌کند، از این بین می‌توان پایگاه‌داده‌ها (مانند [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 های قابل دسترس برای مشتری‌ها (مانند [توئیتر](http://dev.twitter.com/)، [Google Maps](https://developers.google.com/maps/)، یا [Last.fm](http://www.last.fm/api )) از دست هستند.
+
+**کد یک برنامه‌ی دوازده-سازه، هیچ تمایزی بین خدمات ارائه‌شده توسط سامانه‌های داخلی و سرویس‌دهنده‌های بیرونی ایجاد نمی کند.** از دید برنامه‌ی کاربردی، هر دو نوع این سرویس‌ها، منابع پیوست‌شده‌ی سامانه هستند که از طریق یک URL یا از طریق نشانی/اطلاعات محرمانه در [config](./config) برنامه قابل دسترسی هستند. یک [deploy](./codebase) از برنامه دوازده-سازه باید بتواند یک پایگاه داده‌ی داخلی MySQL را با پایگاه‌داده‌ای که توسط شخص ثالث مدیریت می‌شود (مانند [Amazon RDS](http://aws.amazon.com/rds/)) تعویض کند، بدون این‌که هیچ تغییری در کد برنامه اعمال شود. به همین ترتیب، یک سرور SMTP داخلی را می توان با یک سرویس SMTP شخص ثالث (مانند Postmark) بدون تغییر کد جا به جا کرد. در هر دو مورد، تنها موردی که باید دچار تغییر شود، نشانی دسترسی به منبع پیوست‌شده است.
+
+هر سرویس پشتیبان مجزا، یک *منبع* است. به عنوان مثال، پایگاه داده‌ی MySQL یک منبع است. دو پایگاه داده MySQL (که برای اشتراک گذاری در لایه‌ی برنامه استفاده می شود) به عنوان دو منبع مجزا واجد شرایط هستند. برنامه دوازده-سازه این پایگاه‌های داده را به‌عنوان *منابع پیوست‌شده* در نظر می‌گیرد، که نشان‌دهنده اتصال ضعیف آن‌ها به استقراری است که در آن اجرا شده‌اند.
+
+<img src="/images/attached-resources.png" class="full" alt="یک محیط استقرار که چهار سرویس پشتیبان به آن متصل شده‌اند." />
+
+منابع را می‌توان به دلخواه به محیط‌های استقرار متصل کرد و از آنها جدا کرد. به عنوان نمونه اگر پایگاه‌داده‌ی برنامه به دلیل مشکل سخت افزاری به درستی پاسخ درخواست‌ها را ندهد، مدیر برنامه ممکن است سرور پایگاه‌داده‌ی جدیدی را که از یک نسخه پشتیبان اخیر بازیابی شده است، جایگزین کند. پایگاه‌داده‌ی عملیاتی کنونی را می توان جدا کرد، و پایگاه‌داده‌ی جدید را بدون هیچ تغییری در کد به برنامه پیوست کرد.
+
@@ -0,0 +1,18 @@
+## V. ساخت، انتشار، اجرا
+### مراحل ساخت و اجرا را کاملاً جدا کنید
+
+یک [کد منبع](./codebase) طی سه مرحله به یک استقرار عملیاتی (غیر توسعه‌ای) تبدیل می‌شود:
+
+* مرحله‌ی *ساخت*، تبدیلی است که مخزن کد را به یک بسته‌ی اجرایی معروف به *build* تبدیل می کند. با استفاده از نسخه‌ای از کد در یک commit مشخص‌شده توسط فرآیند استقرار در مرحله ساخت، وابستگی‌ها را [وابستگی‌ها] (./dependencies) را دریافت می‌کند و باینری‌ها و  منابع را کامپایل می‌کند.
+* مرحله‌ی *انتشار*، خروجی تولید‌شده توسط مرحله‌ی ساخت را می‌گیرد و آن را با [پیکربندی](./config) فعلی محیط استقرار ترکیب می‌کند. *انتشار* حاصل‌شده، شامل ساخت و پیکربندی است و برای اجرای فوری در محیط اجرا آماده است.
+* مرحله‌ی *اجرا*، (که به عنوان "زمان اجرا" نیز شناخته می‌شود) برنامه را در محیط عملیاتی  با راه‌اندازی مجموعه‌ای از [فرآیندهای](./processes) برنامه در برابر نسخه‌ی انتخاب‌شده. اجرا می‌کند،
+
+![کد منبع به یک بسته تبدیل می‌شود که با پیکربندی ترکیب شده تا یک نسخه ایجاد شود.](/images/release.png)
+
+**برنامه دوازده-سازه از جداسازی دقیق بین مراحل ساخت، انتشار و اجرا استفاده می‌کند.** به عنوان مثال، ایجاد تغییرات در کد در زمان اجرا غیرممکن است، زیرا هیچ راهی برای انتشار مجدد این تغییرات به مرحله‌ی  ساخت وجود ندارد.
+
+ابزارهای استقرار که معمولاً ابزارهای مدیریت انتشار نیز نامیده می‌شوند، توانایی بازگشت به نسخه‌ی پیشین اسقراریافته را ارائه می‌دهند. برای مثال، ابزار استقرار [Capistrano](https://github.com/capistrano/capistrano/wiki) نسخه‌ها را در زیر شاخه‌ای به نام `releases` ذخیره می‌کند و نسخه‌ی کنونی در واقع یک پیوند نمادین به فهرست انتشار حال حاضر است. دستور `rollback` در این ابزار، بازگشت سریع به نسخه‌ی  پیشین را آسان می‌کند.
+
+هر نسخه باید همیشه یک شناسه‌ی انتشار منحصر به فرد، مانند مهر زمانی انتشار (مانند `2011-04-06-20:32:17`) یا یک عدد افزایشی (مانند `v100`) داشته باشد. نسخه‌ها فقط یک دفتر کل پیوست‌شده هستند و یک نسخه پس از ایجاد، نمی‌بایست دچار تغییر شود. برای هر تغییری باید یک نسخه‌ی جدید ایجاد شود.
+
+هر زمان که کد جدیدی ایجاد شود و نیاز به عملیاتی‌سازی داشته باشد، مراحل ساخت توسط توسعه‌دهندگان برنامه آغاز می‌شود. در مقابل، اجرای آن می تواند به طور خودکار مانند راه‌اندازی مجدد سرور، یا راه‌اندازی مجدد فرآیند از کار افتاده توسط مدیر فرآیند انجام شود. بنابراین، مرحله‌ی اجرا باید تا حد امکان در قسمت‌های متغیر کمتری نگه داشته شود، زیرا مشکلاتی که مانع از اجرای برنامه می‌شوند، می‌توانند باعث خرابی آن در نیمه‌های شب و زمانی که هیچ توسعه‌دهنده‌ای در دسترس نیست، شود. مرحله ساخت می‌تواند پیچیده‌تر باشد، زیرا خطاها همیشه در پیش‌روی توسعه‌دهنده‌هایی هستند که مراحل توسعه را هدایت می‌کنند.
@@ -0,0 +1,17 @@
+## I. کد منبع
+### یک مخزن کد که با سیستم کنترل نسخه ردیابی می‌شود، در محیط‌های متعدد مستقر کنید
+
+یک برنامه‌کاربردی دوازده-سازه همیشه در یک سیستم کنترل نسخه، مانند [Git](http://git-scm.com/)، [Mercurial](https://www.mercurial-scm.org/) یا [Subversion](http://subversion.apache.org/) ردیابی می شود. یک رونوشت از پایگاه داده  تحت سیستم کنترل نسخه، *مخزن کد* نامیده می شود که اغلب به *مخزن کد* یا فقط *repo* کوتاه می‌شود.
+
+یک *codebase* هر مخزن کد یکتا (در یک سیستم کنترل نسخه‌ی متمرکز مانند Subversion) یا هر مجموعه‌ای از مخازن کد (در یک سیستم کنترل نسخه‌ی غیرمتمرکز مانند Git) است که یک مسیر توسعه‌ی ریشه‌ی مشترک دارند .
+
+![One codebase به بسیاری از Deploys نقشه می‌دهد](/images/codebase-deploys.png)
+
+همیشه یک تناظر یک به یک بین مخزن کد و برنامه‌ی کاربردی وجود دارد:
+
+* اگر چندین مخزن کد وجود دارد، این یک برنامه نیست -- یک سیستم توزیع شده است. هر مؤلفه در یک سیستم توزیع‌شده یک برنامه است و هر یک به تنهایی می تواند با مؤلفه‌های دوازده-سازه مطابقت داشته باشد.
+* برنامه‌های متعددی که یک کد منبع را به اشتراک می گذارند، ناقض اصول برنامه‌ی دوازده-سازه است. راه حل در اینجا این است که کدهای مشترک را در کتابخانه‌هایی به اشتراک بگذارید که می‌توانند از طریق [مدیریت وابستگی‌ها](./dependencies) به کار گرفته شوند.
+
+تنها یک مخزن کد در هر برنامه وجود دارد، اما نمونه‌های زیادی از این برنامه اجرا خواهند شد. هر *استقرار* یک نمونه در حال اجرا از برنامه است. این معمولاً یک محیط عملیاتی و یک یا چند محیط آزمون است. علاوه بر این، هر توسعه‌دهنده یک نمونه از برنامه‌ی کاربردی در حال اجرا در محیط توسعه‌ی محلی خود دارد، که هر کدام نیز واجد شرایط استقرار هستند.
+
+مخزن کد در همه استقرارها یکسان است، اگرچه ممکن است نسخه‌های مختلفی در هر استقرار فعال باشد. برای مثال، یک توسعه‌دهنده تغییراتی دارد که هنوز در محیط آزمون اجرا نشده‌اند. محیط آزمون دارای تغییراتی است که هنوز برای استقرار عملیاتی اجرا نشده است. اما همه آنها از یک پایگاه کد مشترک استفاده می کنند که همه‌ی آن‌ها را به عنوان استقرارهای مختلف یک برنامه قابل شناسایی می کند.