چرا GitLab در حال حذف Compliance Pipelines و تمرکز روی سیاستهای امنیتی است؟
نوامبر 13, 2025
بدون دیدگاه
ادامه مطلب »
در این مقاله، تجربه‌ی طراحی و توسعه‌ی معماری‌های مرجع GitLab را مرور می‌کنیم تا نشان دهیم چگونه این ساختارها به سازمان‌ها کمک می‌کنند تا گیت‌لب را در مقیاس بزرگ و با کارایی بالا مستقر کنند. ما در این مسیر به بررسی اهداف اصلی، فرآیند طراحی و تغییراتی که طی پنج سال گذشته در معماری‌های مرجع GitLab ایجاد شده است، می‌پردازیم تا درک روشنی از نحوه‌ی تکامل این معماری‌ها به دست آورید.
پنج سال پیش، ما برای نخستین بار معماری‌های مرجع GitLab را معرفی کردیم. این معماری‌ها با همکاری تیم پلتفرم تست GitLab (که قبلاً مهندسی کیفیت نامیده می‌شد)، تیم‌های پشتیبانی و دیگر مشارکت‌کنندگان توسعه یافتند. هدف اصلی از طراحی این معماری‌ها، ایجاد نقاط شروعی مقیاس‌پذیر، پایدار و انعطاف‌پذیر برای استقرار GitLab در مقیاس بزرگ و متناسب با نیاز سازمان‌ها بود.
از زمان معرفی معماری‌های مرجع GitLab، ما شاهد تأثیر چشمگیر آن‌ها بر عملکرد و موفقیت مشتریان در مسیر DevSecOps بوده‌ایم. تیم ما به‌طور مداوم این معماری‌ها را گسترش، بازنگری و به‌روزرسانی می‌کند تا کاربران بتوانند از جدیدترین راهکارها برای استقرار، مقیاس‌بندی و نگهداری محیط‌های GitLab خود بهره‌مند شوند.
به مناسبت پنجمین سالگرد این پروژه، در این مقاله نگاهی دقیق‌تر به روند طراحی معماری‌های مرجع GitLab و نقش آن‌ها در بهبود تجربه‌ی استقرار امروز خواهیم داشت.
پیش از معرفی معماری‌های مرجع GitLab، بسیاری از مشتریان ما در استقرار GitLab در مقیاس بزرگ با مشکلاتی در زمینه‌ی عملکرد و در دسترس بودن روبه‌رو بودند. هر محیط GitLab با توجه به الزامات خاص هر سازمان متفاوت است، اما تجربه‌ی ما در اجرای GitLab.com و همکاری با شرکت‌های بزرگ نشان داد که اصول مشترکی برای استقرار مؤثر GitLab در مقیاس سازمانی وجود دارد.
هدف ما این بود که با شناسایی این اصول، نیازهای کاربران را برطرف کنیم و در عین حال بهترین شیوه‌های استقرار را ترویج دهیم. این کار به ما کمک کرد تا انحراف در پیاده‌سازی‌ها را کاهش دهیم و هماهنگی بیشتری میان تیم‌ها ایجاد کنیم.
برای افزایش پایداری و کارایی GitLab، تصمیم گرفتیم آزمایش‌های عملکردی را گسترش دهیم. با این کار، تیم‌های مهندسی ما قادر شدند مشکلات عملکردی را سریع‌تر شناسایی و برطرف کنند. هدف نهایی ما این بود که عملکرد GitLab در تمامی شرایط پایدار و بهینه باقی بماند.
اما اجرای این آزمایش‌ها نیاز به یک محیط استاندارد و قابل اندازه‌گیری داشت. بنابراین، ما محیطی طراحی کردیم که بتواند حجم کاری واقعی را شبیه‌سازی کند و مبنایی برای ارزیابی دقیق عملکرد فراهم سازد.
و درست در همین مرحله بود که معماری‌های مرجع GitLab متولد شدند.
در مسیر طراحی معماری‌های مرجع GitLab، متوجه شدیم که وجود یک چارچوب مشترک برای تمام سازمان‌ها ضروری است. بنابراین مجموعه‌ای از اهداف کلیدی را برای این پروژه تعیین کردیم تا بتوانیم عملکرد، پایداری و مقیاس‌پذیری بهتری ارائه دهیم.
هدف نخست ما اطمینان از این بود که معماری بتواند نیازهای عملکردی GitLab را برآورده کند. این طراحی باید قادر باشد حجم کاری مورد انتظار را بدون افت سرعت یا کیفیت مدیریت کند.
افزایش دسترسی‌پذیری سیستم یکی از اهداف اصلی ما بود. تلاش کردیم تا زمان فعالیت (Uptime) را به حداکثر برسانیم و قابلیت اطمینان سیستم را افزایش دهیم تا کاربران بتوانند در هر زمان بدون وقفه از GitLab استفاده کنند.
معماری‌های مرجع GitLab باید به‌گونه‌ای طراحی می‌شدند که بتوانند با رشد نیازهای مشتریان سازگار شوند. این یعنی ساختاری پویا که امکان افزایش یا کاهش منابع را بسته به حجم کاری فراهم کند.
یکی دیگر از اهداف ما، بهینه‌سازی مصرف منابع بود. ما می‌خواستیم اطمینان حاصل کنیم که هر منبعی به شکل کارآمد استفاده شود و هزینه‌های غیرضروری حذف شوند.
در نهایت، سادگی در مدیریت و نگهداری معماری‌های مرجع GitLab اهمیت زیادی داشت. ما با استفاده از پیکربندی‌های استاندارد، فرآیند استقرار و نگهداری را تا حد ممکن ساده کردیم.
این اهداف با اولویت برابر در نظر گرفته شدند و هنوز هم در طراحی و توسعه نسخه‌های جدید معماری‌های مرجع GitLab به آن‌ها پایبند هستیم.
پس از تعیین اهداف، زمان آن بود که فرآیند طراحی معماری‌های مرجع GitLab را آغاز کنیم. ما باید طرحی ایجاد می‌کردیم که بتواند نیازهای عملکردی، مقیاس‌پذیری و قابلیت اطمینان را پوشش دهد و سپس با آزمون و تحلیل، آن را اعتبارسنجی کنیم.
فرآیند طراحی نسبتاً ساده به نظر می‌رسید، اما اجرای آن به تلاش زیادی نیاز داشت. ما مراحل زیر را دنبال کردیم:
1. جمع‌آوری داده‌ها:
در ابتدا اطلاعات دقیقی از سیستم‌های فعلی و میزان بار کاری آن‌ها جمع‌آوری کردیم. این داده‌ها شامل معیارهایی از عملکرد و ظرفیت محیط‌های مختلف GitLab بود.
2. تحلیل و طراحی اولیه:
بر اساس داده‌های جمع‌آوری‌شده، یک طرح کلی برای ساختار سیستم طراحی شد. این طراحی باید با معیارهای عملکردی هماهنگ می‌بود و بتواند بار مورد انتظار را تحمل کند.
3. آزمایش و اعتبارسنجی:
پس از ساخت محیط، آن را چندین بار مورد آزمایش قرار دادیم. در هر مرحله، نتایج بررسی و تغییرات لازم در معماری اعمال شد تا در نهایت به یک مدل معتبر برسیم.
4. بهینه‌سازی تدریجی:
بر اساس نتایج آزمایش‌ها و معیارها، تنظیمات به‌صورت تدریجی اصلاح شدند تا عملکرد نهایی با اهداف طراحی هم‌خوانی پیدا کند.
برای تحلیل عملکرد سیستم، از واحد درخواست در ثانیه (RPS) استفاده کردیم. این معیار نشان می‌دهد که هر محیط GitLab در هر ثانیه چند درخواست را می‌تواند پردازش کند.
با مقایسه‌ی مقدار RPS با تعداد کاربران، متوجه شدیم که هر کاربر چه مقدار بار بر سیستم وارد می‌کند. این تحلیل به ما کمک کرد تا الگوهای مشترکی بین اندازه‌ی محیط‌ها و عملکرد آن‌ها در معماری‌های مرجع GitLab شناسایی کنیم.
در مرحله‌ی بعد، طراحی اولیه بر اساس داده‌های واقعی اجرا شد. ما هم‌زمان با جمع‌آوری داده‌ها، کار طراحی اولیه را آغاز کردیم. ایده‌ی اصلی این بود که ساختار GitLab.com را متناسب با نیازهای هر مشتری کوچک‌تر کنیم، بدون آنکه از عملکرد یا صرفه‌ی اقتصادی کاسته شود.
سپس با انجام آزمون‌های متعدد عملکردی، نتایج را بررسی و اصلاح کردیم. این کار چندین بار تکرار شد تا بتوانیم تفاوت میان مشکلات واقعی و محدودیت‌های محیطی را تشخیص دهیم.
در طی این مسیر، نیاز به ابزارهای اختصاصی برای تست عملکرد و ساخت محیط احساس شد. به همین دلیل دو ابزار قدرتمند ایجاد کردیم:
GitLab Performance Tool: برای انجام تست‌های عملکردی و تحلیل بازده سیستم.
GitLab Environment Toolkit: برای ایجاد و مدیریت سریع محیط‌های آزمایشی.
این ابزارها همچنان مورد استفاده هستند و کاربران نیز می‌توانند از آن‌ها برای بهینه‌سازی محیط‌های خود بهره ببرند.
پس از چندین مرحله طراحی، آزمایش و بازنگری، اولین نسخه‌ی پایدار از معماری مرجع GitLab ایجاد شد. این معماری اکنون به عنوان مدل استاندارد برای سیستم‌هایی با توان پردازش ۲۰۰ درخواست در ثانیه (RPS) یا حدود ۱۰٬۰۰۰ کاربر فعال شناخته می‌شود.
معماری‌های مرجع GitLab امروز به عنوان یکی از بخش‌های کلیدی راهنمای استقرار در مقیاس بزرگ شناخته می‌شوند. ما نخستین نسخه از این معماری‌ها را چند سال پیش منتشر کردیم و از آن زمان، به‌طور مداوم آن‌ها را بهبود داده‌ایم. این معماری‌ها را «مستندات زنده» می‌نامیم، زیرا همواره در حال تغییر، توسعه و انطباق با فناوری‌های جدید هستند.
معماری‌های مرجع در اندازه‌ها و مقیاس‌های مختلف طراحی شده‌اند تا بتوان آن‌ها را برای انواع استقرارهای GitLab (deployment) به کار گرفت. این انعطاف‌پذیری به سازمان‌ها اجازه می‌دهد تا بر اساس نیاز و حجم کاری، مناسب‌ترین پیکربندی را انتخاب کنند.
برای محیط‌های کوچک‌تر یا کم‌اهمیت‌تر، نسخه‌های ساده‌تر با قابلیت دسترسی پایین‌تر توصیه می‌شوند. در این نوع استقرارها، در صورت بروز مشکل، سیستم ممکن است برای مدتی در دسترس نباشد، اما هزینه نگهداری و منابع مصرفی کاهش می‌یابد.
تمام مستندات گام‌به‌گام مربوط به معماری‌های مرجع GitLab با همکاری نزدیک بین تیم‌های مهندسی، نگارش فنی و پشتیبانی تهیه شده‌اند. این مستندات شامل دستورالعمل‌هایی برای:
انتخاب اندازه و مقیاس مناسب برای پیکربندی GitLab
مقیاس‌بندی مؤثر محیط‌ها بر اساس رشد پروژه
مدیریت پروژه‌های بزرگ و پیچیده مانند مونورپوها
این رویکرد باعث می‌شود که کاربران بتوانند با اطمینان، محیط‌های خود را بهینه‌سازی کرده و عملکرد پایدارتری تجربه کنند.
یکی از نقاط تمرکز ما، توسعه‌ی معماری‌های مرجع GitLab برای محیط‌های cloud native و ترکیبی است. در این معماری‌ها، بخشی از مؤلفه‌ها در محیط‌های کانتینری مانند Kubernetes اجرا می‌شوند، در حالی‌که سایر مؤلفه‌ها ممکن است در زیرساخت‌های سنتی یا سایر پلتفرم‌های ابری مستقر شوند.
این رویکرد ترکیبی به سازمان‌ها کمک می‌کند تا از مزایای هر دو نوع محیط بهره‌مند شوند — از جمله مقیاس‌پذیری بالا، قابلیت استقرار سریع و هزینه‌های زیرساختی بهینه‌تر.
در مستندات معماری‌های مرجع GitLab همچنین مجموعه‌ای از توصیه‌ها و دستورالعمل‌ها برای انتخاب و استفاده‌ی بهینه از خدمات ارائه‌دهندگان ابری (Cloud Providers) آورده شده است. این بخش به شما کمک می‌کند تا مناسب‌ترین سرویس را بر اساس اهداف عملکرد، هزینه و امنیت انتخاب کنید.
برای اطلاع از آخرین تغییرات و نسخه‌های جدید، پیشنهاد می‌کنیم بخش تاریخچه به‌روزرسانی‌ها (Changelog) در مستندات معماری‌های مرجع GitLab را بررسی کنید. این بخش اطلاعات دقیقی درباره‌ی تغییرات فنی، بهبودها و پیشنهادهای جدید ارائه می‌دهد.
برای اطمینان از عملکرد پایدار و به‌روزرسانی مداوم، ما یک برنامه آزمایشی جامع طراحی کرده‌ایم که هر هفته بررسی می‌کند آیا معماری‌های مرجع GitLab همچنان با آخرین تغییرات این پلتفرم سازگار هستند یا خیر.
این روند آزمایشی به ما امکان می‌دهد تا به سرعت هرگونه تغییر یا ناسازگاری را شناسایی کنیم و بلافاصله راه‌حل‌های لازم را ارائه دهیم.
نتایج این برنامه بسیار موفقیت‌آمیز بوده است. تلاش‌های ما به بسیاری از مشتریان و تیم‌های داخلی GitLab کمک کرده تا خدمات جدید و کارآمدی ارائه دهند.
به عنوان نمونه، ما در توسعه سرویس GitLab Dedicated از همین معماری‌های مرجع استفاده کردیم. این موضوع نشان می‌دهد که کاربرد این معماری‌ها تنها به محیط‌های عمومی محدود نیست، بلکه در پروژه‌های زیرساختی داخلی نیز نقشی اساسی دارند.
حتی پس از گذشت پنج سال از آغاز این مسیر، ما همچنان بر بهبود و گسترش معماری‌های مرجع GitLab تمرکز داریم تا جدیدترین و دقیق‌ترین راهنمایی‌ها را برای کاربران فراهم کنیم.
در صورتی که این مقاله (چگونه ما معماری‌های مرجع GitLab را طراحی کردیم ) برای شما مفید و آموزنده بود، پیشنهاد می‌شود برای اطلاع از سایر مقالات مستر لایسنس به صفحه وبلاگ مستر لایسنس مراجعه نمایید.
تیم مستر لایسنس با بهره گیری از متخصصان مجرب امنیتی قادر به ارائه خدمات و راهکار در زمینه مهندسی معکوس و ایجاد لایسنس نرم افزارهای خارجی با تمامی امکانات کامل می باشد .
تمامی حقوق قانونی این سایت مربوط به MRlicense میباشد
