ابزارهای توسعه دهنده داخلی

1) نقش و مسئولیت پلتفرم توسعه دهنده (IDP)

• شروع سریع (قالب های خدمات، اسکلت API، خطوط لوله) ؛
• مونتاژ/تست/استقرار قابل پیش بینی ؛
• مدیریت امن اسرار، وابستگی ها و مصنوعات
• مشاهدهپذیری پیشفرض) ثبت وقایع/معیارها/ردپاها (
• دسترسی به داده های تست، mocs و sandboxes ارائه دهندگان ؛
• مستندات و «مسیرهای طلایی» برای سناریوهای معمولی.

هدف کاهش بار شناختی، Time-to-First-PR و زمان سرب برای تغییرات، بهبود قابلیت اطمینان و انطباق انتشار است.

2) اصول طراحی DX (توسعه دهنده تجربه)

قرارداد در مورد پیکربندی: استانداردها مهمتر از تنظیمات دستی هستند.
Golden Paths: حداقل مجموعه ای از راه حل های «پیش فرض» که 80٪ موارد را پوشش می دهد.
همه چیز به عنوان کد: خطوط لوله، زیرساخت ها، داشبورد، سیاستمداران - در Git.
امن به طور پیش فرض: SAST/DAST، SBOM، امضای مصنوعی، سیاست وابستگی.
قابلیت مشاهده: خدمات و ابزارها به طور خودکار تله متری را منتشر می کنند.
قابلیت حمل محیط: به صورت محلی = CI = stage = prod (تا آنجا که ممکن است).
بازخورد در دقیقه: تست سریع، lints، محیط پیش نمایش، روابط عمومی statuses.

3) معماری پلت فرم و اجزای کلیدی

DevPortal: دایرکتوری خدمات، قالب ها، اسناد، وضعیت پلت فرم، راه اندازی خطوط لوله و محیط های «یک کلیک».
CLI/skeletizer: تولید خدمات/توابع/کار با یک پشته (ورود به سیستم، سلامت، OpenAPI/Proto، مشاهده پذیری).
ساخت سیستم و ابزارهای monorepo: ذخیره سازی، مونتاژ افزایشی، مصنوعات قطعی.
CI/CD blooprints: خطوط لوله استاندارد برای خدمات (واحد، قراردادها، ادغام، e2e، تجزیه و تحلیل امنیتی، استقرار).
خطوط تست: testcontainers/sandboxes محلی ارائه دهندگان، کارخانه داده های عمومی و وسایل.
قابلیت مشاهده خارج از جعبه: اتصال OTel/Prometheus/logger از طریق یک ماژول.
مدیریت مخفی: ادغام با KMS/HSM، چرخش، سیاست دسترسی.
Ficheflags/experiments: SDK و کنسول برای نورد مترقی.

4) DevPortal: نقطه ورود مرکزی

• فهرست خدمات/کتابخانه ها/طرح ها (مالک، SLA، نسخه ها، آسیب پذیری ها) ؛
• دکمه «ایجاد سرویس» توسط قالب (بلافاصله با خط لوله و هشدار) ؛
• مستندات (استانداردهای codestyle، راهنماهای انتشار، playbooks حادثه) ؛
• وضعیت خدمات پلت فرم، ظرفیت، تغییرات (changelog) ؛
• Runbooks and Golden Paths: «چگونه یک نقطه پایانی اضافه کنیم»، «چگونه مهاجرت را شروع کنیم»، «چگونه یک ارائه دهنده را متصل کنیم».

5) CLI و قالب (skeletizer)

• چارچوب سرویس REST/gRPC/GraphQL با بررسی های بهداشتی ،/metrics ،/ready ؛
• middlewares آماده: درخواست همبستگی، احراز هویت، محدودیت نرخ ؛
• OpenAPI/Protobuf autogen + مدارهای چک برای CI ؛
• logger مدولار، ردیابی، معیارها ؛
• dockerfile + نوشتن برای توسعه محلی ؛
• مجموعه ای اساسی از تست ها و پیکربندی لینترها/قالب ها/prechukov.

• "devx new service --name payments-api --stack go-grpc --db postgres --events kafka --template v2 '

6) توسعه محلی و محیط های از راه دور

Dev Containers/Codespaces-analogue: محیط های مشابه برای همه، نصب سریع.
Docker Compose + Testcontainers: DB/caches/buses با یک فرمان به صورت محلی برداشته می شوند.
Tilt/Skaffold برای راه اندازی مجدد زنده به خوشه Kubernetes «dev».
Remote Dev: ساخت/تست های فشرده منابع در استخرهای اختصاصی اجرا می شود.

شیوه های خوب

تک '.tool-versions '/lockfiles برای نسخه های ابزار ؛

make/just- скрипты: «تست»، «محلی»، «بذر» ؛

اسرار محلی از طریق «dotenv» و یک ارائه دهنده مخفی با نقش های توسعه یافته.

7) مدیریت طرح ها و قراردادها

رجیستری طرح (JSON/Avro/Proto) با سیاست سازگاری ؛

تست قرارداد (Pact/Buf) به عنوان یک کار اجباری در CI ؛

نسخه API (SemVer)، پشتیبانی از دو نسخه، تولید خودکار SDK ؛

مهاجرت پایگاه داده (migrate/flyway/liquibase) - مرحله استاندارد شده خط لوله.

8) تست هرم و داده ها

تست واحد: سریع، موازی، اتصال برای پوشش منطق انتقادی.
تست قرارداد: مصرف کننده ↔ API/ارائه دهنده رویداد.
ادغام: با وابستگی های واقعی در ظروف.
E2E: حداقل اما نماینده مجموعه ای از پیش نویس.
داده های تست: کارخانه ها/رفع، مصنوعی بدون PII، siders برای محیط ؛ عکس های فوری DB - فقط غیر شخصی.

9) CI/CD: خطوط لوله استاندارد

1. خط/فرمت/مجوز/تولید SBOM.

2. SAST (تجزیه و تحلیل استاتیک) + سیاست وابستگی مسدود کردن «معیارها».

3. Unit → Contracts → Integration → E2E با مصنوعات و گزارش ها.

4. ساخت تصویر قطعی، امضا (sigstore/cosign)، فشار به رجیستری.

• URL ویژگی/پیش نمایش در هر PR ؛
• قناری/آبی سبز در مرحله ؛
• انتشار تولید پیشرفته از طریق ficheflag/ترافیک ؛

6. چک های پس از استقرار: هشدارها، بودجه خطا، بسته بندی خودکار در هنگام تخریب.

10) قابلیت مشاهده و debag محلی

ماژول «telemetry-starter»: شامل OTel SDK، صادر کنندگان، همبستگی 'trace _ id' ؛

داشبورد به عنوان کد: داشبورد و هشدارها در Git شرح داده شده است ؛

dev ردیابی محور: درخواست پروفایل به صورت محلی و در غرفه پیش نمایش ؛

گزارش های ساختار یافته (JSON)، محافظت در برابر PII، پوشاندن زمینه های حساس.

11) کیفیت کد و بررسی

خطوط تک/قالب ها و ایستگاه از پیش تنظیم (زبان خاص) ؛

قلاب های پیش ساخته (تست های حجم کوچک/کوچک) ؛

صاحبان کد و بررسی های اجباری برای مصنوعات کلیدی (طرح ها، مهاجرت ها، سیاست ها) ؛

چک لیست روابط عمومی: «چه چیزی تغییر کرده است ؟»، «امنیت ؟»، «سازگاری با عقب ؟»، «مهاجرت ؟» ».

12) توسعه ایمن (SSL) و زنجیره تامین

SCA (تجزیه و تحلیل وابستگی) و منابع allowlist ؛

SAST/DAST/IAST توسط نوع مصنوع ؛

SBOM برای هر ساخت، ذخیره سازی در مخازن مصنوعی ؛

امضای تصویر، گواهی (سطح SLSA)

سیاست مخفی: هیچ اسرار در Git، چرخش، اعتبار موقت ؛

سیاست به عنوان کد (OPA/Conftest) برای روابط عمومی زیرساخت.

13) Ficheflags، آزمایش ها و محیط های پیش نمایش

SDK از phicheflags در قالب ها، محدودیت: ops-flags در مقابل محصول ؛

نورد پیشرفته (1٪ → 25٪ → 100٪)، کانولوشن سریع ؛

محیط پیش نمایش برای هر PR (URL منحصر به فرد، ردیابی، داده های تست)، حذف خودکار پس از ادغام/بستن.

14) ربات ها و اتوماسیون

chatbots برای/استقرار ،/بازگشت ،/سیاهههای مربوط ،/runbook ؛

برچسب های خودکار و رانندگی خودکار در یک ردیاب اشکال ؛

قالب بلیط (حادثه، تغییر، RFC)

به روز رسانی خودکار وابستگی ها با شاخه های سبز و سبز.

15) مستندات و آموزش

نقاط «زنده» (OpenAPI/Proto) به عنوان منبع حقیقت ؛

یادداشت های فنی/RFC از طریق قالب های مشترک، انتشار خودکار از Git ؛

نمایش ویدئویی «چگونه یک پروژه را در 10 دقیقه راه اندازی کنم» ؛

جعبه شن و ماسه DevPortal با اسکریپت های گام به گام.

16) معیارهای عملکرد (DORA/SPACE)

DORA: زمان سرب، فرکانس استقرار، MTTR، تغییر نرخ شکست ؛

فضا: رضایت، عملکرد، فعالیت، ارتباطات ؛

اهداف برای سه ماهه: ↓Lead زمان توسط 30٪، نسخه های ↑chastota، ↓vremya onboarding به N ساعت.

17) کنترل دسترسی و چند اجاره ای

نقش پروفایل های مهندسی (dev، reviewer، releng، platform)

سیاست های محیط زیست: چه کسی می تواند در dev/stage/prod تخلیه کند ؛

سهمیه های فردی/محدودیت ها و جداسازی فضای نام برای شاخه های پیش نمایش/ویژگی.

18) ابزارهای داده و تجزیه و تحلیل

رویدادهای محلی خواندن پروفایل (Kafka/NATS) و پخش

ژنراتورهای مصنوعی و گمنام کننده های تخلیه ؛

لپ تاپ ها/اسکریپت های ad-hoc برای تجزیه و تحلیل معیارهای کیفیت خدمات و انتشار.

19) پیاده سازی نقشه راه

M0-M1 (MVP): DevPortal، قالب های خدمات، CI پایه (lint + unit + build)، مونتاژ محلی از طریق dev-containers، logging/metrics.
M2-M3: تست های قرارداد، محیط های پیش نمایش، تست های ادغام با ظروف تست، SAST/SCA، SBOM.
M4-M6: phicheflags، برنامه های پیشرفته، داشبورد به عنوان کد، سیاست به عنوان کد، استخرهای توسعه از راه دور، اتوژن SDK.
M6 +: انتشار ارکستراسیون، تجربه یک دکمه، ویترین داخلی کامپوننت/کتابخانه، معیارهای DORA/SPACE در DevPortal.

20) چک لیست بلوغ پلت فرم (گزیده ای)

• ایجاد یک سرویس با یک کلیک یک چارچوب کاری با معیارها/سیاهههای مربوط/آهنگ ها می دهد.
• محیط پیش نمایش به طور خودکار برای هر PR افزایش می یابد.
• قرارداد تست اجباری است و تغییرات ناسازگار را مسدود می کند.
• SBOM برای هر ساخت منتشر می شود، تصاویر امضا می شوند.
• مشاهده/هشدار و داشبورد - توسط کد و در مخزن.
• Ficheflags از کنسول در دسترس هستند، رول ها مترقی هستند.
• Runbooks/playbooks با هشدارها مرتبط هستند و در DevPortal قابل مشاهده هستند.
• معیارهای DORA/SPACE در صفحه اصلی DevPortal نمایش داده می شود.
• در حال توسعه یک توسعه دهنده جدید ≤ 1 روز کاری قبل از اولین PR.

خلاصه

یک پلت فرم قوی توسعه دهنده داخلی یک پشته ناهمگن را به یک "خط لوله" تحویل تبدیل می کند: از "ایجاد یک سرویس" به "تولید با نورد امن. قالب های استاندارد، DevPortal، تست قرارداد، محیط های پیش نمایش، قابلیت مشاهده و پیش فرض های امنیتی برای انتشار سریع و قابل پیش بینی بدون به خطر انداختن کیفیت و انطباق.