چرخه عمر توسعه API

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

هر سازمانی چرخه عمر توسعه نرم‌افزار (SDLC) منحصر به فردی دارد. اغلب لازم است که استقرار پروکسی API با همان فرآیندهایی که امروزه برای توسعه، آزمایش و استقرار سایر برنامه‌ها استفاده می‌کنید، همگام‌سازی و همسو شود.

سرویس‌های API ابزارها و APIهای RESTful را ارائه می‌دهند که شما را قادر می‌سازند تا استقرار و مدیریت پروکسی API را در SDLC سازمان خود ادغام کنید. یکی از کاربردهای رایج API RESTful نوشتن اسکریپت‌ها یا کدهایی است که به صورت برنامه‌نویسی، پروکسی‌های API را مستقر می‌کنند، یا پروکسی‌های API را از یک محیط به محیط دیگر منتقل می‌کنند، به عنوان بخشی از یک فرآیند خودکار بزرگتر که برنامه‌های دیگر را نیز مستقر یا منتقل می‌کند. سرویس‌های API هیچ فرضی در مورد SDLC شما (یا هر کس دیگری، در این مورد) ارائه نمی‌دهد. در عوض، عملکردهای اتمی را ارائه می‌دهد که می‌توانند توسط تیم توسعه شما هماهنگ شوند تا چرخه عمر توسعه API شما را خودکار و بهینه کنند.

سرویس‌های API، APIها در مرجع API مستند شده‌اند. برای شروع به مرجع API مراجعه کنید.

محیط‌ها

هر سازمانی در Apigee Edge حداقل دو محیط استقرار دارد که برای پروکسی‌های API در دسترس هستند: «آزمایش» و «تولید». تمایز بین این دو محیط دلخواه است - هر محیط به سادگی توسط مجموعه‌ای متفاوت از آدرس‌های شبکه (URL) شناسایی می‌شود. هدف این است که دامنه‌ای را در اختیار شما قرار دهیم که در آن بتوانید پروکسی‌های API را قبل از اینکه API در معرض توسعه‌دهندگان خارجی قرار گیرد، بسازید و تأیید کنید.

شما می‌توانید از این محیط‌ها برای همگام‌سازی توسعه پروکسی API پردازش‌شده با SDLC خود استفاده کنید. هر محیط توسط یک آدرس شبکه تعریف می‌شود که به شما امکان می‌دهد ترافیک بین پروکسی‌های API که روی آنها کار می‌کنید و آنهایی که توسط برنامه‌ها در زمان اجرا مورد دسترسی قرار می‌گیرند را تفکیک کنید. آدرس‌های شبکه موجود برای هر محیط در مجموعه VirtualHostهای موجود در آن محیط تعریف می‌شوند.

TLS/SSL ورودی و سرور به طور خودکار برای هر محیط فعال می‌شود. دو VirtualHost در هر محیط از پیش تعریف شده‌اند: default و secure . پیش‌فرض یک آدرس HTTP را تعریف می‌کند، در حالی که امن یک آدرس HTTP/S را با TLS/SSL از پیش پیکربندی شده سمت سرور تعریف می‌کند. در پیکربندی پروکسی API، شما مشخص می‌کنید که ProxyEndpoint باید به کدام VirtualHostها گوش دهد. هنگام ارتقا به prod، معمولاً HTTP را با حذف VirtualHost default از پیکربندی پروکسی API غیرفعال می‌کنید.

برای مثال، ProxyEndpoint زیر به HTTP و HTTPS گوش می‌دهد.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>default</VirtualHost>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

با حذف VirtualHost default از پیکربندی ProxyEndpoint، یک پروکسی API ایجاد می‌کنید که فقط به HTTPS گوش می‌دهد و نه به HTTP.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

با انتخاب گزینه Environments در منوی اصلی رابط کاربری مدیریت، می‌توانید ببینید کدام VirtualHostها در یک محیط در دسترس هستند.

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

استقرار پروکسی‌های API در محیط‌ها

وقتی یک پروکسی API ایجاد می‌کنید، باید تصمیم بگیرید که در کدام محیط کار خواهید کرد. می‌توانید یک پروکسی API جدید در محیط عملیاتی ایجاد کنید، اما این کار توصیه نمی‌شود زیرا ممکن است API را قبل از آماده شدن در اختیار توسعه‌دهندگان قرار دهید. به طور کلی، با ایجاد یک پروکسی API در test شروع کنید که پس از آزمایش، آن را به prod ارتقا می‌دهید .

برای اطلاعات بیشتر، به درک استقرار مراجعه کنید.

توسعه تکراری در تست

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

ارتقاء به تولید

وقتی یک پروکسی API به طور کامل پیاده‌سازی و آزمایش شد، آماده ارتقا به «تولید» است. نسخه آزمایشی پروکسی API برای بازنویسی نسخه آزمایشی پروکسی API مستقر در تولید استفاده خواهد شد.

سرویس‌های API قابلیت‌هایی را برای اطمینان از استقرار یکپارچه‌ی پروکسی‌های API فراهم می‌کنند و تأثیر بر برنامه‌ها و کاربران نهایی را در طول فرآیند استقرار به حداقل می‌رسانند.

استقرار اسکریپت‌نویسی

رابط کاربری مدیریت Apigee Edge به شما این امکان را می‌دهد که پروکسی‌های API را مستقیماً از سازنده پروکسی API برای تولید مستقر کنید. با این حال، در بسیاری از موارد، الزامات امنیت، قابلیت اطمینان و ثبات، تیم‌های توسعه را ملزم به اسکریپت‌نویسی رویه‌های استقرار می‌کند. برای انجام این کار، می‌توانید کد و اسکریپت‌هایی بنویسید که API RESTful ارائه شده توسط سرویس‌های API را فراخوانی کنند.

منابع محیطی

برای کنترل بیشتر در طول ارتقاء، توصیه می‌شود که فقط پروکسی‌های API را در مرحله آزمایش تکرار کنید و تا حد امکان تغییرات کمی را در پروکسی‌های API مستقر در مرحله تولید ایجاد کنید.

برای انجام این کار، باید مطمئن شوید که منابع خاص مرتبط با هر محیط به گونه‌ای پیکربندی شده‌اند که بتوانند در پیکربندی پروکسی API ثابت بمانند.

• URLهای هدف: فراخوانی URLهای مختلف backend توسط API Proxyها در طول آزمایش و تولید، امری رایج است. می‌توانید از پیکربندی‌های TargetServer برای ایجاد پیکربندی‌های TargetEndpoint مستقل از محیط استفاده کنید. به بخش متعادل‌سازی بار در سرورهای backend مراجعه کنید.
• حافظه‌های پنهان و نقشه‌های کلید/مقدار: هر دو منبع پایدار توسط محیط محدود می‌شوند. شما باید مطمئن شوید که از قراردادهای نامگذاری استفاده می‌شود تا پروکسی‌های API بتوانند داده‌ها را بدون نیاز به تغییرات پیکربندی در طول ارتقاء ذخیره کنند. به ایجاد و ویرایش حافظه پنهان محیط مراجعه کنید.
• اهداف فراخوانی سرویس: فراخوانی‌های سرویس ممکن است بسته به محیط از اهداف متفاوتی استفاده کنند، مثلاً اگر یک فراخوانی سرویس در محیط آزمایشی از یک سرویس آزمایشی استفاده کند. به سیاست فراخوانی سرویس مراجعه کنید.

برای مستقل کردن پیکربندی‌های پروکسی API از محیط، می‌توانید از دستورات شرطی نیز استفاده کنید. دستورات شرطی ساخته شده با متغیر environment.name می‌توانند برای ارزیابی محیط فعلی قبل از اجرای یک سیاست یا قبل از مسیریابی به یک URL در backend استفاده شوند.

برای اطلاعات بیشتر، به درک استقرار مراجعه کنید.