چرا فرایند انتشار نرم‌افزار باید قابل اتکا باشد؟

یک Feature جدید آماده شده است.

تست اولیه هم خوب بوده.

Developer می‌گوید:

روی سیستم من بدون مشکل کار می‌کند.

حالا فقط یک مرحله باقی مانده:

Production.

اما همین «فقط یک مرحله» گاهی پرریسک‌ترین بخش کل پروژه است.

نسخه جدید Deploy می‌شود و ناگهان:

Login از کار می‌افتد.

یک API قدیمی با نسخه جدید سازگار نیست.

Migration دیتابیس نیمه‌کاره می‌ماند.

Environment Variable اشتباه است.

یکی از Dependencyها تغییر کرده.

یا Application ظاهراً بالا آمده، اما Checkout برای بخشی از کاربران Error می‌دهد.

اینجاست که تفاوت میان:

«نرم‌افزار را می‌توان Deploy کرد»

و:

«نرم‌افزار فرایند انتشار قابل اتکایی دارد»

مشخص می‌شود.

DORA، Continuous Delivery را توانایی انتشار سریع، امن و پایدار تغییرات در زمان موردنیاز تعریف می‌کند؛ به شکلی که تیم بتواند حتی در ساعات عادی کاری تغییر Production بدهد، بدون اینکه انتشار هر نسخه تبدیل به یک اتفاق پراسترس شود.

پس هدف Release Pipeline فقط سرعت نیست.

هدف این است که انتشار:

قابل تکرار، قابل مشاهده، قابل کنترل و قابل برگشت باشد.

اگر Deploy کردن ترسناک است، مشکل فقط تیم نیست

در بعضی تیم‌ها Release یک مراسم خاص است.

همه باید آنلاین باشند.

چند نفر Checklist دستی دارند.

یک نفر Commandها را اجرا می‌کند.

یک نفر Database Script را Run می‌کند.

یک نفر Config را تغییر می‌دهد.

بعد همه منتظر می‌مانند ببینند چیزی خراب می‌شود یا نه.

اگر هر Release به هماهنگی حافظه‌ای چند نفر وابسته باشد، مشکل این نیست که تیم «دقت کافی ندارد».

فرایند بیش از حد به انسان وابسته است.

Microsoft در Safe Deployment Practices تأکید می‌کند تمام تغییرهای Production ذاتاً ریسک دارند و باید تا جای ممکن از یک الگوی استاندارد و خودکار عبور کنند تا Human Error کاهش یابد. همان راهنما انتشارهای کوچک و پرتکرار را نیز به Releaseهای بزرگ و کم‌تعداد ترجیح می‌دهد، چون تشخیص و رفع مشکل در تغییر کوچک ساده‌تر است.

Release خوب نباید به این بستگی داشته باشد که چه کسی آن روز Deploy را انجام می‌دهد.

CI و CD دقیقاً چه مسئله‌ای را حل می‌کنند؟

CI/CD اغلب به شکل یک اصطلاح واحد گفته می‌شود، اما دو مسئله متفاوت را حل می‌کند.

Continuous Integration

تغییرات Code مرتب با Branch اصلی ادغام می‌شوند و Pipeline سریع Feedback می‌دهد.

مثلاً:

• Build موفق است؟
• Unit Testها پاس می‌شوند؟
• Lint مشکلی دارد؟
• Dependency ناامن وجود دارد؟
• Integration شکسته؟

هدف این است که مشکل Integrating شدن Codeها زود دیده شود؛ نه دو هفته بعد وقتی چند Branch بزرگ قرار است هم‌زمان Merge شوند.

DORA نیز Continuous Integration، Test Automation و Trunk-based Development را جزو قابلیت‌هایی می‌داند که Continuous Delivery را ممکن می‌کنند.

Continuous Delivery

بعد از اینکه تغییر از Quality Gateها عبور کرد، باید در وضعیت قابل انتشار باشد.

یعنی مسیر:

Code → Build → Test → Artifact → Staging → Production

تا جای ممکن استاندارد و قابل تکرار باشد.

Continuous Delivery الزاماً به این معنی نیست که هر Commit بدون کنترل مستقیم وارد Production شود.

می‌تواند Approval داشته باشد.

اما مرحله انتشار دیگر مجموعه‌ای از Commandهای دستی و حدس‌زدن نیست.

تغییر کوچک، Release امن‌تر

فرض کنید یک Release شامل ۶۰ Commit و تغییر پنج بخش اصلی سیستم است.

بعد از Deployment، Error Rate بالا می‌رود.

کدام تغییر مشکل ایجاد کرده؟

پیداکردنش سخت‌تر است.

حالا همان تغییرات را به ده Release کوچک‌تر تقسیم کنید.

اگر بعد از Release هفتم مشکلی ایجاد شود، محدوده Investigation بسیار کوچک‌تر است.

Microsoft نیز در راهنمای Safe Deployment سال ۲۰۲۶ توصیه می‌کند تغییرهای Production تا حد امکان کوچک، Incremental و Quality-gated باشند.

Release کوچک معمولاً:

• Review ساده‌تری دارد.
• تست محدودتر و دقیق‌تری دارد.
• Blast Radius پایین‌تری دارد.
• Rollback ساده‌تری دارد.
• و تیم راحت‌تر می‌فهمد چه چیزی تغییر کرده است.

Batch بزرگ Code فقط Delivery را کند نمی‌کند؛ ریسک تشخیص Failure را هم بالا می‌برد.

Build باید قابل تکرار باشد

یک Anti-pattern رایج این است:

نسخه‌ای برای Test ساخته شود.

بعد قبل از Production دوباره Build بگیریم.

به نظر مشکلی ندارد.

اما Build دوم ممکن است واقعاً همان Artifact قبلی نباشد.

Dependency جدید Download شود.

Base Image تغییر کرده باشد.

Build Script رفتار متفاوتی داشته باشد.

یا Package Registry نسخه دیگری Resolve کند.

Google Cloud در راهنمای CI/CD برای GKE توصیه می‌کند Build یک بار انجام شود و همان Image تست‌شده بین Environmentها Promote شود تا چیزی که در Production Deploy می‌شود همان چیزی باشد که قبلاً Test شده است.

این اصل ساده است:

Build once, promote many.

مثلاً:

Commit → Build Artifact v2.14.7 → Test → Staging → Production

نه:

Commit → Build for Test → دوباره Build for Staging → دوباره Build for Production

Config مخصوص Environment باید جدا باشد.

Artifact اصلی بهتر است ثابت بماند.

Artifact باید هویت داشته باشد

اگر بعد از Incident بپرسیم:

الان دقیقاً چه نسخه‌ای روی Production است؟

نباید جواب:

فکر کنم Build دیشب باشد.

باشد.

Artifact باید Version مشخص داشته باشد.

مثلاً:

web-api:2.14.7

یا با Commit SHA.

باید بتوانیم بفهمیم:

• چه Source Codeای آن را ساخته؟
• چه زمانی Build شده؟
• Pipeline موفق بوده؟
• چه Testهایی پاس شده؟
• چه کسی آن را Promote کرده؟

Microsoft توصیه می‌کند Build Artifactها Version شوند تا Rollback و Roll-forward قابل کنترل باشند.

در زنجیره تأمین نرم‌افزار، SLSA نیز مفهوم Provenance را مطرح می‌کند: اطلاعات قابل تأییدی که نشان می‌دهد Artifact کجا، چه زمانی و چگونه ساخته شده است. این Traceability کمک می‌کند مصرف‌کننده Artifact بتواند منشأ Build را بررسی کند.

در Pipeline بالغ:

«فایل Deploy» فقط فایل نیست؛ شناسنامه دارد.

Staging باید تا جای ممکن شبیه Production باشد

اگر Test در محیطی انجام شود که تقریباً هیچ شباهتی به Production ندارد، نتیجه Test هم محدود است.

مثلاً:

• Production سه Instance دارد، Staging یکی.
• Production پشت Reverse Proxy است، Staging مستقیم.
• Production Database Version دیگری دارد.
• Configها متفاوت‌اند.
• Feature Flagها متفاوت‌اند.
• Network Ruleها متفاوت‌اند.
• Authentication Provider فرق می‌کند.

در این شرایط ممکن است تمام Testها سبز باشند و Application در Production خراب شود.

Microsoft توصیه می‌کند Staging Environment تا حد ممکن Production را Mirror کند تا تغییر در یک محیط کنترل‌شده آزمایش شود.

قرار نیست Staging همیشه دقیقاً هم‌اندازه Production باشد.

اما تفاوت‌ها باید شناخته‌شده و عمدی باشند.

نه نتیجه سال‌ها تغییر اتفاقی.

Quality Gate فقط Unit Test نیست

وجود CI Pipeline خوب است.

اما این:

Unit tests passed ✅

به این معنی نیست که Release حتماً امن است.

هر نوع تست کلاس متفاوتی از Failure را می‌گیرد.

یک Pipeline بسته به سیستم ممکن است شامل این موارد باشد:

• Unit Tests
• Integration Tests
• Contract Tests
• API Tests
• UI / End-to-End Tests
• Security Scanning
• Dependency Scanning
• Static Analysis
• Migration Tests
• Performance Checks
• Smoke Tests

Microsoft نیز تأکید می‌کند نباید تنها به یک نوع تست تکیه کرد؛ برای مثال Contract Test و Behavior Test مشکلات متفاوتی را پیدا می‌کنند.

هدف Quality Gate این نیست که Pipeline را شلوغ کنیم.

هدف این است که Failure ارزان‌تر را قبل از Production پیدا کنیم.

تستی که همیشه قرمز است، دیگر Gate نیست

Automated Test فقط وقتی ارزش دارد که قابل اعتماد باشد.

اگر Team می‌داند:

این Test معمولاً Fail می‌شود، دوباره Run کن.

بعد از مدتی کسی به Pipeline اعتماد نمی‌کند.

هر Failure تبدیل به:

Retry

Ignore

Override

می‌شود.

DORA نیز روی Test Suite قابل اتکا تأکید دارد؛ تست باید Failure واقعی را پیدا کند و Code قابل Release را عبور دهد.

Flaky Test فقط مزاحمت نیست.

کم‌کم Alarm System تیم را بی‌اعتبار می‌کند.

Pipeline‌ای که زیاد اشتباه هشدار می‌دهد، در روزی که هشدار واقعی می‌دهد هم جدی گرفته نمی‌شود.

Approval خوب است، اما Approval دستی جای تست را نمی‌گیرد

برای بعضی Environmentهای حساس، Manual Approval منطقی است.

مثلاً:

• Production مالی
• سیستم‌های Critical
• تغییر Infrastructure مهم
• یا Releaseهایی که Compliance خاصی دارند

GitHub Environments می‌تواند Deployment را به Approval، Branch Restriction یا Protection Rule متصل کند و حتی اجازه دهد سیستم‌های Observability، Security یا Change Management درباره ادامه Deployment تصمیم بگیرند.

اما Approval نباید به شکل زیر باشد:

علی جان، Pipeline سبزه، Deploy بزن؟

و علی بدون Context روی Approve کلیک کند.

Approval ارزش دارد وقتی شخص Approver می‌داند:

• چه چیزی تغییر کرده؟
• چه Testهایی اجرا شده؟
• Risk چیست؟
• Plan برگشت چیست؟
• و چه Metricهایی بعد از انتشار دیده خواهند شد؟

Approval یک Decision Gate است؛ نه دکمه تزئینی.

Feature Release را از Code Deployment جدا کنید

یکی از ابزارهای بسیار مفید در Release Engineering، Feature Flag است.

فرض کنید Code قابلیت جدید را Deploy کرده‌اید، اما Feature هنوز خاموش است.

حالا می‌توانید Feature را فقط برای:

• تیم داخلی،
• ۱٪ کاربران،
• یک مشتری،
• یک کشور،
• یا گروه آزمایشی

فعال کنید.

Microsoft نیز Feature Flagها را برای کنترل Exposure و Rollback سریع قابلیت‌ها توصیه می‌کند و آن‌ها را در Progressive Deployment به‌کار می‌گیرد.

این جداسازی دو مفهوم ایجاد می‌کند:

Deploy Code

و:

Release Feature

دیگر لازم نیست هر بار که Product Manager می‌خواهد Feature فعال شود، Deployment جدید انجام دهیم.

و اگر Feature مشکل داشت، گاهی خاموش‌کردنش بسیار سریع‌تر از Rollback کامل Build است.

Feature Flag هم بدهی می‌سازد

Feature Flag مفید است.

اما اگر Flagهای قدیمی هیچ‌وقت حذف نشوند، Code پیچیده می‌شود.

مثلاً بعد از مدتی:

اگر Flag A روشن و B خاموش بود...

اما فقط برای کاربران Enterprise...

به‌جز Version قدیمی...

و اگر C فعال بود...

فهمیدن رفتار واقعی سیستم سخت می‌شود.

پس Feature Flag باید Lifecycle داشته باشد:

• Owner
• تاریخ ایجاد
• هدف
• شرط حذف
• و Cleanup

Flag موقت نباید تبدیل به Architecture دائمی شود.

Production را یک‌باره به همه کاربران ندهید

حتی اگر تمام Testها پاس شده باشند، Production همیشه چیزی برای یاددادن دارد.

Traffic واقعی متفاوت است.

Data واقعی متفاوت است.

Behavior کاربران متفاوت است.

Dependencyهای واقعی متفاوت‌اند.

پس یکی از بهترین روش‌های کاهش Risk این است که Release مرحله‌ای باشد.

Microsoft در Safe Deployment Practices سال ۲۰۲۶ توصیه می‌کند از Progressive Exposure استفاده شود تا Blast Radius مشکلات انتشار محدود شود.

Canary Deployment

در Canary Deployment ابتدا درصد کمی از کاربران نسخه جدید را دریافت می‌کنند.

مثلاً:

1%

بعد:

5%

25%

50%

100%

بین هر مرحله Metricها بررسی می‌شوند.

اگر Error Rate یا Latency بد شد، Rollout متوقف می‌شود.

Microsoft Canary را یکی از الگوهای اصلی Progressive Exposure می‌داند و توصیه می‌کند بین مراحل زمان کافی برای مشاهده سلامت Workload وجود داشته باشد.

Blue-Green Deployment

در Blue-Green دو Environment داریم.

Blue نسخه فعلی است.

Green نسخه جدید.

نسخه جدید در Green Deploy و تست می‌شود.

بعد Traffic به‌تدریج یا یک‌باره به Green منتقل می‌شود.

اگر مشکل جدی باشد، می‌توان Traffic را دوباره به Blue برگرداند.

Microsoft این مدل را نیز به‌عنوان روش کاهش Risk و Progressive Rollout توضیح می‌دهد.

Rolling Update

در Rolling Deployment همه Instanceها هم‌زمان تغییر نمی‌کنند.

مثلاً ابتدا یک بخش از Instanceهای قدیمی با نسخه جدید جایگزین می‌شوند.

سپس گروه بعدی.

Kubernetes Deployment به‌صورت رسمی Rolling Update را برای جایگزینی تدریجی Podهای قدیمی با نسخه جدید و حفظ Availability پشتیبانی می‌کند و امکان Pause، Resume و Rollback Rollout را هم دارد.

هر الگو مزایا و هزینه خودش را دارد.

هدف انتخاب اسم جذاب نیست.

هدف این است:

Failure نسخه جدید تا جای ممکن تعداد کمی کاربر را تحت تأثیر قرار دهد.

Deployment بدون Monitoring نصفه است

Pipeline با پیام:

Deployment succeeded.

تمام نمی‌شود.

این فقط یعنی Mechanism استقرار Error واضحی نداده است.

بعد از Release باید بدانیم سلامت واقعی محصول چه شده.

مثلاً:

• Error Rate
• P95 / P99 Latency
• CPU / Memory
• Database Error
• Queue Backlog
• Crash Rate
• Business Transaction Success Rate
• Login Success
• Checkout Completion

Microsoft می‌گوید هر مرحله Progressive Exposure باید به Health Check متصل باشد و در صورت مشاهده مشکل، Rollout فوراً متوقف و Recovery شروع شود.

این یعنی:

Monitoring بخشی از Deployment Pipeline است؛ نه Dashboardی که یک تیم دیگر شاید بعداً نگاه کند.

Health Check باید از دید کاربر معنی داشته باشد

فرض کنید:

Server روشن است.

Health Endpoint پاسخ 200 می‌دهد.

اما Payment API خراب است.

آیا Application سالم است؟

از دید Infrastructure شاید بله.

از دید مشتری نه.

پس Health Model فقط:

CPU < 80%

نیست.

باید Business-critical Flowها را هم پوشش دهد.

مثلاً:

• آیا Login کار می‌کند؟
• آیا سفارش ثبت می‌شود؟
• آیا Payment Success Rate عادی است؟
• آیا Queue حیاتی پردازش می‌شود؟

گاهی بهترین Deployment Gate یک Metric کسب‌وکاری است.

نه Metric سرور.

Rollback را قبل از Release طراحی کنید

بدترین زمان برای طراحی Rollback وقتی است که Production Down شده.

قبل از Deployment باید بدانیم:

• اگر نسخه جدید مشکل داشت، چه می‌کنیم؟
• Artifact قبلی چیست؟
• Config قبلی چیست؟
• Traffic چگونه برمی‌گردد؟
• Database چه می‌شود؟
• Feature Flag داریم؟
• Rollback چقدر زمان می‌برد؟

Microsoft توصیه می‌کند Artifact Versioning و Plan مشخص برای Rollback و Roll-forward وجود داشته باشد. همچنین هشدار می‌دهد Rollback در تغییرهای Stateful، Database و Schema می‌تواند پیچیده باشد.

اگر مسیر برگشت را تست نکرده‌اید، فقط امیدوارید که Rollback کار کند.

Database Migration سخت‌ترین بخش Rollback است

Code را معمولاً راحت‌تر می‌توان به Version قبلی برگرداند.

اما Data را همیشه نه.

فرض کنید Migration یک Column را حذف کرده است.

نسخه قبلی Application به آن Column نیاز دارد.

حالا Deploy جدید مشکل دارد.

Code را Rollback می‌کنید.

ولی Schema دیگر با نسخه قبل سازگار نیست.

یکی از روش‌های کم‌ریسک‌تر در تغییر Database، استفاده از Migrationهای Backward-compatible است.

مثلاً:

• مرحله اول Column جدید اضافه شود.
• نسخه جدید با قدیم و جدید سازگار باشد.
• Data Migration انجام شود.
• بعد از تثبیت نسخه جدید، Column قدیمی در Release جدا حذف شود.

این مسیر کندتر به نظر می‌رسد.

اما Rollback را بسیار ساده‌تر می‌کند.

Database Change هم Release است، نه یک Script جانبی.

Config هم Code محسوب می‌شود

بسیاری از Incidentها نه از Code، بلکه از Config می‌آیند.

• Environment Variable اشتباه
• Port اشتباه
• Feature Flag
• Network Rule
• Secret
• Scaling Setting
• Infrastructure Policy

برای همین Infrastructure as Code و Configuration Versioning اهمیت دارند.

Microsoft صریحاً Deployment Risk را فقط برای Application Code نمی‌داند؛ Infrastructure as Code، Feature Flag و Config Change هم تغییر Production هستند و باید همان انضباط Release را داشته باشند.

این نگاه مهم است:

هر چیزی که رفتار Production را تغییر می‌دهد، بخشی از Release است.

Secret نباید در Pipeline Log ظاهر شود

Automation مزیت بزرگی دارد.

اما Pipeline خودش بخشی از Attack Surface است.

• Credentialهای Cloud
• Registry Token
• SSH Key
• Deployment Secret
• Certificate

اگر Pipeline ناامن باشد، مهاجم شاید اصلاً نیازی به هک Application نداشته باشد.

GitHub Environment Secrets فقط بعد از عبور Job از Protection Rule در دسترس Workflow قرار می‌گیرند و Environmentها می‌توانند دسترسی را محدود کنند.

در Pipeline بهتر است:

• Secret داخل Repository نباشد.
• Least Privilege رعایت شود.
• Credentialها عمر محدود داشته باشند.
• Production Access محدود باشد.
• و Logها Secret را Mask کنند.

CI/CD فقط ابزار Delivery نیست.

بخشی از Software Supply Chain Security است.

Artifact باید قبل از Deploy قابل اعتماد باشد

فرض کنید Build کاملاً سالم است.

اما کسی Image را بعداً در Registry تغییر دهد.

یا Artifact از Build System تأییدنشده آمده باشد.

Google Cloud در Binary Authorization امکان Policy Enforcement در زمان Deploy را ارائه می‌دهد؛ برای مثال می‌توان بررسی کرد Image توسط Build System مشخص ساخته شده یا Validationهای موردنیاز را پاس کرده باشد.

SLSA نیز Provenance را برای همین Traceability و Integrity در زنجیره Build مطرح می‌کند.

در محیط‌های حساس، سؤال فقط:

Test پاس شد؟

نیست.

سؤال دیگر این است:

این همان Artifactی است که Test شده بود؟

Emergency Release هم باید فرایند داشته باشد

Incident امنیتی رخ داده.

Production خراب است.

باید Hotfix فوری منتشر شود.

در این شرایط ممکن است نتوانید همان زمان معمول Release را طی کنید.

اما جواب نباید این باشد:

چون عجله داریم، همه Gateها را خاموش کنید.

Microsoft توصیه می‌کند Emergency Deployment Protocol از قبل تعریف شود؛ مثلاً Approval، Smoke Test یا Bake Time کوتاه‌تر شود، اما مشخص باشد چه کسی اجازه این استثنا را دارد و چه کنترل‌هایی همچنان باید اجرا شوند.

فرایند Emergency باید قبل از Emergency نوشته شده باشد.

در Incident زمان طراحی Governance نیست.

Release موفق را با «تعداد Deploy» تنها نسنجید

اگر تیم روزی ۲۰ بار Deploy می‌کند ولی هر هفته Incident دارد، Deployment Frequency به‌تنهایی چیز زیادی نمی‌گوید.

DORA عملکرد Software Delivery را از دو زاویه می‌بیند:

Throughput

و:

Instability

در منابع به‌روزشده DORA، شاخص‌هایی مانند این‌ها استفاده می‌شوند:

Change Lead Time

از Commit تا اجرای موفق تغییر در Production چقدر طول می‌کشد؟

Deployment Frequency

چقدر مرتب Release می‌کنیم؟

Failed Deployment Recovery Time

اگر Release مشکل ایجاد کرد، چقدر طول می‌کشد سرویس سالم شود؟

Change Fail Rate

چه درصدی از Releaseها نیاز به Fix، Rollback یا Intervention فوری دارند؟

DORA از ۲۰۲۴ همچنین Deployment Rework Rate را برای سنجش انتشارهای برنامه‌ریزی‌نشده ناشی از Bugهای Production وارد مدل پنج‌معیاره خود کرده است.

این ترکیب مهم است.

هدف تیم فقط:

Deploy بیشتر

نیست.

هدف:

تغییر سریع‌تر با Failure کمتر و Recovery سریع‌تر

است.

سرعت و Reliability دشمن هم نیستند

یک تصور قدیمی این است که برای Release امن باید کند باشیم.

و اگر سریع Deploy کنیم حتماً Quality پایین می‌آید.

اما فلسفه Continuous Delivery دقیقاً برعکس است.

• Automation
• تغییر کوچک
• Feedback سریع
• Test قابل اتکا
• Rollout محدود
• Monitoring
• Rollback سریع

همگی اجازه می‌دهند تیم هم سریع‌تر تغییر بدهد و هم Risk هر تغییر را پایین نگه دارد.

DORA سال‌هاست Software Delivery Performance را با ترکیبی از Throughput و Stability بررسی می‌کند، نه با انتخاب یکی از آن‌ها.

کندبودن Release تضمین نمی‌کند Release امن باشد.

گاهی فقط باعث می‌شود هر Release بزرگ‌تر و ترسناک‌تر شود.

یک Release Pipeline عملی چه شکلی دارد؟

برای همه تیم‌ها یک Pipeline ثابت وجود ندارد.

اما جریان معمول می‌تواند چیزی شبیه این باشد:

Code Commit ↓ Review ↓ Build ↓ Automated Tests ↓ Security / Quality Checks ↓ Versioned Artifact ↓ Deploy to Staging ↓ Integration / Smoke Tests ↓ Approval or Automated Gate ↓ Canary / Blue-Green / Rolling Deployment ↓ Health Validation ↓ Progressive Rollout ↓ Production Monitoring ↓ Rollback or Continue

نکته مهم این نیست که Pipeline چند Stage دارد.

مهم این است که هر Stage به یک سؤال جواب دهد.

آیا Code قابل Build است؟

آیا درست کار می‌کند؟

آیا امن است؟

آیا Artifact مشخص است؟

آیا نسخه واقعی قابل Deploy است؟

آیا نسخه جدید در Production سالم است؟

و اگر نه:

چطور سریع برمی‌گردیم؟

چک‌لیست Release Pipeline قابل اتکا

از کجا بفهمیم Release Pipeline واقعاً قابل اتکاست؟

نه وقتی Jenkins یا GitHub Actions نصب شده.

نه وقتی فایل YAML داریم.

نه وقتی Deploy خودکار شده.

و حتی نه وقتی Test Coverage عدد خوبی نشان می‌دهد.

یک Release Process وقتی قابل اتکاست که تیم بتواند یک تغییر کوچک را بدون اضطراب به Production ببرد.

اگر Failure رخ داد، سریع متوجه شود.

بداند چه چیزی تغییر کرده.

اثر Failure را محدود کند.

و بتواند مسیر امنی برای Rollback یا Fix Forward داشته باشد.

فرایند انتشار خوب Developer را کند نمی‌کند.

کارهای تکراری و پرریسک را از دوش او برمی‌دارد.

Release دیگر یک Event استثنایی نیست.

بخشی عادی از مهندسی نرم‌افزار می‌شود.

هدف CI/CD این نیست که نرم‌افزار سریع‌تر به Production برسد.

هدف این است که تغییر خوب، سریع‌تر و با غافلگیری کمتر به دست کاربر برسد.

→بازگشت به مقالات