از زمانی که کسب درآمد از APIها بیشتر شده، توجه‌ها به سمت APIها هم بیشتر شده است. حالا دو معیار کیفیت و قابلیت اطمینان بودن جز اهداف کلیدی مورد نظر شرکت‌هایی است که به دنبال استفاده از APIها در مقیاس‌های کلان هستند و از طریق فرایندهای devops هم به خوبی پشتیبانی می‌شود. حجم بازار این حوزه ما به قدری زیاد است که اگر به آن فکر کنید، بدون شک گیج می‌شوید: آمازون هر ۱۱.۷ ثانیه یک کد را روی پروداکشن قرار می‌دهد، نتفلیکس بیشتر از ۲۰ هزار دیپلوی را در روز انجام می‌دهد و فیدلیتی با انتشار فریم‌ورک جدید هر سال ۲.۳ میلیون دلار را صرفه‌جویی می‌کند. بنابراین اگر API دارید، ممکن است بخواهید API خود را از طریق پایپ لاین CI/CD دیپلوی کنید. 

استقرار API از طریق پایپ لاین CI/CD یکی از فعالیت‌های کلیدی «مدیریت چرخه حیات کامل API» است. پیشنهاد می‌کنیم در این زمینه یادداشت «مدیریت چرخه حیات API؛ از توسعه تا بازنشستگی» را بخوانید. فعالیت «استقرار» که بین فاز «پیاده‌سازی» و «ایمنی» قرار دارد، شامل تمامی فرایندهای مورد نیاز برای آوردن API از کد منبع به محیط تولید می‌شود. به طور دقیق‌تر، یکپارچه‌سازی مداوم و تحویل مداوم را تحت پوشش قرار می‌دهد. 

یک API «فقط یک تکه‌ی دیگر از نرم‌افزار» نیست. 

به جای اینکه به API به عنوان تکه‌ای از نرم‌افزار مانند بخش‌های دیگر فکر کنید، به آن به شکل بخشی نگاه کنید که: 

• در ارتباط با یک رابط برای برقراری ارتباط است. 
• با اکوسیستمی از مصرف‌کنندگان در ارتباط است که با این نرم‌افزار ارتباط برقرار می‌کنند. 
• با توسعه‌دهندگان مختلفی که این API را استفاده می‌کنند، در ارتباط است. 

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

اصول کلی برای استقرار API از طریق پایپ‌لاین CI/CD

۱- از رویکرد اول قرارداد استفاده کنید. 

اگرچه بیشتر اوقات استفاده از رویکرد اول کد مانع از استقرار API از طریق پایپ لاین CI/CD نمی‌شود، اما استفاده از رویکرد اول قرارداد فرایندهای شما را بسیار قابل اعتمادتر و ساده‌تر می‌کند. 

در رویکرد اول قرارداد، قرارداد API (برای APIهای REST، قرارداد API باز نامیده می‌شود) خیلی زودتر از مرحله اجرا ایجاد می‌شود. این یک همکاری بین مالک محصول، معماران، توسعه‌دهندگان و مشتریان اولیه است. Apicurio Studio می‌تواند به شما کمک کند تا به راحتی مشخصات OpenAPI را به صورت مشترک ایجاد کنید. 

۲- از آزمایش‌پذیری API خود اطمینان حاصل کنید

برای استقرار API از طریق پایپ لاین CI/CD به روش خودکار، آزمایش‌هایی لازم است. انواع مختلفی از آزمون‌ها وجود دارد و برای پوشش همه آن‌ها یک کتاب کامل لازم است. برای استقرار API خود از طریق پایپ لاین CI/CD، حداقل باید موارد زیر را داشته باشید: 

تست‌های واحد: برای آزمایش هر یک از کوچک‌ترین اجزای نرم‌افزار به صورت جداگانه 

تست‌های یکپارچه‌سازی: برای آزمایش بخش بزرگتری از اجزای نرم‌افزار با هم. 

آزمون‌های پذیرش: برای اطمینان از برآورده شدن انتظارات کسب‌وکاری (به عنوان بخشی از روش‌های توسعه مبتنی بر آزمون پذیرش)

تست‌های End-to-End: برای اطمینان از اینکه هر جزء نرم‌افزاری در زنجیره طبق انتظار، در یک محیط تولید مانند کار می‌کند.

تست‌های عملکرد: برای اطمینان از اینکه عملکرد توسط یک اصلاح یا یک ویژگی جدید کاهش نمی‌یابد. 

تست های واحد و یکپارچه‌سازی به خوبی از سوی توسعه دهندگان شناخته شده است. بیایید روی استفاده از موارد بعدی تمرکز کنیم.

تست های پذیرش را می توان از طریق یک ابزار اختصاصی مانند Microcks مدیریت کرد و توسط پایپ‌لاین CI/CD شما راه اندازی کرد.تست‌های عملکرد نیز می‌توانند خودکار شوند. می‌توانید درباره خودکارسازی تست‌های عملکرد بیشتر جستجو کنید. 

۳- به نسخه‌بندی معنایی پایبند باشید

هنگام انتشار نسخه های جدید API خود، بسیار مهم است که به نسخه‌دهی معنایی(semantic) پایبند باشید. این به پایپ لاین CI/CD شما کمک می‌کند تا بداند چگونه با نسخه‌های جدید مقابله کند: نسخه‌های جزئی جدید با نسخه‌های قبلی سازگار هستند و می‌توانند «در جای خود» مستقر شوند. برای راضی نگه داشتن مشتریان فعلی، باید نسخه‌های اصلی «در کنار هم» مستقر شوند.

۴- ناتوان باشید

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

۵- اصول API Management as Code را به کار بگیرید

مشابه اصل “زیرساخت به عنوان کد”، اصل “API-Management-as-Code” می‌گوید که وضعیت راه حل مدیریت API شما به طور کامل توسط محتوای مخازن Git شما تعیین می‌شود. سرویس‌ها توسط فایل apecification OpenAPI آن‌ها که در مخزن Git شما متعهد شده‌اند، تعریف می‌شوند. برنامه‌های کاربردی در یک فایل مصنوع، همچنین در مخزن Git شما تعریف شده است و… 

مراحل استقرار API از طریق پایپ لاین CI/CD

 ۱- ریلیز را آماده کنید

از آنجایی که شما اصول API-Management-as-Code را اعمال کردید، تمام ساخته‌های شما نسخه شده و در یک مخزن Git ذخیره می شوند. برای استقرار API خود از یک پایپ لاین CI/CD، با بررسی مخزن شروع کنید.

داخل مخزن Git شما قرارداد API قرار دارد. فایل مشخصات OpenAPI را بخوانید و اطلاعات مربوطه را برای خط لوله خود استخراج کنید:

فیلد “info.version” برای اعمال نسخه‌سازی معنایی مفید است.

از فیلدهای پسوند فروشنده (فیلدهای “x-*”) در شی “info” می‌توان برای نگهداری ابرداده (واحد تجاری مسئول، کانال هدف، وضعیت و غیره) استفاده کرد.

از مشخصات OpenAPI، یک Mock ایجاد کنید که در اختیار پذیرندگان اولیه شما قرار خواهد گرفت. بعداً، همه مصرف کنندگان API شما برای توسعه و پیاده‌سازی سرویس شما در محصول خود از آن استفاده خواهند کرد. ابزارهایی مانند Microcks می‌توانند از فایل مشخصات OpenAPI شما یک ماک تولید کنند.

از این داده ها، می توانید نسخه و وضعیت API را محاسبه کنید.

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

وضعیت API را می توان از فیلدهای افزونه فروشنده یا فراداده های فرم آزاد محاسبه کرد. از آن حالات متوالی عبور می کند:

ایجاد شده: API در حالت کار کردن در پورتال توسعه‌دهنده موجود است، اما فقط برای کاربران اولیه قابل دسترسی است. 

منتشر شده: API نوعی GA است، هر کسی می‌تواند مشترک آن شود. اشتراک از طریق گردش کاری انتخاب شده، انجام می‌شود. 

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

بازنشسته شده: API از پورتال مدیریت و از پورتال توسعه‌دهنده حذف می‌شود. 

۲- API را مستقر کنید

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

اگر API شما به خط مشی‌های دروازه‌ای سفارشی نیاز دارد، باید یک تصویر کانتینری از دروازه‌ی API خود بسازید که حاوی خط مشی سفارشی باشد. کد خط مشی نیز در مخزن Git شما ذخیره می‌شود. پس از ساخت، می‌توانید استقرار جدیدی از کانتینر دروازه API را راه‌اندازی کنید. 

۳- API خود را تست کنید

اکنون می‌توانید با اجرای آزمون‌های پذیرش ( از روش توسعه مبتنی بر آزمون پذیرش)، از برآورده شدن انتظارات تجاری اطمینان حاصل کنید. ابزاری مانند Microcks می‌تواند به شما در ذخیره، مدیریت و اجرای تست‌ها برای APIهای خود کمک کند. ذخیره همه مجموعه‌های آزمایشی API در یک مکان راحت است: برای هر نسخه جزئی، می‌توانید مجموعه‌های آزمایشی همه نسخه‌های قبلی را اجرا کنید. بنابراین اطمینان حاصل می‌شود که نسخه جدید واقعا با نسخه‌های قبلی سازگار است. 

برای استقرار API خود از طریق یک پایپ‌لاین CI/CD، باید برنامه‌های کاربردی را از راه فایل‌های دست‌ساز ذخیره شده در مخزن Git خود منتشر کنید. این برنامه‌های مرحله‌ای، پیشنهاد خدمت شما برای مشتریان APIهای شما هستند. آن‌ها برای هر روش سهمیه، قوانین قیمت‌گذاری برای کسب درآمد و لیست ویژگی‌هایی را در اختیار دارند. برنامه‌های کاربردی به عنوان فایل‌های YAML توصیف می‌شوند. آن‌ها را می‌توان با دست یا از یک رابط کاربری گرافیکی به وسیله مالک محصول ایجاد کرد و در مخزن Git شما قرار داد. 

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

۴- API خود را منتشر کنید

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

آخرین گام استقرار API از طریق پایپ‌لاین CI/CD این است که به مصرف‌کنندگان API موجود خود اطلاع دهید که یک نسخه کوچک جدید مستقر شده است. همچنین اگر این بخشی از فرایندهای شما باشد، می‌توانید یادداشت انتشار عمومی را برای آن‌ها ارسال کنید. 

بازگشت به عقب (Rollback)

اگر در طول پایپ‌لاین CI/CD مشکلی پیش بیاید، ممکن است علاقه‌مند باشید که هر گونه تغییری که تاکنون انجام شده، پس بگیرید. اگر از اصول گفته شده و روش‌های API As A Code Management پیروی کنید، به راحتی از پس این کار بر می‌آیید. شما فقط کافی است که یک پایپ‌لاین جدید را با ابعادی کوچک‌تر از نسخه قبلی ایجاد کنید تا وضعیت قبلی سیستم بازیابی شود.

محیط‌ها

اگر محیط‌های متفاوتی در شرکت خود دارید، این مراحل باید در هر محیط تکرار شوند. هر چند باید به نکات زیر هم توجه شود: 

• مرحله اول (آماده‌سازی انتشار) یکبار برای همیشه انجام می‌شود. 
• تصویر کانتینر درگاه API نیز فقط یک بار ساخته می‌شود و سپس به طور یکسان در هر محیط ساخته می‌شود. 
• تست‌های پذیرش در محیط‌های کاربردی اجرا می‌شوند. در حالی که تست‌های end-to-end در محیط‌های مشابه تولید (و همچنین تست‌های عملکرد) اجرا می‌شوند. 
• مصرف‌کنندگان API فقط در محیط‌های پروداکشن و شبه پروداکشن مطلع می‌شوند. 

اینکه به چه تعداد محیط نیاز دارید، کاملا به فرایندهای داخلی شما بستگی دارد. برخی از شرکت‌ها با سه محیط سازگارند و برخی دیگر به ۹ محیط نیاز دارند.