+
+ | نوع |
+ زبان |
+ کتابخانه |
+ تطبیق‌دهنده |
+
+
+ | پایگاه داده |
+ روبی/ریل |
+ ActiveRecord |
+ MySQL، PostgreSQL، SQLite |
+
+
+ | صف |
+ Python/Django |
+ Celery |
+ RabbitMQ، Beanstalkd، Redis |
+
+
+ | حافظه پنهان |
+ روبی/ریل |
+ ActiveSupport::Cache |
+ حافظه، سیستم فایل، Memcached |
+
+
+
+توسعه‌دهندگان گاهی اوقات علاقه‌ی زیادی در استفاده از یک سرویس پشتیبان کوچک در محیط های توسعه‌ی خود پیدا می‌کنند، در حالی که یک سرویس پشتیبان جدی‌تر و قوی‌تر در محیط عملیات استفاده می‌شود. به عنوان مثال، استفاده از SQLite در محیط توسعه و PostgreSQL در محیط عملیات. یا حافظه‌ی سیستم برای ذخیره سازی در توسعه و Memcached در عملیات.
+
+**توسعه‌دهنده‌ی برنامه‌ی کاربردی دوازده-سازه در برابر اصرار برای استفاده از خدمات پشتیبان مختلف بین توسعه و عملیات مقاومت می‌کند**، حتی زمانی که رابط‌های برنامه‌نویسی از نظر تئوری هرگونه اختلاف در سرویس پشتیبان را از بین می‌برند. تفاوت بین سرویس‌های پشتیبان به این معنی است که ناسازگاری‌های کوچک ظاهر می‌شوند و باعث می‌شوند کدهایی که کار می‌کردند و آزمایش‌هایشان را در مرحله توسعه یا آزمون پشت سر گذاشته‌اند، در عملیات شکست بخورند. این نوع خطاها باعث ایجاد اصطکاک می شود که استقرار مداوم را از بین می‌برد. هزینه این اصطکاک و عدم‌سرویس‌دهی متعاقب آن در استقرار مستمر، در طی طول عمر یک برنامه‌ی کاربردی بسیار زیاد است.
+
+ابزارهای کوچک محیط توسعه، همانند گذشته برای برنامه‌نویسان قانع‌کننده نیستند. نصب و اجرای سرویس‌های پشتیبان مدرن مانند Memcached، PostgreSQL و RabbitMQ به لطف سیستم‌های بسته‌بندی تازه‌وارد مانند [Homebrew](http://mxcl.github.com/homebrew/) و [apt-get]( https://help.ubuntu.com/community/AptGet/Howto) همانند گذشته سخت و طاقت‌فرسا نیست. از طرف دیگر، ابزارهای ارائه اعلامی مانند [Chef](http://www.opscode.com/chef/) و [Puppet](http://docs.puppetlabs.com/) همراه با محیط‌های مجازی کم‌هزینه مانند [ Docker](https://www.docker.com/) و [Vagrant](http://vagrantup.com/) به توسعه‌دهندگان اجازه می‌دهند محیط‌های توسعه‌ای را پیکربندی کنند که تقریباً همانند محیط‌های عملیات هستند. هزینه‌ی نصب و استفاده از این سیستم‌ها در مقایسه با مزیت برابری توسعه/عملیات و استقرار مستقمر بسیار پایین است.
+
+رابط‌های برنامه‌نویسی سرویس‌های پشتیبان مختلف هنوز مفید هستند، زیرا انتقال به سرویس‌های پشتیبان جدید را نسبتاً بدون دردسر می‌سازند. اما همه راه‌اندازی‌های برنامه (محیط‌های توسعه‌دهنده، آزمون و عملیات) باید از یک نوع و نسخه‌ی همانند از هر یک از خدمات پشتیبان استفاده کنند.
\ No newline at end of file
diff --git a/content/fa/disposability.md b/content/fa/disposability.md
new file mode 100644
index 000000000..65e06ff19
--- /dev/null
+++ b/content/fa/disposability.md
@@ -0,0 +1,12 @@
+## IX. دسترس‌پذیری
+### با راه‌اندازی سریع و توقف تدریجی نرم‌افزار، دسترس‌پذیری را به حداکثر برسانید
+
+**[پردازه‌های](./processes) برنامه‌ی دوازده-سازه *یکبار مصرف* هستند، به این معنی که می توان آنها را در یک آن، ایجاد یا متوقف کرد.** این کار مقیاس‌پذیری سریع و منعطف، استقرار سریع [کد](./codebase) یا [پیکربندی](./config) تغییرات و استحکام عملیات را تسهیل می‌کند.
+
+پردازه‌ها می‌بایست **زمان راه اندازی حداقلی داشته باشند**. در حالت ایده‌آل، یک پردازه از زمان اجرای دستور راه‌اندازی، چند ثانیه طول می‌کشد تا آماده‌ی پردازش درخواست‌ها یا کارها شود. زمان راه‌اندازی کوتاه، چابکی بیشتری را برای فرایند [انتشار](./build-release-run) و افزایش مقیاس‌پذیری فراهم می‌کند. و به استحکام برنامه کمک می کند، زیرا مدیر سیستم در صورت لزوم می‌تواند به راحتی پردازه‌ها را به ماشین‌های فیزیکی جدید منتقل کند.
+
+پردازه‌ها هنگامی که **سیگنال [SIGTERM](http://en.wikipedia.org/wiki/SIGTERM)** را از مدیر پردازه یا پردازه‌ی اصلی سیستم دریافت می‌کنند، به آرامی خاموش می‌شوند. برای یک پردازه‌ی وب، خاموش شدن تدریجی شامل توقف بررسی درخواست‌های رسیده به درگاه سرویس (و در نتیجه رد هر درخواست جدید)، اجازه دادن به تمام درخواست‌های کنونی و سپس خروج کامل و توقف پردازه به‌دست می‌آید. ضمناً اساس این مدل بر این اصل استوار است که درخواست‌های HTTP کوتاه هستند (کمتر از چند ثانیه)، یا در مورد درخواست‌هایی که به مدت زمان بررسی بیشتری نیاز دارند، سرویس‌گیرنده باید به‌طور یکپارچه تلاش کند تا زمانی که اتصال قطع شد، دوباره اتصال را برقرار کند.
+
+برای یک پردازه‌ی کاری، با برگرداندن کار کنونی فعال به صف کارها، توقف تدریجی حاصل می‌شود. برای مثال، در [RabbitMQ](http://www.rabbitmq.com/) پردازه‌ی فعال، می تواند یک ['NACK'](https://www.rabbitmq.com/amqp-0-9-1-quickref#basic.nack) ارسال کند. در [Beanstalkd](https://beanstalkd.github.io)، هر زمان که یک پردازه‌ی فعال ارتباط خود را قطع کند، کار به طور خودکار به صف باز می‌گردد. سیستم‌های مبتنی بر قفل مانند [Delayed Job](https://github.com/collectiveidea/delayed_job#readme) باید حتماً قفل خود را در فهرست رکوردها، آزاد کنند. به طور ضمنی، این مدل بر اساس این اصل بنا شده که همه فرآیند‌ها [قابلیت توقف در حین اجرا](http://en.wikipedia.org/wiki/Reentrant_%28subroutine%29) دارند ، معمولاً با جمع‌آوری نتایج درخواست در یک تراکنش، یا استفاده از عملیات [با قابلیت تلاش مجدد بدون تأثیر بر نتیجه‌ی نهایی](http://en.wikipedia.org/wiki/Idempotence) به دست می‌آید.
+
+پردازه‌های برنامه‌ی کاربردی همچنین باید **در برابر توقف ناگهانی** در صورت بروز خرابی در سخت‌افزار زیرین مقاوم باشند. در حالی که این اتفاق بسیار نادرتر از یک توقف تدریجی با سیگنال «SIGTERM» است، اما همچنان احتمال رخداد آن وجود دارد. یک رویکرد توصیه‌شده استفاده از یک مکانیزم صف قوی، مانند Beanstalkd است، که در صورت قطع اتصال مشتریان یا پایان مهلت سرویس‌گیرنده برای دریافت پاسخ، کارها را به صف باز می گرداند. در هر صورت، یک برنامه‌ی دوازده-سازه برای مدیریت توقف‌های غیرمنتظره و غیر تدریجی طراحی شده است. [نتایج منطقی](http://docs.couchdb.org/en/latest/intro/overview.html) حاصل از این مفهموم در [طراحی شکست‌محور](http://lwn.net/Articles/191059/) ظاهر می‌شود.
\ No newline at end of file
diff --git a/content/fa/intro.md b/content/fa/intro.md
new file mode 100644
index 000000000..ab66132ac
--- /dev/null
+++ b/content/fa/intro.md
@@ -0,0 +1,12 @@
+معرفی
+=============
+
+در عصر مدرن، نرم‌افزار معمولاً به عنوان یک سرویس به نام *برنامه‌های کاربردی تحت وب* یا *نرم‌افزار به عنوان سرویس* ارائه می شود. برنامه‌ی کاربردی دوازده-سازه روشی برای ساخت برنامه‌های کاربردی نرم‌افزاری به عنوان سرویس است که:
+
+* از قالب‌های **قابل توصیف** برای خودکارسازی راه‌اندازی استفاده می‌کند تا زمان و هزینه را برای توسعه‌دهندگان جدیدی که به پروژه می پیوندند به حداقل برساند.
+* یک **قرارداد تمیز** با سیستم عامل میزبان دارد تا **حداکثر قابلیت حمل** را بین محیط‌های اجرا ارائه دهد.
+* برای **استقرار** در **سکوهای ابری مدرن**، بدون نیاز به سرورها و مدیریت سیستم‌ها مناسب است.
+* **واگرایی** بین توسعه و عملیات را به حداقل می‌رساند تا **استقرار مستمر**، حداکثر چابکی را به ارمغان آورد.
+* و می‌تواند بدون تغییر قابل توجه در ابزار، معماری یا شیوه‌های توسعه، **مقیاس‌پذیر** شود.
+
+روش دوازده-سازه را می توان برای برنامه‌هایی که به هر زبان برنامه‌نویسی نوشته شده‌اند و از هر ترکیبی از خدمات پشتیبان (پایگاه داده، صف، کش حافظه و غیره) استفاده می‌کنند، اعمال کرد.
diff --git a/content/fa/logs.md b/content/fa/logs.md
new file mode 100644
index 000000000..7bd3fc967
--- /dev/null
+++ b/content/fa/logs.md
@@ -0,0 +1,16 @@
+## XI. رویدادنویسی
+### رویدادنویسی را به عنوان جریانی از رویدادها در نظر بگیرید
+
+رویدادنویسی، عملکرد یک برنامه‌ی در حال اجرا را مشاهده می‌کند. در محیط‌های مبتنی بر سرور، این مشاهدات معمولاً روی یک فایل روی دیسک (یک "logfile") نوشته می‌شوند. اما این فقط یکی از قالب‌های خروجی است.
+
+رویدادنوشته‌ها، جریان رویدادهای انباشته‌شده با ترتیب زمانی هستند که از جریان‌های خروجی همه‌ی فرآیندهای در حال اجرا و خدمات پشتیبان جمع‌آوری شده‌اند. رویدادنوشته‌ها در شکل خام خود معمولاً یک قالب متنی با یک رویداد در هر خط هستند (اگرچه رهگیری پشته‌ای از خطاها ممکن است چندین خط را در بر بگیرد). رویدادنوشته‌ها آغاز یا پایان ثابتی ندارند، اما تا زمانی که برنامه کار می‌کند، پیوسته جریان دارند.
+
+**یک برنامه‌ی کاربردی دوازده-سازه هرگز به مسیریابی یا ذخیره‌سازی جریان خروجی خود اهمیت نمی دهد**. نباید سعی در نوشتن یا مدیریت فایل‌های رویدادنویسی داشته باشد. در عوض، هر فرآیند در حال اجرا، جریان رویداد خود را بدون بافر در «stdout» می‌نویسد. در محیط توسعه، توسعه‌دهنده این جریان را در پیش‌زمینه ترمینال خود می‌بیند تا رفتار برنامه را مشاهده کند.
+
+در استقرار محیط آزمون یا عملیات، جریان هر فرآیند توسط محیط اجرا ثبت می‌شود، با تمام جریان‌های رویدادنویسی دیگر از برنامه ترکیب می‌شود و برای مشاهده و بایگانی طولانی‌مدت به یک یا چند مقصد نهایی هدایت می‌شود. این مقاصد بایگانی‌شده، برای برنامه، قابل مشاهده یا تنظیم نیستند و در عوض کاملاً توسط محیط اجرا، مدیریت می‌شوند. مسیریاب‌های رویدادنویسی منبع باز (مانند Logplex و Fluentd) برای این منظور در دسترس هستند.
+
+جریان رویداد برای یک برنامه را می توان به یک فایل هدایت کرد یا از طریق `tail` در یک ترمینال مشاهده کرد. مهمتر از همه، جریان را می توان به یک سیستم نمایه‌سازی و تجزیه و تحلیل رویدادنویسی مانند Splunk، یا یک سیستم انبار داده‌های همه منظوره مانند [Hadoop/Hive](http://hive.apache.org/) سپرد. این سیستم‌ها قدرت و انعطاف‌پذیری زیادی را برای بررسی رفتار یک برنامه در طول زمان فراهم می‌کنند، از جمله:
+
+* یافتن رویدادهای ویژه در گذشته.
+* نمودارهایی در مقیاس بزرگ از روندهای برنامه (مانند درخواست در دقیقه).
+* هشدار فعال با توجه به هشدار تعریف شده توسط کاربر (مانند هشدار در زمانی که تعداد خطاها در دقیقه از یک آستانه ویژه فراتر رود).
\ No newline at end of file
diff --git a/content/fa/port-binding.md b/content/fa/port-binding.md
new file mode 100644
index 000000000..41582f3cb
--- /dev/null
+++ b/content/fa/port-binding.md
@@ -0,0 +1,14 @@
+## VII. درگاه‌های شبکه
+### سرویس‌های نرم‌افزار را از طریق درگاه‌های شبکه ارائه کنید
+
+برنامه های وب گاهی اوقات در داخل یک کانتینر وب سرور اجرا می‌شوند. به عنوان مثال، برنامه های PHP ممکن است به عنوان یک ماژول در داخل [Apache HTTPD](http://httpd.apache.org/) اجرا شوند، یا برنامه‌های جاوا ممکن است در داخل [Tomcat](http://tomcat.apache.org/) اجرا شوند.
+
+**برنامه‌ی کاربردی دوازده‌سازه کاملاً مستقل است** و برای ارائه‌ی یک وب‌سرویس روی یک درگاه، نیازی به وجود وب‌سرور در زمان اجرا ندارد. برنامه‌ی وب **HTTP را به عنوان یک سرویس با اتصال به یک درگاه** و گوش دادن به درخواست هایی که برای آن ارسال می‌شود، ارائه می‌کند.
+
+در محیط توسعه، توسعه‌دهنده از یک URL سرویس مانند «http://localhost:5000/» استفاده می‌کند تا به سرویس ارائه‌شده توسط برنامه‌ی خود دسترسی پیدا کند. در عملیات، یک لایه‌ی مسیریابی، درخواست‌های مسیریابی از نام میزبان عمومی قابل دسترس برای مشتریان بیرونی را به پردازه‌های وب متصل به درگاه برنامه‌ی کاربردی مدیریت می کند.
+
+این کار معمولاً با استفاده از [اعلام وابستگی‌ها](./dependencies) برای افزودن یک کتابخانه‌ی وب‌سرور به برنامه‌ی کاربردی، مانند [Tornado](http://www.tornadoweb.org/) برای Python، کتابخانه‌ی [Thin](http://code.macournoyer.com/thin/) برای Ruby یا [Jetty](http://www.eclipse.org/jetty/) برای جاوا و سایر زبان‌های مبتنی بر JVM. این امر به طور کامل در *فضای کاربر*، یعنی در داخل کد برنامه اجرا می‌شود. قراردادی که برنامه‌ی کاربردی با محیط اجرای برنامه یا سیستم عامل دارد، ارائه‌ی یک درگاه شبکه برای دریافت درخواست‌ها است.
+
+HTTP تنها سرویسی نیست که می توان بر روی درگاه شبکه ارائه کرد. تقریباً هر نوع نرم‌افزار سرور را می‌توان از طریق درگاه شبکه و انتظار برای درخواست‌های دریافتی اجرا نمود. نمونه‌ها عبارتند از [ejabberd](http://www.ejabberd.im/) (ارتباط با [پروتکل XMPP](http://xmpp.org/)) و [Redis](http://redis.io/) (ارتباط با [پروتکل Redis](http://redis.io/topics/protocol)).
+
+همچنین توجه داشته باشید که رویکرد اتصال درگاه به این معنی است که یک برنامه می‌تواند با ارائه URL به برنامه‌ی دیگر به عنوان یک منبع ارائه‌دهنده در [پیکربندی](./backing-services) برای برنامه‌ی دیگر به [ارائه‌دهنده‌ی سرویس](./backing-services) تبدیل شود.
\ No newline at end of file
diff --git a/content/fa/processes.md b/content/fa/processes.md
new file mode 100644
index 000000000..72d6db827
--- /dev/null
+++ b/content/fa/processes.md
@@ -0,0 +1,14 @@
+## VI. پردازه‌ها
+### برنامه را به عنوان یک یا چند پردازه‌ی بدون حالت واسط اجرا کنید
+
+برنامه‌ی کاربردی در محیط اجرا به صورت یک یا چند *پردازه* بر روی سیستم عامل اجرا می‌شود.
+
+در ساده‌ترین حالت، کد یک اسکریپت مستقل است، محیط اجرا یک لپ‌تاپ توسعه‌دهنده با مفسر یا کامپایلر زبان برنامه‌نویسی نصب‌شده است، و پردازه از طریق خط فرمان (به عنوان مثال، «python my_script.py») راه‌اندازی می‌شود. در سوی دیگر، استقرار در عملیات برای برنامه‌های پیچیده، ممکن است از بسیاری از [انواع فرآیند که در تعدادی از صفر و یا بیشتر پردازه‌ی در حال اجرا تشکیل شده است](./concurrency)، استفاده کند.
+
+**پردازه‌های یک برنامه‌ی کاربردی دوازده-سازه، بدون حالت (stateless) و [اشتراک هیچ منبعی](http://en.wikipedia.org/wiki/Shared_nothing_architecture) هستند.** هر داده‌ای که نیاز به ماندگاری دارد، باید در یک [سرویس پشتیبان](./backing-services) مانا، مانند یک پایگاه‌داده ذخیره شود.
+
+فضای حافظه یا فایل سیستم فرآیند را می توان به عنوان یک کش مختصر و تک‌تراکنش استفاده کرد. به عنوان نمونه، می‌توان به دریافت یک فایل بزرگ، عملیات بر روی آن و ذخیره‌ی نتایج عملیات در پایگاه‌داده اشاره کرد. برنامه‌ی دوازده-سازه هرگز فرض نمی‌کند که هر چیزی که در حافظه نهان یا روی دیسک ذخیره شده است، به وسیله‌ی یک درخواست یا پردازش در آینده در دسترس خواهد بود -- با اجرای بسیاری از پردازه‌ها از هر نوع، احتمال اینکه درخواست آینده توسط یک پردازه‌ی متفاوت ارائه شود، بسیار زیاد است. حتی زمانی که فقط یک پردازه را اجرا می‌کنید، یک راه‌اندازی مجدد (با استقرار کد، تغییر پیکربندی یا محیط اجرا که فرآیند را به مکان فیزیکی دیگری منتقل می‌کند) معمولاً تمام حالت‌های داخلی سیستم (مانند حافظه و سیستم فایل) را از بین می‌برد و یا تغییر می‌دهد.
+
+بسته‌بندی‌کننده‌ی منابع مانند [django-assetpackager](http://code.google.com/p/django-assetpackager/) از سیستم فایل به عنوان حافظه‌ی پنهان برای کدهای کامپایل‌شده استفاده می‌کنند. یک برنامه‌ی دوازده-سازه ترجیح می دهد، این کامپایل را در طول [مراحل ساخت](/build-release-run) انجام دهد. بسته‌بندی‌کننده‌های منابع مانند [Jammit](http://documentcloud.github.io/jammit/) و [Rails asset pipeline](http://ryanbigg.com/guides/asset_pipeline.html) را می‌توان برای بسته از منابع و کتابخانه‌های مراحل ساخت پیکربندی کرد.
+
+برخی از سیستم‌های وب به ["نشست‌های دارای حالت"](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence) متکی هستند -- یعنی داده‌های نشست کاربر در حافظه‌ی پردازه‌ی برنامه ذخیره می‌شود و انتظار درخواست آینده از همان بازدید‌کننده برای هدایت به همان فرآیند وجود دارد. نشست‌های این‌چنینی ناقض اصول دوازده-سازه است و هرگز نباید از آنها استفاده کرد یا به آنها اعتماد کرد. داده‌های حالت یک نشست، نامزدهای خوبی برای ذخیره‌سازی داده در پایگاه‌داده‌هایی مانند [Memcached](http://memcached.org/) یا [Redis](http://redis.io/) است که امکان انقضای داده را می‌دهند.
\ No newline at end of file
diff --git a/content/fa/toc.md b/content/fa/toc.md
new file mode 100644
index 000000000..249828580
--- /dev/null
+++ b/content/fa/toc.md
@@ -0,0 +1,38 @@
+دوازده-سازه
+===================
+
+## [I. کد منبع](./codebase)
+### یک مخزن کد که با سیستم کنترل نسخه ردیابی می‌شود، در محیط‌های متعدد مستقر کنید
+
+## [II. وابستگی‌ها](./dependencies)
+### وابستگی‌ها را به صراحت اعلام و جدا کنید
+
+## [III. پیکربندی‌ها](./config)
+### پیکربندی‌ها را در محیط ذخیره کنید
+
+## [IV. سرویس‌های پشتیبان](./backing-services)
+### خدمات پشتیبان را به عنوان منابع همراه نرم‌افزار تلقی کنید
+
+## [V. ساخت، انتشار، اجرا](./build-release-run)
+### مراحل ساخت و اجرا را کاملاً از هم جدا کنید
+
+## [VI. پردازه‌ها](./processes)
+### برنامه را به عنوان یک یا چند پردازه‌ی بدون حالت واسط اجرا کنید
+
+## [VII. درگاه‌های شبکه](./port-binding)
+### سرویس‌های نرم‌افزار را از طریق درگاه‌های شبکه ارائه کنید
+
+## [VIII. همزمانی](./concurrency)
+### از طریق مدل پردازه مقیاس‌پذیری را افزایش دهید
+
+## [IX. دسترس‌پذیری](./disposability)
+### با راه‌اندازی سریع و توقف تدریجی نرم‌افزار، دسترس‌پذیری را به حداکثر برسانید
+
+## [X. برابری توسعه/عملیات](./dev-prod-parity)
+### محیط توسعه، آزمون و عملیات را تا حد امکان همانند هم نگه دارید
+
+## [XI. رویدادنویسی](./logs)
+### رویدادنویسی را به‌عنوان جریانی از رویدادها در نظر بگیرید
+
+## [XII. فرآیندهای مدیریتی](./admin-processes)
+### وظایف مدیریتی/نگهداری را با پردازه‌های یکبار مصرف اجرا کنید
\ No newline at end of file
diff --git a/content/fa/who.md b/content/fa/who.md
new file mode 100644
index 000000000..b8a87a6d0
--- /dev/null
+++ b/content/fa/who.md
@@ -0,0 +1,4 @@
+چه کسی باید این سند را بخواند؟
+==============================
+
+هر برنامه‌نویسی که برنامه‌های کاربردی را می‌سازد که به‌عنوان یک سرویس اجرا می‌شوند. مهندسان عملیاتی که چنین برنامه‌هایی را مستقر یا مدیریت می‌کنند.
\ No newline at end of file
diff --git a/locales/fa.yml b/locales/fa.yml
new file mode 100644
index 000000000..0a2547b5e
--- /dev/null
+++ b/locales/fa.yml
@@ -0,0 +1,7 @@
+fa:
+ # Name of language listed in locales menu
+ language: "فارسی (fa)"
+
+ # A text to make known that the article is a translation not an original.
+ # Empty for English, original.
+ translation: "این نوشتار، یک برگردان است."
diff --git a/public/css/screen.css b/public/css/screen.css
index f9b41152f..9f12136b7 100644
--- a/public/css/screen.css
+++ b/public/css/screen.css
@@ -175,6 +175,14 @@ article img.full {
margin-right: 5px;
}
+article.rtl {
+ direction: rtl;
+}
+
+article.ltr {
+ direction: ltr;
+}
+
.header-container {
position: relative;
justify-content: space-between;
diff --git a/views/factor.erb b/views/factor.erb
index 404a0bd01..7844870d7 100644
--- a/views/factor.erb
+++ b/views/factor.erb
@@ -1,5 +1,5 @@
+
+منابع را می‌توان به دلخواه به محیط‌های استقرار متصل کرد و از آنها جدا کرد. به عنوان نمونه اگر پایگاه‌داده‌ی برنامه به دلیل مشکل سخت افزاری به درستی پاسخ درخواست‌ها را ندهد، مدیر برنامه ممکن است سرور پایگاه‌داده‌ی جدیدی را که از یک نسخه پشتیبان اخیر بازیابی شده است، جایگزین کند. پایگاه‌داده‌ی عملیاتی کنونی را می توان جدا کرد، و پایگاه‌داده‌ی جدید را بدون هیچ تغییری در کد به برنامه پیوست کرد.
+
diff --git a/content/fa/build-release-run.md b/content/fa/build-release-run.md
new file mode 100644
index 000000000..26699beea
--- /dev/null
+++ b/content/fa/build-release-run.md
@@ -0,0 +1,18 @@
+## V. ساخت، انتشار، اجرا
+### مراحل ساخت و اجرا را کاملاً جدا کنید
+
+یک [کد منبع](./codebase) طی سه مرحله به یک استقرار عملیاتی (غیر توسعه‌ای) تبدیل می‌شود:
+
+* مرحله‌ی *ساخت*، تبدیلی است که مخزن کد را به یک بسته‌ی اجرایی معروف به *build* تبدیل می کند. با استفاده از نسخه‌ای از کد در یک commit مشخص‌شده توسط فرآیند استقرار در مرحله ساخت، وابستگی‌ها را [وابستگی‌ها] (./dependencies) را دریافت می‌کند و باینری‌ها و منابع را کامپایل می‌کند.
+* مرحله‌ی *انتشار*، خروجی تولید‌شده توسط مرحله‌ی ساخت را می‌گیرد و آن را با [پیکربندی](./config) فعلی محیط استقرار ترکیب می‌کند. *انتشار* حاصل‌شده، شامل ساخت و پیکربندی است و برای اجرای فوری در محیط اجرا آماده است.
+* مرحله‌ی *اجرا*، (که به عنوان "زمان اجرا" نیز شناخته می‌شود) برنامه را در محیط عملیاتی با راه‌اندازی مجموعه‌ای از [فرآیندهای](./processes) برنامه در برابر نسخه‌ی انتخاب‌شده. اجرا می‌کند،
+
+
+
+**برنامه دوازده-سازه از جداسازی دقیق بین مراحل ساخت، انتشار و اجرا استفاده می‌کند.** به عنوان مثال، ایجاد تغییرات در کد در زمان اجرا غیرممکن است، زیرا هیچ راهی برای انتشار مجدد این تغییرات به مرحله‌ی ساخت وجود ندارد.
+
+ابزارهای استقرار که معمولاً ابزارهای مدیریت انتشار نیز نامیده می‌شوند، توانایی بازگشت به نسخه‌ی پیشین اسقراریافته را ارائه می‌دهند. برای مثال، ابزار استقرار [Capistrano](https://github.com/capistrano/capistrano/wiki) نسخه‌ها را در زیر شاخه‌ای به نام `releases` ذخیره می‌کند و نسخه‌ی کنونی در واقع یک پیوند نمادین به فهرست انتشار حال حاضر است. دستور `rollback` در این ابزار، بازگشت سریع به نسخه‌ی پیشین را آسان می‌کند.
+
+هر نسخه باید همیشه یک شناسه‌ی انتشار منحصر به فرد، مانند مهر زمانی انتشار (مانند `2011-04-06-20:32:17`) یا یک عدد افزایشی (مانند `v100`) داشته باشد. نسخه‌ها فقط یک دفتر کل پیوست‌شده هستند و یک نسخه پس از ایجاد، نمی‌بایست دچار تغییر شود. برای هر تغییری باید یک نسخه‌ی جدید ایجاد شود.
+
+هر زمان که کد جدیدی ایجاد شود و نیاز به عملیاتی‌سازی داشته باشد، مراحل ساخت توسط توسعه‌دهندگان برنامه آغاز می‌شود. در مقابل، اجرای آن می تواند به طور خودکار مانند راه‌اندازی مجدد سرور، یا راه‌اندازی مجدد فرآیند از کار افتاده توسط مدیر فرآیند انجام شود. بنابراین، مرحله‌ی اجرا باید تا حد امکان در قسمت‌های متغیر کمتری نگه داشته شود، زیرا مشکلاتی که مانع از اجرای برنامه می‌شوند، می‌توانند باعث خرابی آن در نیمه‌های شب و زمانی که هیچ توسعه‌دهنده‌ای در دسترس نیست، شود. مرحله ساخت می‌تواند پیچیده‌تر باشد، زیرا خطاها همیشه در پیش‌روی توسعه‌دهنده‌هایی هستند که مراحل توسعه را هدایت می‌کنند.
\ No newline at end of file
diff --git a/content/fa/codebase.md b/content/fa/codebase.md
new file mode 100644
index 000000000..8b84ce030
--- /dev/null
+++ b/content/fa/codebase.md
@@ -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) است که یک مسیر توسعه‌ی ریشه‌ی مشترک دارند .
+
+
+
+همیشه یک تناظر یک به یک بین مخزن کد و برنامه‌ی کاربردی وجود دارد:
+
+* اگر چندین مخزن کد وجود دارد، این یک برنامه نیست -- یک سیستم توزیع شده است. هر مؤلفه در یک سیستم توزیع‌شده یک برنامه است و هر یک به تنهایی می تواند با مؤلفه‌های دوازده-سازه مطابقت داشته باشد.
+* برنامه‌های متعددی که یک کد منبع را به اشتراک می گذارند، ناقض اصول برنامه‌ی دوازده-سازه است. راه حل در اینجا این است که کدهای مشترک را در کتابخانه‌هایی به اشتراک بگذارید که می‌توانند از طریق [مدیریت وابستگی‌ها](./dependencies) به کار گرفته شوند.
+
+تنها یک مخزن کد در هر برنامه وجود دارد، اما نمونه‌های زیادی از این برنامه اجرا خواهند شد. هر *استقرار* یک نمونه در حال اجرا از برنامه است. این معمولاً یک محیط عملیاتی و یک یا چند محیط آزمون است. علاوه بر این، هر توسعه‌دهنده یک نمونه از برنامه‌ی کاربردی در حال اجرا در محیط توسعه‌ی محلی خود دارد، که هر کدام نیز واجد شرایط استقرار هستند.
+
+مخزن کد در همه استقرارها یکسان است، اگرچه ممکن است نسخه‌های مختلفی در هر استقرار فعال باشد. برای مثال، یک توسعه‌دهنده تغییراتی دارد که هنوز در محیط آزمون اجرا نشده‌اند. محیط آزمون دارای تغییراتی است که هنوز برای استقرار عملیاتی اجرا نشده است. اما همه آنها از یک پایگاه کد مشترک استفاده می کنند که همه‌ی آنها را به عنوان استقرارهای مختلف یک برنامه قابل شناسایی می کند.
\ No newline at end of file
diff --git a/content/fa/concurrency.md b/content/fa/concurrency.md
new file mode 100644
index 000000000..2fefdd27a
--- /dev/null
+++ b/content/fa/concurrency.md
@@ -0,0 +1,14 @@
+## VIII. همزمانی
+### از طریق مدل پردازه مقیاس‌پذیری را افزایش دهید
+
+هر برنامه‌ی کامپیوتری، پس از اجرا، توسط یک یا چند پردازه نمایش داده‌می شود. برنامه‌های وب، شکل‌های مختلفی برای اجرای فرآیند به خود گرفته‌اند. برای نمونه، پردازه‌های PHP به عنوان پردازه‌های فرزند آپاچی اجرا می‌شوند که بر حسب نیاز بر اساس حجم درخواست ایجاد شده‌اند. پردازه‌های جاوا رویکردی متفاوت دارند. JVM که یک پردازه‌ی مجمتع عظیم را ارائه می‌کند و بلوک بزرگی از منابع سیستم (پردازنده و حافظه) را در هنگام راه‌اندازی ذخیره می‌کند و مدیریت داخلی همزمانی را با استفاده از رشته‌ها انجام می‌دهد. در هر دو مورد، پردازه(ها) ی در حال اجرا، تنها برای توسعه‌دهندگان برنامه قابل مشاهده است.
+
+
+
+**در برنامه‌ی کاربردی دوازده-سازه، پردازه‌ها همانند شهروند درجه یک هستند.** پردازه‌ها در برنامه‌ی دوازده-سازه نشانه‌هایی قوی از [مدل فرآیند یونیکس برای اجرای دیمون‌های سرویس](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/) دارند. با استفاده از این مدل، توسعه‌دهنده می‌تواند با اختصاص دادن هر نوع کار به یک *نوع پردازه*، برنامه‌ی خود را برای مدیریت بارهای کاری مختلف طراحی کند. برای مثال، درخواست‌های HTTP ممکن است توسط یک پردازه‌ی وب و وظایف طولانی‌مدت که در پس‌زمینه اجرا می‌شوند، توسط یک یا چند پردازه‌ی دسته‌ای انجام شود.
+
+این امر پردازه‌های منفرد را از مدیریت چندگانه داخلی خود، از طریق رشته‌های داخل VM زمان اجرا، یا مدل async/evented که در ابزارهایی مانند [EventMachine](https://github.com/eventmachine/eventmachine)، [Twisted یافت می‌شود، حذف نمی‌کند. ](http://twistedmatrix.com/trac/)، یا [Node.js](http://nodejs.org/). اما یک ماشین مجازی تنها می‌تواند تا این حد بزرگ شود (مقیاس عمودی)، بنابراین برنامه باید بتواند چندین فرآیند در حال اجرا بر روی چندین ماشین فیزیکی را نیز بپوشاند.
+
+زمانی که نوبت به افزایش مقیاس‌پذیری می‌رسد، مدل پردازه واقعاً اهمیت می‌یابد. [به اشتراک گذاشتن هیچ منبعی در ماهیت تقسیم افقی پردازه‌های برنامه‌ی دوازده‌سازه](./processes) به این معنی است که افزودن همزمانی بیشتر، یک عملیات ساده و قابل اعتماد خواهد بود. آرایه‌ی انواع پردازه و تعداد پردازه‌های هر نوع، با نام *مدل پردازه* شناخته می‌شود.
+
+پردازه‌های برنامه‌ی دوازده-سازه [هرگز نباید دیمونیزه شوند](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)، پاسخگویی به پردازه‌هایی که با خطا روبه‌رو شده‌اند و مدیریت راه‌اندازی مجدد توسط کاربر و خاموش‌شدن سرور تکیه کنید.
\ No newline at end of file
diff --git a/content/fa/config.md b/content/fa/config.md
new file mode 100644
index 000000000..9dae5ca66
--- /dev/null
+++ b/content/fa/config.md
@@ -0,0 +1,22 @@
+## III. پیکربندی‌ها
+### پیکربندی‌ها را در محیط ذخیره کنید
+
+*پیکربندی* یک برنامه هر چیزی است که احتمالاً بین [استقرار](./codebase) های گوناگون (آزمون، عملیات و محیط‌های توسعه‌دهنده و غیره)، متفاوت است که می‌تواند شامل موارد زیر باشد:
+
+* مشخصات اتصال به پایگاه‌داده، Memcached، و سایر [سرویس‌های پشتیبان](./backing-services)
+* موارد محرمانه مربوطه به سرویس‌های بیرونی مانند آمازون S3 یا توییتر
+* مقادیر ویژه‌ی هر محیط مانند نام میزبان استاندارد برای استقرار
+
+گاهی اوقات برنامه‌ها پیکربندی را به صورت ثابت در کد ذخیره می‌کنند. این مورد ناقص اصول دوازده-سازه است که مستلزم جداسازی دقیق پیکربندی از کد ** است. پیکربندی به طور قابل توجهی در بین استقرارها متفاوت است، در حالی که در مخزن کد، این‌گونه نیست.
+a
+یک آزمون تورنسل برای اینکه آیا یک برنامه تمام تنظیمات را به درستی از کد خارج کرده است یا خیر، این است که آیا مخزن کد می تواند در هر لحظه منبع باز شود، بدون اینکه هیچ محرمانگی از برنامه به خطر بیفتد؟
+
+توجه داشته باشید که این تعریف از "پیکربندی" پیکربندی داخلی برنامه را **شامل نمی‌شود**، مانند "config/routes.rb" در Rails، یا نحوه اتصال [ماژول‌های کد](Spring/docs/current/spring-framework-reference/html/beans.html) در [Spring](http://spring.io/). این نوع پیکربندی در بین استقرارها متفاوت نیست، و بنابراین بهتر است در متن کد انجام شود.
+
+روش دیگر برای پیکربندی، استفاده از فایل‌های پیکربندی است که در سیستم کنترل نسخه بررسی نمی‌شوند، مانند «config/database.yml» در Rails. این یک پیشرفت بزرگ نسبت به استفاده از مقادیر ثابتی است که در مخزن کد رهگیری نمی‌شوند، اما همچنان دارای نقاط ضعفی است: ممکن است به اشتباه در کنترل نسخه ثب و رهگیری شود، این تمایل وجود دارد که فایل‌های پیکربندی در مکان‌ها و قالب‌های مختلف پراکنده شوند، که دیدن و مدیریت تمام تنظیمات در یک مکان را دشوار می‌کند. علاوه بر این، این قالب‌ها معمولاً مختص زبان و یا یک چارچوب ویژه هستند.
+
+**پیکربندی برنامه دوازده-سازه در *متغیرهای محیطی*** (اغلب به صورت *env vars* یا *env* کوتاه می‌شود). متغیرهای محیطی به راحتی بین محیط‌ها بدون تغییر هیچ بخشی از کد قابل تغییر هستند. بر خلاف فایل‌های پیکربندی، احتمال کمی وجود دارد که به طور تصادفی در مخزن کد بررسی شوند و برخلاف فایل‌های پیکربندی سفارشی، یا مکانیزم‌های پیکربندی دیگر مانند System Properties در جاوا، یک استاندارد زبان برنامه‌نویسی و سیستم عامل هستند.
+
+یکی دیگر از جنبه های مدیریت پیکربندی، گروه‌بندی است. گاهی اوقات برنامه‌ها پیکربندی دسته‌ای را در گروه‌های نام‌گذاری‌شده (اغلب «environments» نامیده می‌شوند) با نام‌گذاری‌های خاص، مانند محیط‌های `test`، `development` و `production` در Rails ترکیب می‌کنند. این روش‌ها به طور ذاتی مقیاس‌پذیر نیستند و در صورت ایجاد تعداد بیشتری محیط، نام‌های محیط جدیدی مانند `staging` یا `qa` نیاز است. همین‌طور که پروژه بزرگ‌تر می شود، توسعه‌دهندگان ممکن است محیط‌های خاص خود را مانند `joes-staging` اضافه کنند، که منجر به انفجار ترکیبی از پیکربندی‌ها می شود که مدیریت استقرار برنامه را بسیار شکننده می‌کند.
+
+در یک برنامه‌ی کاربردی دوازده-سازه، متغیرهای محیطی، مقادیر ویژه‌ای هستند که هر کدام کاملاً مستقل از سایر متغیرهای محیطی هستند. آنها هرگز به عنوان «محیط» گروه‌بندی نمی شوند، بلکه به طور مستقل برای هر استقرار مدیریت می‌شوند. این مدلی است که اندازه‌ی آن به آرامی افزایش می‌یابد زیرا برنامه به طور طبیعی در چرخه‌ی عمر خود به شکل فزاینده‌ای رشد می‌یابد.
\ No newline at end of file
diff --git a/content/fa/dependencies.md b/content/fa/dependencies.md
new file mode 100644
index 000000000..ff1ab135c
--- /dev/null
+++ b/content/fa/dependencies.md
@@ -0,0 +1,12 @@
+## II. وابستگی‌ها
+### وابستگی‌ها را به صراحت اعلام و جدا کنید
+
+اکثر زبان‌های برنامه‌نویسی یک سیستم بسته‌بندی برای توزیع کتابخانه‌های پشتیبانی ارائه می دهند، مانند [CPAN](http://www.cpan.org/) برای Perl یا [Rubygems](http://rubygems.org/) برای Ruby. کتابخانه‌هایی را که از طریق یک سیستم بسته‌بندی نصب می‌شوند، می‌توان در سراسر سیستم (معروف به "بسته‌های سایت") نصب کرد یا در مسیر نصب برنامه (معروف به "کتابخانه" یا "بسته‌بندی") قرار داد.
+
+**یک برنامه دوازده-سازه هرگز به وجود ضمنی بسته‌های محیط نصب متکی نیست.** همه‌ی وابستگی‌ها را به طور کامل و دقیق از طریق مانیفست *اعلام وابستگی* اعلام می‌کند. علاوه بر این، از یک ابزار * جداسازی وابستگی * در طول اجرا استفاده می کند تا اطمینان حاصل شود که هیچ کتابخانه‌ی وابسته‌‌ای به طور ضمنی از سیستم میزبان "مورد استفاده قرار نمی‌گیرد". مشخصات کتابخانه‌ها، کامل و صریح به طور یکسان برای تولید و توسعه اعمال می شود.
+
+برای مثال، [Bundler](https://bundler.io/) برای Ruby قالب مانیفست «Gemfile» را برای اعلام وابستگی‌ها و «bundle exec» را برای جداسازی وابستگی ارائه می‌کند. در پایتون دو ابزار جداگانه برای این مراحل وجود دارد - [Pip](http://www.pip-installer.org/en/latest/) برای اعلان استفاده می شود و [Virtualenv](http://www.virtualenv.org/en/latest/) برای جداسازی. حتی C نیز [Autoconf](http://www.gnu.org/s/autoconf/) را برای اعلام وابستگی دارد، و پیوند استاتیک می‌تواند جداسازی وابستگی‌ها را فراهم کند. مهم نیست که زنجیره‌ی ابزار چیست، اعلان وابستگی و جداسازی باید همیشه با هم استفاده شوند -- فقط یکی یا دیگری برای برآورده کردن دوازده-سازه کافی نیست.
+
+یکی از مزایای اعلام وابستگی صریح این است که راه‌اندازی را برای توسعه‌دهندگانی که تازه وارد برنامه شده‌اند، ساده می‌کند. توسعه‌دهنده‌ی جدید می‌تواند کد برنامه را بر روی دستگاه توسعه‌ی خود بررسی کند، و فقط به مفسر یا مترجم زبان برنامه‌نویسی و مدیر وابستگی نصب شده را به عنوان پیش‌نیاز احتیاج دارد. همچنین می‌توانند همه‌چیز مورد نیاز برای اجرای کد برنامه را به سادگی با دستور *build* نصب کنند. به عنوان نمونه، برای ساخت بسته‌ها در Ruby/Bundler دستور 'bundle install' به کار می‌رود، در حالی که برای Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) دستور 'lein deps' استفاده می‌شود.
+
+برنامه‌های کاربردی دوازده-سازه نیز به وجود ضمنی هیچ ابزار سیستمی میزبان متکی نیستند. به عنوان مثال می توان به ارسال به ImageMagick یا «curl» اشاره کرد. در حالی که این ابزارها ممکن است در بسیاری از سیستم‌ها یا حتی بیشتر سیستم‌ها وجود داشته باشند، هیچ تضمینی وجود ندارد که در همه سیستم‌هایی که برنامه ممکن است در آینده اجرا شود، وجود داشته باشند، یا اینکه نسخه‌ی موجود در سیستم آینده با برنامه سازگار باشد. اگر برنامه نیاز به استفاده از یک ابزار سیستمی داشته باشد، آن ابزار باید به همراه وابستگی‌های برنامه عرضه شود.
\ No newline at end of file
diff --git a/content/fa/dev-prod-parity.md b/content/fa/dev-prod-parity.md
new file mode 100644
index 000000000..f3d5fbff2
--- /dev/null
+++ b/content/fa/dev-prod-parity.md
@@ -0,0 +1,76 @@
+## X. برابری توسعه/عملیات
+### توسعه، آزمون و عملیات را تا حد امکان، همانند نگه دارید
+
+از لحاظ تاریخی، شکاف‌های قابل توجهی بین توسعه (توسعه‌دهنده‌ای که تغییرات مداوم در [استقرار](./codebase) محیط توسعه‌ی برنامه انجام می دهد) و عملیات (استقرار در حال اجرای برنامه که توسط کاربران نهایی در دسترس است) وجود داشته است. این شکاف‌ها در سه حوزه ظاهر می شوند:
+
+* **شکاف زمانی**: یک توسعه‌دهنده ممکن است روی کدی کار کند که عملیاتی‌سازی آن روزها، هفته‌ها یا حتی ماه‌ها طول می‌کشد.
+* **شکاف پرسنل**: توسعه‌دهندگان کد می نویسند، مهندسان عملیات آن را مستقر می‌کنند.
+* **شکاف ابزار**: توسعه‌دهندگان ممکن است از پشته ای مانند Nginx، SQLite و OS X استفاده کنند، در حالی که در محیط عملیات از Apache، MySQL و Linux استفاده می‌شود.
+
+**برنامه دوازده-سازه برای [استقرار مستمر](http://avc.com/2011/02/continuous-deployment/) طراحی شده است و فاصله بین توسعه و عملیات را کم نگه می دارد.** با نگاهی به سه شکاف توضیح داده شده در بالا:
+
+* فاصله زمانی را کم کنید: طوری‌که یک برنامه‌نویس ممکن است کد بنویسد و چند ساعت یا حتی چند دقیقه بعد آن را مستقر کند.
+* شکاف پرسنل را کم کنید: طوری‌که توسعه‌دهندگانی که کد را نوشته‌اند، از نزدیک در استقرار آن و مشاهده رفتار آن در عملیات نقش دارند.
+* شکاف ابزارها را کم کنید: طوری‌که محیط توسعه و عملیات را تا حد امکان هماهند هم هستند.
+
+چکیده‌ی موارد فوق را در جدول زیر ببینید:
+
+