آنچه باید در مورد پورتال توسعه دهندگان داخلی بدانید

برای تیم های مهندسی پلت فرم، سوال بزرگ این است: بسازید یا بخرید؟

کمک به توسعه دهندگان برای انجام کارهای بیشتر در زمان کمتر به اولویت سازمان ها تبدیل شده است. با گسترش دامنه SaaS و محبوبیت بیشتر DevOps، شرکت‌ها متوجه می‌شوند که باید بار شناختی را بر روی توسعه‌دهندگان کاهش دهند، زیرا اغلب باید از تمام ریزسرویس‌های در دسترس خود آگاه باشند.

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

این دسته که پورتال‌های توسعه‌دهنده داخلی نامیده می‌شوند، به سرعت در شرکت‌های نرم‌افزاری مورد توجه قرار می‌گیرند، زیرا آنها به دنبال بهبود تجربه توسعه‌دهنده خود و در نتیجه کارایی هستند. طبق گفته Forrester، 87٪ از رهبران DevOps موافق بودند که افزایش بهره وری توسعه دهندگان یک اولویت برای 12 ماه آینده است.

به گفته گارتنر، “این پورتال ها رهبران مهندسی نرم افزار را قادر می سازند تا یک “فروشگاه برنامه” همه کاره ایجاد کنند که استفاده مجدد از نرم افزار را افزایش می دهد، تجربه نصب برنامه نویس را بهبود می بخشد، تحویل نرم افزار را ساده می کند و به اشتراک گذاری دانش را تسهیل می کند.”

اما این پورتال های توسعه دهنده به خودی خود به وجود نیامدند. ظهور آنها ارتباط نزدیکی با روند دیگری دارد: ظهور مهندسی پلت فرم.

Shomik Ghosh، شریک Boldstart Ventures، به TechCrunch+ گفت: به طور خلاصه، تیم‌های مهندسی پلتفرم «گروه‌هایی در سازمان‌های معمولاً بزرگ‌تر هستند که نقش بهبود تجربه توسعه‌دهنده برای سایر توسعه‌دهندگان در سازمان را بر عهده دارند».

تیم های مهندسی پلت فرم به طور فزاینده ای در سازمان های بزرگ و همچنین پورتال های توسعه دهندگان داخلی رایج شده اند. گارتنر انتظار دارد که تا سال 2026، 80 درصد از سازمان های مهندسی نرم افزار یک تیم پلتفرم داشته باشند و تا سال 2025، 75 درصد از سازمان ها با تیم های پلت فرم، پورتال های توسعه دهنده سلف سرویس را در اختیار مهندسان خود قرار دهند.

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

فراتر از کاتالوگ

پورتال‌های توسعه‌دهنده داخلی ابزاری کلیدی برای تیم‌های مهندسی پلتفرم هستند، اما در واقع قبل از اینکه هر دو مفهوم به طور کامل تصور شوند، ظاهر شدند. در واقع، آنها پس از DevOps به وجود آمدند: مهندسان ناگهان متوجه شدند که به طور فزاینده‌ای وظیفه دارند تا کدهایی را که می‌نویسند، مستقر کرده و کار کنند. اما در واقعیت – و در تولید – اغلب مشخص نبود که چه کسی مالک یک میکروسرویس است.