چرا نباید Configuration را داخل Code قرار دهیم؟

یکی از اشتباه‌های رایج در پروژه‌های Backend این است که اطلاعات Configuration را مستقیماً داخل Source Code قرار دهیم.

مثلاً:

var connectionString =
    "Server=localhost;Database=MyDb;User=sa;Password=123";

در نگاه اول شاید ساده و سریع به نظر برسد، اما در یک پروژه واقعی خیلی زود تبدیل به دردسر می‌شود.

مشکل قرار دادن Configuration داخل Code چیست؟

🔴 1. Secret داخل Source Code قرار می‌گیرد

Connection String ممکن است شامل اطلاعات حساسی مثل:

• Username
• Password
• API Key
• Access Token

باشد.

اگر این اطلاعات داخل Code قرار بگیرند، ممکن است وارد Git Repository یا حتی یک Pull Request شوند.

حتی اگر بعداً مقدار را از Code حذف کنیم، ممکن است همچنان در Git History باقی مانده باشد.

---

🔴 2. Deployment سخت می‌شود

فرض کنید Application شما سه Environment دارد:

Development
Staging
Production

اگر Connection String داخل Code باشد، برای هر Environment باید Code را تغییر دهیم.

در حالی که چیزی که باید تغییر کند Configuration است، نه Source Code.

---

🔴 3. Configuration بین Environmentها متفاوت است

مثلاً در Development ممکن است Database روی سیستم خودمان باشد:

Server=localhost;Database=MyDb;

اما در Production ممکن است Database روی یک Server یا Cloud Database قرار داشته باشد.

پس بهتر است Application همان Build را در Environmentهای مختلف اجرا کنیم و فقط Configuration را تغییر دهیم.

---

راه درست چیست؟

در ASP.NET Core می‌توانیم Configuration را از منابع مختلف دریافت کنیم.

مثلاً در appsettings.json:

{
  "ConnectionStrings": {
    "Default": "..."
  }
}

و در Code:

var connectionString =
    builder.Configuration.GetConnectionString("Default");

حالا Code دیگر به مقدار واقعی Connection String وابسته نیست.

---

در Production چه کنیم؟

برای اطلاعات حساس، معمولاً بهتر است Secretها را مستقیماً داخل appsettings.json یا Source Code قرار ندهیم.

یکی از گزینه‌ها استفاده از Environment Variables است:

Environment Variables
        +
Secret Management

مثلاً Application می‌تواند مقدار Connection String را از Environment دریافت کند.

در محیط‌های Containerized مثل Docker و Kubernetes نیز این الگو بسیار رایج است.

برای Secretهای حساس‌تر هم می‌توان از Secret Management مناسب محیط استفاده کرد.

مثلاً:

Development
    ↓
User Secrets / Local Configuration

Production
    ↓
Environment Variables
    +
Secret Management

---

یک قانون ساده

می‌توانیم کل این موضوع را در یک جمله خلاصه کنیم:

Code باید ثابت باشد، Configuration باید قابل تغییر باشد.

یعنی اگر Application را از Development به Production منتقل کردیم، نباید برای تغییر Database، API Key یا سایر تنظیمات مجبور شویم Source Code را تغییر دهیم.

این جداسازی یکی از اصول مهم برای داشتن Deployment قابل اعتماد و امن‌تر است.

یک نکته مهم

appsettings.json برای Configuration عمومی کاملاً کاربردی است، اما نباید تصور کنیم هر چیزی که داخل آن قرار می‌دهیم امن است.

مثلاً این کار مناسب نیست:

{
  "ConnectionStrings": {
    "Default": "Server=...;User=sa;Password=SuperSecret123"
  }
}

چون فایل Configuration هم ممکن است وارد Repository شود.

بهتر است Configuration را از Secret جدا کنیم و Secretهای حساس را از طریق مکانیزم مناسب Environment در اختیار Application قرار دهیم.

در نهایت:

Code
  ≠
Configuration
  ≠
Secrets

این تفکیک ساده، وقتی پروژه وارد CI/CD، Docker، Kubernetes یا Cloud می‌شود، اهمیتش چند برابر خواهد شد. 🔐