Azure SQL Developer؛ اجرای موتور واقعی Azure SQL روی Docker برای توسعه محلی

مایکروسافت Azure SQL Developer را در Private Preview معرفی کرده است: موتور واقعی Azure SQL Database داخل container برای laptop، توسعه محلی و CI. در این راهنما تفاوت آن با SQL Server container و LocalDB را روشن می کنیم، نصب و اتصال EF Core را می سازیم، محدودیت های preview را بررسی می کنیم و نشان می دهیم چه زمانی «فقط connection string را عوض کردن» واقعاً قابل اتکاست.

Azure SQL Developer دقیقاً چیست؟

مایکروسافت در 23 ژوئیه 2026 نسخه Private Preview این محصول را معرفی کرد. پیام اصلی ساده است: توسعه دهنده به جای اتصال به database مشترک cloud یا استفاده از engine متفاوت روی سیستم خود، همان Azure SQL Database engine را داخل container اجرا می کند. طبق اعلام رسمی، defaultها، T-SQL، system viewها و error messageها با سرویس cloud هم راستا هستند. این سطح از parity می تواند خطاهایی را که فقط بعد از deploy آشکار می شوند، زودتر وارد inner loop کند.

این محصول SQL Server image با branding تازه نیست. تفاوت engine مهم است، زیرا Azure SQL Database و SQL Server با وجود اشتراک عمیق، release cadence و قابلیت های دقیقاً یکسان ندارند. اگر target production شما Azure SQL Database است، تست migration، query و driver روی همان engine ارزش بیشتری از شباهت تقریبی دارد. در عین حال، «همان engine» را نباید با «همان محیط managed cloud» یکی گرفت؛ network control plane، identity، backup service، geo-replication و policyهای PaaS داخل container بازتولید نمی شوند.

مایکروسافت سازگاری stack را برای driverهای node-mssql، mssql-python، pyodbc و mssql-jdbc و ORMهایی مانند Prisma، SQLAlchemy، EF Core، Django و TypeORM اعلام کرده است. این یعنی بیشتر برنامه ها بدون تغییر data layer می توانند container را مصرف کنند. نقطه اتصال، connection string است. با این حال migration از محیط قبلی باید همراه integration test باشد؛ هر پروژه ممکن است dependency، collation، authentication یا feature خاص خود را داشته باشد.

مقایسه Azure SQL Developer با SQL Server container و LocalDB

LocalDB برای بسیاری از پروژه های .NET سریع و ساده است، اما روی Windows متمرکز است و lifecycle آن با container متفاوت است. SQL Server container برای تست SQL Server بسیار مناسب است، ولی اگر production Azure SQL Database باشد ممکن است feature availability یا default متفاوت شود. Azure SQL Developer دقیقاً شکاف parity engine را هدف گرفته است. انتخاب درست از target production شروع می شود، نه از ابزار موردعلاقه تیم.

در پروژه ای که باید هم SQL Server on-premises و هم Azure SQL Database را پشتیبانی کند، یک container واحد کافی نیست. test matrix باید هر target رسمی را جدا اجرا کند. Azure SQL Developer نباید تست SQL Server را حذف کند و SQL Server container نیز نباید نماینده کامل Azure SQL فرض شود. معماری چندهدفه هزینه دارد، ولی این هزینه باید در CI دیده شود نه پس از استقرار مشتری.

راه اندازی container از صفر

در مرحله Private Preview ابتدا باید ثبت نام کنید و credential pull-only رجیستری دریافت کنید. مایکروسافت هشدار داده این credentialها shared cohort secret هستند و ممکن است rotate شوند؛ بنابراین آن ها را در repository، Dockerfile یا log قرار ندهید. برای CI از secret store پلتفرم استفاده کنید. پس از login، image در اولین docker run pull می شود و در اجراهای بعدی می تواند offline کار کند.

docker login sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io -u <username>

docker run \
  --name sqldb \
  -e "ACCEPT_EULA=Y" \
  -e "MSSQL_SA_PASSWORD=YourStr0ng_Passw0rd" \
  -p 1433:1433 \
  -d sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io/azure-sql/db-dev:latest

password باید policy پیش فرض SQL را رعایت کند: دست کم هشت کاراکتر و ترکیبی از حروف بزرگ، حروف کوچک، عدد و symbol. این مثال برای توسعه است؛ password واقعی را در shell history یا فایل اشتراکی نگه ندارید. روی Apple Silicon یا میزبان non-x64 باید --platform linux/amd64 اضافه شود، چون image فعلی x64 است و با emulation اجرا می شود. این emulation می تواند performance تست را با production یا x64 local متفاوت کند.

پس از بالا آمدن container، database برنامه خودکار ساخته نمی شود؛ این رفتار با Azure SQL Database هم راستاست. می توانید از sqlcmd میزبان یا نسخه bundled داخل container استفاده کنید. flag -C در نمونه توسعه certificate را trust می کند؛ production identity و TLS باید جدا طراحی شود.

docker ps --filter "name=sqldb"

docker exec sqldb /opt/mssql-tools18/bin/sqlcmd \
  -S localhost \
  -U sa \
  -C \
  -Q "IF DB_ID('appdb') IS NULL CREATE DATABASE appdb;"

برای ماندگاری داده در restart می توانید volume تعریف کنید، اما testهای integration معمولاً از database یا container disposable سود می برند. هدف test isolation این است که هر run از state شناخته شده آغاز شود. در توسعه روزمره، volume مفید است؛ در CI، ساخت schema با migration و seed تکرارپذیر بهتر از cache کردن state مبهم است.

اتصال ASP.NET Core و EF Core

در .NET بهتر است connection string از environment یا secret configuration خوانده شود و کد application بین local و Azure تغییر نکند. provider همچنان SQL Server است، زیرا EF Core از پروتکل و dialect سازگار استفاده می کند. برای local container می توانید TrustServerCertificate=true داشته باشید؛ برای Azure production از Microsoft Entra authentication یا روش سازمانی استفاده کنید. قرار دادن user و password production در appsettings اشتباه است.

var builder = WebApplication.CreateBuilder(args);

var connectionString = builder.Configuration
  .GetConnectionString("AppDb")
  ?? throw new InvalidOperationException("AppDb connection string is missing.");

builder.Services.AddDbContext<AppDbContext>(options =>
  options.UseSqlServer(connectionString, sql =>
    sql.EnableRetryOnFailure()));

var app = builder.Build();
app.Run();

نمونه local می تواند به Server=localhost,1433;Database=appdb;User Id=sa;Password=...;TrustServerCertificate=true اشاره کند. در Azure connection string به server ابری و authentication مناسب تغییر می کند. شعار «فقط یک خط connection string» زمانی درست است که application به abstractionهای خارج از engine وابسته نباشد، migrationها روی Azure نیز مجاز باشند و policyهایی مانند firewall و identity فراهم شده باشند. این موارد در deploy pipeline مسئولیت جدا دارند.

{
  "ConnectionStrings": {
    "AppDb": "Server=localhost,1433;Database=appdb;User Id=sa;Password=YourStr0ng_Passw0rd;TrustServerCertificate=true"
  }
}

پس از ایجاد database، migrationها را روی container اعمال کنید و test واقعی query بنویسید. فقط موفق شدن Database.Migrate() کافی نیست؛ transaction، concurrency، unique constraint، timeout، decimal precision، JSON یا vector queryهایی را که در محصول دارید پوشش دهید. parity engine بیشترین ارزش را زمانی دارد که test suite از featureهای واقعی استفاده کند.

نمونه Docker Compose برای توسعه

services:
  db:
    image: sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io/azure-sql/db-dev:latest
    platform: linux/amd64
    environment:
      ACCEPT_EULA: "Y"
      MSSQL_SA_PASSWORD: ${MSSQL_SA_PASSWORD}
    ports:
      - "1433:1433"

  api:
    build: .
    depends_on:
      - db
    environment:
      ConnectionStrings__AppDb: >-
        Server=db,1433;Database=appdb;User Id=sa;
        Password=${MSSQL_SA_PASSWORD};TrustServerCertificate=true

depends_on فقط ترتیب start را کنترل می کند و readiness database را تضمین نمی کند. application یا entrypoint باید retry محدود، health check و timeout روشن داشته باشد. برای migration بهتر است job یا init step جداگانه بسازید تا چند instance هم زمان schema را تغییر ندهند. این اصول مستقل از Azure SQL Developer هستند، اما container واقعی تر باعث می شود raceها زودتر دیده شوند.

Integration Test واقعی در CI

یکی از سناریوهای رسمی محصول، اجرای container به عنوان service در GitHub Actions یا Azure Pipelines است. مزیت آن حذف database مشترک و کاهش flaky test ناشی از state همسایه است. هر pipeline می تواند instance موقت خود را بالا بیاورد، migration را اجرا کند و بعد از test حذف شود. Private Preview یک چالش اضافه دارد: runner باید به registry دسترسی داشته باشد و credential به صورت secret امن تزریق شود.

در CI بهتر است tag دقیق image ثبت شود، نه اینکه برای build قابل تکرار همیشه latest مصرف شود؛ اگر preview فقط latest ارائه می کند، digest pull شده را در log کنترل شده ثبت و تغییر engine را با test baseline مدیریت کنید. همچنین زمان startup، health probe و cleanup در failure را اندازه بگیرید. container leak روی self-hosted runner هم disk را پر می کند و هم ممکن است state test بعدی را آلوده سازد.

• credential رجیستری فقط در secret store و با mask شدن log نگهداری شود.
• database برای هر run نام یا container مستقل داشته باشد.
• readiness با query واقعی بررسی شود، نه فقط open بودن port.
• migration و seed idempotent یا disposable باشند.
• بعد از test، log database و artifact خطا جمع آوری و container حذف شود.
• testهای production identity، firewall و PaaS control plane در محیط Azure جدا اجرا شوند.

قابلیت های AI، Vector و Agent Skills

مایکروسافت برای Azure SQL Developer قابلیت های native مانند نوع VECTOR، تابع VECTOR_DISTANCE، AI_GENERATE_EMBEDDINGS و CREATE EXTERNAL MODEL را ذکر کرده است. این ترکیب امکان prototype کردن RAG با model محلی و سپس تغییر provider به Azure OpenAI در cloud را فراهم می کند. DiskANN index در زمان اعلام هنوز در حال توسعه معرفی شده، پس performance و availability آن را برای production فرض نکنید.

Agent skills نیز برای هدایت ابزارهای coding agent منتشر شده اند. فرمان npx skills add microsoft/azure-sql-database-container مجموعه instructionهایی را نصب می کند که agent را از انتخاب اشتباه SQL Server image یا اختراع رفتار غیرواقعی دور می کند. مایکروسافت سازگاری را برای GitHub Copilot، Claude Code، Codex و Cursor ذکر کرده است. این skillها automation را آسان می کنند، اما review انسانی migration، secret، schema و command اجراشده را حذف نمی کنند.

npx skills add microsoft/azure-sql-database-container

skill azuresql-db-local-to-cloud مسیر راه اندازی local و deploy با تغییر connection string را هدف می گیرد. skillهای FAQ و feedback نیز محدودیت های engine را به agent توضیح می دهند و می توانند draft گزارش issue بسازند؛ طبق منبع رسمی چیزی بدون تأیید کاربر submit نمی شود. در تیم سازمانی، نسخه skill و محتوای instruction باید مانند dependency code review شود، زیرا agent براساس آن command و configuration تولید می کند.

محدودیت ها و ریسک های Private Preview

مهم ترین محدودیت، وضعیت Private Preview است. برای registry باید ثبت نام و credential دریافت شود، credentialها ممکن است rotate شوند و SLA یا ثبات public product را نباید انتظار داشت. image در حال حاضر x64 است؛ اجرای Apple Silicon تحت emulation برای functional test قابل استفاده است ولی benchmark قابل اتکا نیست. همچنین featureهایی که تیم Azure SQL هنوز در حال توسعه اعلام کرده، نباید dependency قطعی release شوند.

Container همان database engine است، نه کل Azure. قابلیت های control plane مانند ایجاد logical server، firewall rule، private endpoint، geo-replication، automated backup policy، auditing managed و Entra integration production باید در محیط Azure تست شوند. local parity مسئله SQL behavior را حل می کند؛ deployment parity نیازمند infrastructure test و staging cloud است. این تفکیک را در test pyramid مستند کنید.

مسئله دیگر data persistence و license/EULA است. محیط توسعه نباید به database production غیرمجاز تبدیل شود. lifecycle، backup local و حذف داده های حساس را تعریف کنید. برای workshop آفلاین، image را از قبل pull کنید اما credential و image distribution را مطابق شرایط preview انجام دهید. رایگان بودن local dev و CI به معنی مجاز بودن هر نوع hosting نیست.

Azure SQL Developer برای چه کسی مناسب است؟

ارزش اصلی برای تیمی است که Azure SQL Database target قطعی دارد و از اختلاف local engine، latency محیط مشترک یا هزینه databaseهای موقت آسیب می بیند. اگر test suite ضعیف باشد، تغییر container به تنهایی کیفیت را بالا نمی برد. ابتدا critical queryها و migrationها را قابل آزمایش کنید، سپس engine وفادارتر را وارد کنید. ابزار خوب زمانی سود می دهد که feedback loop مهندسی نیز طراحی شده باشد.

پرسش های متداول

آیا Azure SQL Developer همان SQL Server Docker image است؟

خیر. مایکروسافت آن را Azure SQL Database engine واقعی، نه clone و نه SQL Server image معرفی کرده است.

آیا برای استفاده Azure subscription لازم است؟

برای local dev و CI طبق اعلام رسمی subscription یا کارت بانکی لازم نیست، اما در Private Preview باید credential رجیستری بگیرید.

آیا روی Apple Silicon اجرا می شود؟

image فعلی x64 است و باید با --platform linux/amd64 تحت emulation اجرا شود.

آیا EF Core و Prisma کار می کنند؟

مایکروسافت سازگاری EF Core، Prisma و چند ORM و driver رایج را اعلام کرده است.

آیا پس از pull اولیه offline است؟

بله، منبع رسمی می گوید پس از اولین pull بدون اینترنت اجرا می شود.

آیا تمام قابلیت های Azure SQL cloud در container وجود دارد؟

engine محلی است؛ control plane و سرویس های managed cloud باید جداگانه در Azure آزمایش شوند.

جمع بندی

Azure SQL Developer پاسخ مشخصی به شکاف local و cloud می دهد: اجرای همان Azure SQL Database engine در Docker برای development و CI. این محصول می تواند migration و query bug را زودتر آشکار کند، database مشترک را حذف کند و prototypeهای vector را محلی سازد. اما Private Preview، image x64 و نبود control plane managed محدودیت های واقعی اند و باید در rollout منعکس شوند.

فرمان های رسمی، frameworkهای پشتیبانی شده، قابلیت های vector، مسیر agent skills و شرایط preview در معرفی رسمی Azure SQL Developer آمده است. پیشنهاد اجرایی این است که آن را ابتدا در یک service کم ریسک و CI آزمایشی وارد کنید، نه اینکه یک باره تمام محیط local تیم را جایگزین کنید.