عامل ۸- همروندی (Concurrency)
برنامه را از طریق مدل پردازش (process model) مقیاس‌پذیر و بزرگ کنید

هر برنامه کامپیوتری پس از اجرا با یک یا چند پردازش (process) در سیستم عامل نمایش داده می‌شود. برنامه‌های وب شکل‌های مختلفی برای اجرای پردازش پیدا کرده‌اند. به عنوان مثال پردازش‌ها یا برنامه‌های PHP می‌توانند به عنوان فرزندی از پردازش‌های آپاچی اجرا می‌شوند البته در صورت نیاز (on demand) و بسته به میزان حجم درخواست (request). پردازش‌های جاوا رویکردی متضادی دارند، این رویکرد به کمک JVM و ابتدا با استفاده از پردازش غول‌پیکری که بخش بزرگی از منابع سیستم مانند CPU و حافظه را در ابتدا در اختیار می‌گیرد و سپس با مدیریت داخلی همروندی (concurrency) به کمک ریسمان‌ها(thread) انجام می‌شود. در هر دو نمونه یعنی PHP و جاوا، امکانِ دسترسی و مشاهده‌‌ی پردازش‌های در حال اجرا برای توسعه‌دهندگان برنامه در پایین‌ترین میزان خود قرار دارد.

پردازش‌ها در برنامه دوازده عاملی اهمیت زیادی دارند و شهروندان درجه‌ یک به حساب می‌آیند. (مترجم؛ در زبان‌های برنامه نویسی، شهروند درجه یک عنصری از زبان است که از تمام عملیات موجود که برای سایر عناصر زبان پشتیبانی می‌کند). خط مشی پردازش‌ها در برنامه دوازده عاملی به شدت از مدل پردازش یونیکس (unix) برای دیمن‌های (deamon) سرویس‌های در حال اجرا اقتباس شده است. (مترجم؛ دیمن، پردازشی از نوع سرویس (service process) که در پس‌زمینه (background) اجرا می‌شود و وظیفه‌ی آن نظارت و رسیدگی به سیستم یا فراهم‌سازی خدماتی برای سایر پردازش‌هاست). توسعه‌دهندگان به کمک این مدل می‌توانند معماری برنامه خود را برای مدیریت اجرای کارهای متنوع و متفاوت به گونه‌ای طراحی کنند که هر نوعی از کارها را به یک نوع پردازش (process type) ویژه‌ محول کنند. به عنوان نمونه، درخواست‌های HTTP توسط یک پردازش وب (web process) مدیریت می‌شود و کاری که در پس‌زمنیه برای طولانی‌مدت باید اجرا شود توسط یک پردازش کارگر(worker process) انجام می‌شود.

چنین رویکردی در مورد تقسیم زمان و تسهیم منابع (multiplexing) داخلیِ پردازش‌های مستقل استثنا قائل نمی‌شود. (مترجم؛ ایجاد منابع متعدد منطقی از یک منبع فیزیکی را مالتی پلکس گویند) . این کار معمولا به کمک ریسمان‌های (thread) داخل ماشین مجازی (VM) یا به کمک مدل async/evented که در ابزارهایی مانند EventMachine، Twisted یا Node.js وجود دارند مدیریت می‌شوند. نکته مهم این است که اندازه‌ی ماشین مجازی می‌تواند تا حد مشخصی افزایش یابد (افزایش عمودی)، بنابراین برنامه باید بتواند با چندین پردازش که روی چندین ماشین فیزیکی در حال اجرا هستند نیز کار کند.

وقتی که زمان مقیاس‌پذیری افقی (scale out) فرا برسد تازه اهمیت مدل پردازش نمایان می‌شود (مترجم؛ scale in به معنای افزایش عمودی منابع و scale out به معنای افزایش افقی آنها است.). اصل «اشتراک‌گذاری صفر»(share-nothing) و ماهیت تقسیم‌پذیری افقیِ پردازش‌های برنامه دوازده عاملی به این معنی است که افزایش همروندی (concurrency) عملیاتی ساده و قابل اتکا است. آرایه ای از نوع پردازش (Process type) و تعداد پردازش‌های موجود از هر نوع با نام شکل گیری پردازش (process formation) شناخته می‌شود.

پردازش‌‌ها در برنامه دوازده عاملی هرگز نباید دیمن‌سازی کنند (daemonize) یا فایل‌های PID (process identifier) را دست کاری کنند (مترجم؛ دیمن‌سازی یک برنامه یا اسکریپت به معنای آماده‌سازی آنها برای اجرا در پس‌زمینه (background) و تبدیل کردن آنها به یک دیمن است).. در عوض، برای مدیریت خروجی‌ها، رسیدگی به پردازش‌های از کار افتاده و مدیریت راه‌اندازی‌های مجدد و خاموش‌ کردن‌هایی که توسط کاربر انجام می‌شوند، باید از مدیریت پردازش‌های سیستم عامل استفاده کنند. از جمله‌ی این ابزارهای مدیریت پردازش‌ می‌توان به systemd در لینوکس، مدیر پردازش توزیع‌شده در پلتفرم‌های ابری یا ابزارهایی که برای توسعه‌دهندگان ساخته‌ شده‌اند مانند Foreman اشاره کرد.

نوشته‌های قبلی:
قسمت هشتم: عامل هفتم: اتصال به پورت

مترجم: حمید آقای خاتمی

گزیده:
«از اژدهای هفت‌سر مترس، از مردم نمام بترس که هرچه وی به ساعتی بشکافد، به سالی نتوان دوخت.» قابوسنامه

عامل ۵: ساخت(build)، انتشار(release)، اجرا(run)
گام‌های ساخت (‌Build) و اجرا(Run) را کاملا از هم جدا کنید.

هر پایگاه کد (codebase) طی سه مرحله به استقرار (deploy) تبدیل می‌شود:

• مرحله ساخت (build stage) : در این مرحله مخزن کد (codebase) به یک بسته قابل اجرا (executable bundle) تبدیل می‌شود. این بسته‌ی قابل اجرا با نام بسته‌ی ساخت (Build) نیز شناخته می‌شود. در این مرحله ابتدا بر اساس شماره‌ی نسخه‌ی (version) کدی که در فرایند استقرار مشخص شده، کد از مخزن کد برداشته می‌شود،‌ در گام دوم، اجزا و مولفه‌های خارجی که برنامه به آنها وابسته است (vendors dependencies) گردآوری می‌شود و در پایان، فایل‌ها و سایر اجزای برنامه کامپایل می‌شوند.
• مرحله انتشار (release stage): در این مرحله بسته ساخت (Build) که در مرحله قبلی آماده شده با پیکربندی(config) استقرار ترکیب می‌شود که نتیجه‌ی آن نسخه قابل انتشار (release) است که شامل هم بسته‌ی ساخت و هم پیکربندی است. این نسخه‌‌ی انتشار برای استفاده در محیط اجرا (execution environment) آماده است.
• مرحله اجرا (run stage): برنامه در محیط اجرا بالا می‌آید، برای هر انتشار مجموعه‌ای از فرآیندهای برنامه اجرا می‌شود. این مرحله نام “مرحله زمان اجرا” (runtime) نیز شناخته می شود.

مترجم:
بسته (bundle):‌به دو یا چند برنامه‌ی نرم‌افزاری (application) که با هم بسته‌بندی می‌شوند و به عنوان یک محصول به فروش می‌رسند) بسته یا باندل گفته می‌شود.

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

ابزارهای استقرار معمولاً دارای ابزارهای مدیریت انتشار نیز هستند و یکی از قابلیت‌های برجسته آنها،‌ امکان برگشت به عقب و به نسخه قبلی است (roll back). برای مثال، ابزار استقرار Capistrano نسخه‌ها را در پوشه‌ای (folder) به نام releases ذخیره می‌کند. در این ابزار به کمک یک فایل لینکی (Symlink) که به یکی از پوشه‌های داخل releases اشاره می‌کند، مشخص می‌گردد که نسخه‌ی جاری در کدام یک از پوشه‌ها قرار دارد. هم‌چنین در این ابزار، فرمان rollback به شما کمک می‌کند به راحتی و به سرعت به نسخه قبلی برگردید.

مترجم:
Symlink که symbolic link هم نامیده می‌شود نوعی فایل در لینوکس است که به فایل یا پوشه دیگری در کامپیوتر اشاره می کند. Symlink مشابه shortcut در ویندوز است.

هر انتشار باید یک شناسه‌ی منحصر به فرد مانند شناسه‌ی زمانی (timestamp) مانند ۲۰۱۱-۰۴-۰۶-۲۰:۳۲:۱۷ یا یک شناسه‌ی عددی مانند v100 داشته باشد. فهرست انتشارها مانند لیستی است که فقط می‌توان به آن ردیف جدیدی اضافه کرد و بعد از اضافه شدن ردیف جدید، نمی‌توان آن را تغییر داد.. اعمال هر تغییر جدیدی در انتشار فقط از طریق ایجاد یک انتشار جدید و اضافه کردن آن به لیست موجود، امکان‌پذیر است.

نوشته‌های قبلی:
–قسمت پنجم: سرویس ‌های کمکی ( backing services)

مترجم: حمید آقای خاتمی

گزیده:
بخش توسعه‌ی (Devs) مریخی‌اند و بخش عملیات و اجرا (Ops) ونوسی! استیون هاینس

عامل ۴: سرویس ‌های کمکی ( backing services)
با سرویس‌‌های کمکی مانند منابع ضمیمه شده یا پیوست ( attached resources) رفتار کنید.

سرویس کمکی ( backing services) هر سرویسی است که برنامه از طریق شبکه از آن برای انجام کارهای معمول و روزمره‌اش استفاده کند. از جمله سرویس‌های کمکی می‌توان به پایگاه‌ داده مانند MySQL، سیستم‌های‌ پیام‌رسان و مدیریت صف (messaging/queueing) مانند RabbitMQ، سرویس ایمیل ( SMTP) برای ارسال و دریافت ایمیل‌هامانند Postfix و حافظه‌های ذخیره‌سازی سریع (caching) مانند Memcached اشاره کرد.

سرویس‌‌های کمکی مانند پایگاه داده از قدیم توسط راهبران سیستم (administrators) که استقرار برنامه‌ها نیز بر عهده‌ی آنهاست مدیریت می‌شوند. علاوه‌ بر سرویس‌هایی که به صورت محلی و داخلی (local) مدیریت می‌شوند، برنامه‌ها ممکن است از سرویس‌هایی استفاده کنند که توسط شرکت‌های دیگر ارائه و مدیریت می‌شوند. برای مثال می‌توان به سرویس ایمیل مانند Postmark، سرویس جمع‌آوری شاخص‌های آماری مانند New Relic یا Loggly، سرویس مدیریت دارایی‌های دیجیتالی مانند Amazon S3 و حتی سرویس‌های مبتنی بر API مانند Twitter، Google Maps یا Last.fm اشاره کرد.

کد هر برنامه دوازده عاملی هیچ تفاوتی بین سرویس‌های محلی و سرویس‌های خارجی قائل نیست. از دید برنامه، هر دو نوع سرویس، منابع پیوست (attached resources) هستند که از طریق یک آدرس (URL) یا هر مکانیزم آدرس‌دهی دیگری که در فایل پیکربندی ذخیره شده‌ قابل دسترسی‌اند. موقع استقرار ( deploy) هر برنامه دوازده عاملی باید بتوان بدون تغییر کد، یک پایگاه داده MySQL محلی را با نسخه‌ای که توسط یک شرکت خارجی مدیریت می‌شود مانند Amazon RDS تعویض کرد. هم‌چنین بدون تغییر کد باید یک سرویس‌دهنده‌ی SMTP داخلی را با یک سرویس‌دهنده‌ی خارجی مانند Postmark تعویض کرد. در هر دو مورد فقط کافی است آدرس دسترسی به منابع در پیکربندی (config) تغییر داده شود.

هر سرویس‌ کمکی یک منبع ( resource) به حساب می‌آید. برای نمونه هر پایگاه داده MySQL یک منبع است. دو پایگاه داده MySQL (که در لایه Application برای اشتراک گذاری استفاده می‌شود) دو منبع مجزا به شمار می‌آیند. برنامه دوازده عاملی با این پایگاه‌های داده مانند منابع پیوست (attached resources) برخورد می‌کند که نشان‌دهنده همبستگی کم (loose coupling) آن‌ها به استقراری است که در آن قرار دارند.
منابع را می‌توان به دلخواه به استقرارها متصل و جدا کرد. برای مثال، اگر پایگاه داده به دلیل مشکلات سخت افزاری بد کار کرد راهبر (admin) برنامه می‌تواند از روی آخرین نسخه‌ی پشتیبان، سرویس‌دهنده‌ی جدیدی برای پایگاه داده راه‌اندازی کند و برنامه را به آن متصل نماید. به عنوان نمونه‌ای دیگر، پایگاه داده عملیاتی را می‌توان جدا کرد و پایگاه داده جدیدی را به برنامه متصل کرد. تمام این‌ کارها بدون هیچ تغییری در کد انجام می‌شود.

نوشته‌های قبلی:
– قسمت چهارم: پیکربندی

مترجم: حمید آقای خاتمی

گزیده:
«زمانی که از به هدر دادنش لذت ببری. به هدر نرفته‌است.» جان لنون

عامل ۳: پیکربندی
پیکربندی (config) را در محیط استقرار (environment) ذخیره کنید

پیکربندی هر برنامه احتمالاً برای استقرارهای مختلف (محیط عملیاتی یا production، محیط داخلی یا stage، محیط‌ توسعه‌دهندگان و غیره) یکسان نیست. این تفاوت می‌تواند به دلایل متفاوتی از جمله موارد زیر باشد:
– منابع دسترسی به پایگاه داده، حافظه‌های ذخیره‌سازی سریع (Memcached) و سایر خدمات پشتیبان (backing services) سرویس‌دهنده‌
– اعتبارنامه (Credentials) برای خدمات خارجی مانند Amazon S3 یا Twitter
– مقادیری مانند نام مستعار میزبان (canonical hostname یا cname) برای هر استقرار

گاهی اوقات پیکربندی به صورت مقادیر ثابتی (constants) در خود کد نوشته می‌شود. چنین کاری نقض اصول برنامه‌های دوازده عاملی است که در آن، جداسازی کامل و دقیق پیکربندی از کد الزامی است. پیکربندی نسخه‌های مختلف استقرار (عملیاتی، داخلی، توسعه‌دهندگان) با هم تفاوت جدی دارند در حالی که کد این نسخه‌ها معمولا یکسان است. یک آزمایش ساده برای کسب اطمینان از جداسازی درست پیکربندی از کد برنامه این است که بررسی کنید آیا بدون در اختیار دادن اعتبارنامه‌ها (credentials) می‌توان کد برنامه را در همان لحظه به یک کد متن‌باز تبدیل کرد و در اختیار همه قرار داد.

دقت کنید که تعریف ما از “پیکربندی” شامل پیکربندی داخلی برنامه [مثلا پیکربندی ارتباط بین ماژول‌ها و مولفه‌های برنامه] نمی‌شود. این نوع پیکربندی در استقرار‌ها متفاوت نیست در نتیجه بهتر است در خود کد نگهداری و مدیریت شود.

رویکرد دیگر مدیریت پیکربندی، استفاده از فایل‌های پیکربندی (config files) است که در مخزن کد (repo) قرار نمی‌گیرند. چنین رویکردی در مقایسه با نوشتن پیکربندی در کد به کمک تعریف مقادیر ثابت، پیشرفت بزرگی محسوب می‌شود، هر چند این روش نیز ایراداتی دارد. احتمال اشتباه و قراردادن فایل پیکربندی در مخزن کد بسیار بالا است. احتمال پراکنده شدن فایل‌های پیکربندی در جاهای مختلف و با قالب‌های (format) متفاوت زیاد است. چنین اتفاقی مدیریت فایل‌های پیکربندی‌ و یکسان‌سازی آنها را دشوار می‌کند. معمولا قالب‌(formats) هر یک از این فایل‌های پیکربندی مختص زبان یا چارچوب متفاوتی است که مدیریت آنها را دشوارتر می‌کند.

هر برنامه دوازده عاملی پیکربندی را در متغیرهای محیط (environment variables) ذخیره می‌کند (به صورت اختصار env vars یا env نامیده می‌شوند). متغیرهای محیطی (env vars) را بدون آن که نیازی به تغییر کد باشد، به راحتی می‌توان برای هر استقرار تغییر داد. در مقایسه با فایل‌های پیکربندی، احتمال قرار گرفتن اشتباهی آنها در مخزن کد نیز کمتر است. و برخلاف فایل‌های پیکربندی خاص‌منظوره یا مکانیزم‌های پیکربندی خاص هر زبان‌ برنامه‌نویسی، این متغیرها مستقل از استاندارد زبان و سیستم عامل تعریف می‌شوند.

گروه‌بندی یکی دیگر از موضوعات مدیریت پیکربندی (config) است. گاهی‌ افراد متغیرهای پیکربندی را در قالب گروه‌هایی دسته‌بندی می‌کنند که نام آنها ترکیبی است از انواع استقرار (development, test, ,production) و کلمه‌ی environments . چنین روشی مقیاس‌پذیر نیست زیرا با اضافه شدن انواعی جدیدی از استقرار مانند staging یا qa به نام‌های جدیدی برای محیط‌ها نیاز خواهیم داشت. حتی احتمالا با رشد پروژه و ورود توسعه‌دهندگان جدید، هر فردی محیط‌ دلخواه و مورد نیازش را به فهرست محیط‌های قبلی اضافه خواهد کرد (مانند smith-qa یا smith-development). چنین اتفاقی باعث رشد نمایی و انفجار تعداد پیکربندی‌ها (config) می‌شود و عملا مدیریت استقرار را پراشتباه و فلج می‌نماید.

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

پانوشت:
استقلال یا orthogonal بودن دو متغیر محیطی (env var) به چه معناست؟
orthogonal به این معناست که دو متغیر محیطی می‌توانند مستقل از همدیگر تغییر کنند و تغییر یکی لزوما منجر به تغییر دیگری نمی‌شود. در نتیجه هنگام انتخاب متغیرهای محیطی باید بدون در نظر گرفتن محیط‌های استقرار (مانند development, test, and production)، یک سری از متغیرها را شناسایی و به عنوان متغیر محیطی تعریف کرد

نوشته‌های قبلی:
– قسمت سوم: وابستگی‌ها (۳)

مترجم: حمید آقای خاتمی

گزیده:
بگذارید تعریف کاملاً متفاوتی از موفقیت به شما ارائه دهم، تعریفی که دست کم دو هزار سال قدمت دارد. موفقیت، براساس تعریف خود، نه به میزان منزلت و اعتباری که جامعه به فرد می‌دهد وابسته است و نه به قرار گرفتن در فهرست‌های مبتذل. تعریفش این است؛ موفقیت حقیقی، موفقیت درونی است. همین!» رولف دوبلی
مرجع:‌ ویکی گفتار

عامل ۲: وابستگی ها (Dependencies)
وابستگی ها را به صورت شفاف و صریح بیان کنید و آن ها را ایزوله کنید (Explicitly declare and isolate dependencies)

اکثر زبان‌های برنامه‌نویسی دارای سیستم بسته‌بندی (packaging system) یا مدیریت بسته‌ها (package manager) برای توزیع و پخش کتابخانه‌ها هستند، مانند npm برای جاوا اسکریپت، pip برای پایتون و NuGet برای دات‌نت. کتابخانه‌هایی که با ابزار مدیریت بسته‌ها نصب می‌شوند می‌توانند در سطح کل سیستم (system-wide) نصب ‌شوند که با نام site packages نیز معروف‌ هستند یا می‌توانند فقط محدود به یک دایرکتوری شوند که برنامه در آن قرار دارد که با نام vendoring یا bundling نیز معروف هستند.

یک برنامه دوازده عاملی هیچ گاه اعتماد نمی‌کند که بسته‌ها از قبل در سیستم نصب شده‌اند و به صورت پیش‌فرض وجود دارند. این گونه برنامه‌ها همه‌ وابستگی‌ها را به صورت کامل و دقیق و به کمک یک «بیانیه اعلان وابستگی‌» (dependency declaration manifest) اعلام می‌کنند. به علاوه از یک «ابزار ایزوله‌سازی وابستگی» (dependency isolation tool) در طول اجرای برنامه استفاده می‌کنند تا مطمئن شوند که هیچ‌گونه وابستگی بیان‌نشده‌ای از محیط اطراف به داخل سیستم “نشت نمی‌کند” (leak in). وابستگی‌ها به صورت کامل و صریح و به شکل یکسان هم برای محیط عملیاتی و هم برای محیط توسعه اعمال می‌شوند.

برای مثال در پایتون دو ابزار جداگانه برای این کارها وجود دارد. ابزار Pip برای اعلان وابستگی‌ها و Virtualenv برای ایزوله‌سازی استفاده می‌شود. صرف نظر از ابزارهای استفاده‌شده، اعلان وابستگی‌ها و ایزوله‌سازی وابستگی‌ها باید همواره با هم استفاده گردند و هیچ یک از آنها به تنهایی شرط‌های برنامه‌های ۱۲ عاملی را محقق نمی‌کنند.

یکی از مزایای اعلان صریح وابستگی‌ها (explicit dependency declaration) این است که راه اندازی (setup) را برای توسعه‌دهندگان تازه‌وارد ساده می‌کند. توسعه‌دهنده جدید کافی است نسخه‌ای ازکد (codebase) برنامه را روی دستگاه خود داشته باشد و آن وقت برای اجرا تنها به ابزارهای خود زبان (مانند پایتون) و ابزار مدیر وابستگی (مانند pip) ‌نیاز خواهد داشت. پس از این مراحل، آنها می‌توانند به کمک یک سری دستورات ساخت (build command) معین کارهای لازم برای اجرای برنامه را انجام دهند.

برنامه‌های دوازده عاملی نه تنها اعتماد نمی‌کنند که بسته‌ها در سیستم از قبل نصب شده‌اند، بلکه حتی اعتماد نمی‌کنند که ابزارها نیز از قبل نصب‌ شده و قابل استفاده باشند. به عنوان مثال ابزاری مانند curl (ابزار ارسال و دریافت داده‌ها) ممکن است در اکثر سیستم‌ها وجود داشته باشد، ولی تضمینی وجود ندارد که در همه سیستم‌هایی که برنامه روی آنها اجرا خواهد شد نیز وجود داشته باشد یا اینکه نسخه موجود در سیستم با برنامه سازگار باشد. اگر برنامه‌ای به ابزاری نیاز دارد باید آن را به همراه خودش عرضه کند.

نوشته‌های قبلی:
– قسمت دوم: پایگاه کد (۲)

مترجم: حمید آقای خاتمی

گزیده:
وقتی بچه بودم، پدرم می‌گفت که بزرگترین امیدها و بدترین ترس‌های ما به ندرت رنگ واقعیت به خود می‌گیرند.
از فیلم مونیخ

عامل ۱:‌ پایگاه کد (code base)

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

یک برنامه‌ی دوازده عاملی همیشه به کمک سیستم‌های کنترل نسخه (version control) مانند Git، Mercurial یا Subversion کنترل و ردیابی (track) می‌شود. به یک کپی از پایگاه داده‌ای که حاوی اطلاعات نسخه‌ها است مخزن کد (code repository) گفته می‌شود که معمولا به صورت مختصر به نام مخرن، code repo یا repo خوانده می‌شود.

معمولا ارتباط یک به یکی بین پایگاه کد و برنامه وجود دارد:

• وجود چندین پایگاه کد برای یک برنامه نشان می‌دهد که آن برنامه تنها یک برنامه جدا نیست، بلکه احتمالا یک سیستم توزیع‌شده است. هر مؤلفه (component) از این سیستم توزیع‌شده، خود یک برنامه‌ی جداست و هر یک از این برنامه‌ها به تنهایی می‌تواند عوامل دوازده‌گانه را رعایت کنند.
• اگر چند برنامه دارای یک کد یکسان و مشترک باشند، عوامل دوازده‌گانه را نقض کرده‌اند. راه حل این است که کد مشترک بین آنها جدا شود و در کتابخانه‌هایی قرار گیرد که بتوان به کمک مدیر وابستگی(dependency manager) در جاهای مختلف استفاده شوند.

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

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

نوشته‌های قبلی:
– قسمت اول: برنامه ۱۲ عاملی (۱)

مترجم: حمید آقای خاتمی

گزیده:
هدف زندگی این نیست که با اکثریت همراه شوی، بلکه در نپیوستن به جمع بی خردان است. مارکوس آئورلیوس