---
title: "V. ساخت، انتشار، اجرا"
source: Twelve-Factor App
source_url: https://github.com/heroku/12factor
licence: MIT
domain: engineering
subdomain: 12factor
date_added: 2026-04-25
---

## 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`) داشته باشد. نسخه‌ها فقط یک دفتر کل پیوست‌شده هستند و یک نسخه پس از ایجاد، نمی‌بایست دچار تغییر شود. برای هر تغییری باید یک نسخه‌ی جدید ایجاد شود.

هر زمان که کد جدیدی ایجاد شود و نیاز به عملیاتی‌سازی داشته باشد، مراحل ساخت توسط توسعه‌دهندگان برنامه آغاز می‌شود. در مقابل، اجرای آن می تواند به طور خودکار مانند راه‌اندازی مجدد سرور، یا راه‌اندازی مجدد فرآیند از کار افتاده توسط مدیر فرآیند انجام شود. بنابراین، مرحله‌ی اجرا باید تا حد امکان در قسمت‌های متغیر کمتری نگه داشته شود، زیرا مشکلاتی که مانع از اجرای برنامه می‌شوند، می‌توانند باعث خرابی آن در نیمه‌های شب و زمانی که هیچ توسعه‌دهنده‌ای در دسترس نیست، شود. مرحله ساخت می‌تواند پیچیده‌تر باشد، زیرا خطاها همیشه در پیش‌روی توسعه‌دهنده‌هایی هستند که مراحل توسعه را هدایت می‌کنند.
