GitLab — مبانی، قابلیت‌ها و CI/CD

GitLab چیست؟

GitLab — یک پلتفرم کامل DevOps با کد منبع باز تحت مجوز MIT است. برخلاف GitHub که خدمات مختلف را از طریق یکپارچه‌سازی‌ها ترکیب می‌کند، GitLab یک ابزار واحد برای کل چرخه عمر توسعه ارائه می‌دهد: از مدیریت کد و بازبینی کد تا CI/CD، نظارت، امنیت و استقرار. این پلتفرم برای اکثر وظایف DevOps به خدمات شخص ثالث نیاز ندارد.

تاریخچه GitLab در سال ۲۰۱۱ به عنوان یک پروژه داخلی توسط توسعه‌دهندگان اوکراینی آغاز شد. اولین نسخه عمومی در سپتامبر ۲۰۱۱ منتشر شد و در سال ۲۰۱۵ GitLab به اولین پروژه در GitLab.com تبدیل شد و میزبانی ابری را راه‌اندازی کرد. در سال ۲۰۱۷، GitLab یک فرآیند مهاجرت دردناک اما آموزنده را انجام داد — انتقال کل زیرساخت از Azure به Google Cloud که به صورت زنده پخش و در یک سری پست‌ها مستند شد.

معماری GitLab از سه مؤلفه اصلی تشکیل شده است: GitLab Rails (برنامه وب در Ruby on Rails)، GitLab Shell (پردازش عملیات Git از طریق SSH) و Gitaly (سرور gRPC برای دسترسی به داده‌های Git). CI/CD از طریق GitLab Runner — یک برنامه جداگانه که روی سرورهای ساخت نصب می‌شود و job‌ها را در محیط‌های ایزوله (Docker، Kubernetes، VirtualBox) اجرا می‌کند — تأمین می‌شود.

GitLab CI/CD: pipeline‌ها و runner‌ها

GitLab CI/CD — یک سیستم یکپارچه تحویل و یکپارچه‌سازی مداوم داخلی است که مزیت کلیدی پلتفرم محسوب می‌شود. برخلاف GitHub Actions، GitLab CI/CD از ابتدا در معماری گنجانده شده است و به پیکربندی جداگانه نیاز ندارد: هر پروژه پس از افزودن فایل .gitlab-ci.yml به ریشه مخزن، به طور خودکار CI/CD دریافت می‌کند.

Pipeline (pipeline) از مرحله‌هایی (stages) تشکیل شده است که به صورت ترتیبی یا موازی اجرا می‌شوند: build → test → deploy. هر مرحله شامل یک یا چند job است که روی runner‌ها اجرا می‌شوند. اگر یک job در مرحله با خطا پایان یابد، کل مرحله به عنوان failed علامت‌گذاری می‌شود و مراحل بعدی به طور پیش‌فرض اجرا نمی‌شوند. در زیر نمونه pipeline برای یک پروژه موبایل آورده شده است:

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build-android:
  stage: build
  image: openjdk:17-jdk
  script:
    - ./gradlew assembleDebug
  artifacts:
    paths:
      - app/build/outputs/

unit-tests:
  stage: test
  script:
    - ./gradlew testDebugUnitTest

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute app.apk

GitLab Runner از چندین executor (اجراکننده) پشتیبانی می‌کند: Docker (توصیه شده)، Kubernetes، SSH، VirtualBox و Parallels. محبوب‌ترین گزینه اجراکننده Docker است که هر job را در یک کانتینر جداگانه اجرا می‌کند. Runner می‌تواند به عنوان مختص یک پروژه یا به صورت مشترک (shared) برای کل گروه ثبت شود. GitLab.com runner‌های مشترک رایگان با محدودیت ۲۰۰۰ دقیقه در ماه ارائه می‌دهد.

قابلیت‌های پیشرفته CI/CD

GitLab CI/CD از اجرای دستی (when: manual)، اجرای تأخیری (when: delayed)، اجرای موازی (parallel: 5)، ماتریس (matrix)، pipeline‌های پویا (child pipelines) و pipeline‌های چندسطحی (parent-child) پشتیبانی می‌کند. این امکان ساخت سناریوهای پیچیده را فراهم می‌کند: مثلاً تولید پویای pipeline برای هر ماژول در مخزن یکتا یا اجرای ساخت‌های موازی برای معماری‌های مختلف Android (arm64, x86_64).

GitLab در مقابل GitHub: تفاوت‌های کلیدی

GitLab و GitHub — دو رقیب اصلی در بازار پلتفرم‌های Git هستند، اما فلسفه و معماری آنها اساساً متفاوت است. GitHub بر جامعه باز، اکوسیستم یکپارچه‌سازی‌ها و ویژگی‌های اجتماعی (fork، ستاره) تمرکز دارد. GitLab بر چرخه جامع DevOps متمرکز است و همه ابزارها را به صورت پیش‌فرض ارائه می‌دهد: از برنامه‌ریزی تا نظارت.

تفاوت معماری اصلی: GitLab — یک برنامه یکپارچه است که توسعه‌دهنده آن را به طور کامل نصب می‌کند. همه ویژگی‌ها (CI/CD، Container Registry، Security Scanning، Pages) داخلی هستند و بلافاصله پس از نصب کار می‌کنند. GitHub — پلتفرمی با API است که بیشتر ویژگی‌ها از طریق یکپارچه‌سازی با خدمات شخص ثالث پیاده‌سازی می‌شوند: Travis CI، CircleCI، Jenkins، SonarQube. جدول زیر ویژگی‌های کلیدی را مقایسه می‌کند:

انتخاب بین GitLab و GitHub به نیازهای تیم بستگی دارد. اگر اولویت استقرار سریع با پیکربندی صفر و جامعه باز است — GitHub را انتخاب کنید. اگر کنترل کامل زیرساخت، میزبانی خود و امنیت داخلی مورد نیاز است — GitLab ترجیح داده می‌شود. طبق نظرسنجی Stack Overflow (۲۰۲۴)، ۹۰٪ توسعه‌دهندگان از GitHub و ۳۳٪ از GitLab (اغلب هر دو پلتفرم همزمان) استفاده می‌کنند.

Self-Managed GitLab: نصب روی سرور خود

Self-Managed GitLab (قبلاً On-Premises) امکان نصب پلتفرم روی سرور خود و کنترل کامل داده‌ها، زیرساخت و در دسترس بودن را فراهم می‌کند. این امر به ویژه برای سازمان‌های با الزامات انطباق اهمیت دارد: بخش مالی، مؤسسات دولتی، سازمان‌های پزشکی که داده‌ها نمی‌توانند روی سرورهای شخص ثالث ذخیره شوند.

نصب GitLab در Ubuntu، Debian، CentOS و از طریق Docker پشتیبانی می‌شود. بسته رسمی Omnibus شامل همه مؤلفه‌ها است: وب‌سرور (NGINX)، پایگاه داده (PostgreSQL)، حافظه نهان (Redis)، پردازنده Git (Gitaly) و فرآیندهای پس‌زمینه. حداقل نیازها: ۴ گیگابایت RAM و ۲ CPU برای تیم تا ۱۰۰ نفر. برای نصب‌های بزرگ با بار بالا، جداسازی مؤلفه‌ها روی سرورهای جداگانه توصیه می‌شود.

# نصب GitLab CE روی Ubuntu از طریق Omnibus
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

# نصب بسته
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

# بررسی وضعیت
sudo gitlab-ctl status
sudo gitlab-ctl tail

Self-Managed GitLab محدودیت دقیقه CI/CD ندارد — همه runner‌ها متعلق به سازمان هستند و قدرت آنها فقط توسط سخت‌افزار خود محدود می‌شود. همچنین Geo-replication برای مناطق، لاگ‌های حسابرسی، مسدودسازی IP و یکپارچه‌سازی با ارائه‌دهندگان LDAP/SAML شرکتی در دسترس است. GitLab هر ماه (در ۲۲ام) به‌روزرسانی‌هایی با ویژگی‌های جدید و رفع مشکلات امنیتی منتشر می‌کند.

ابزارهای امنیتی داخلی GitLab

امنیت در GitLab در سطح پلتفرم تعبیه شده است و شامل چندین اسکنر است که در هر مرحله از pipeline کار می‌کنند. SAST (Static Application Security Testing) کد منبع را برای آسیب‌پذیری‌ها بدون اجرای برنامه تحلیل می‌کند و بیش از ۱۵ زبان از جمله Java، Kotlin، Swift، Python و JavaScript را پشتیبانی می‌کند. DAST (Dynamic Application Security Testing) برنامه وب در حال اجرا را برای آسیب‌پذیری‌ها از داخل تست می‌کند.

ابزارهای اضافی: Container Scanning تصاویر Docker را برای آسیب‌پذیری‌ها در لایه‌های پایه بررسی می‌کند؛ Dependency Scanning وابستگی‌های پروژه را تحلیل و درباره CVE‌های شناخته شده هشدار می‌دهد؛ Secret Detection کلیدهای API، رمزهای عبور و توکن‌هایی که به طور تصادفی commit شده‌اند را پیدا می‌کند؛ Fuzz Testing تست خودکار با داده‌های نادرست برای یافتن باگ‌های غیر آشکار انجام می‌دهد. همه نتایج اسکن در یک Security Dashboard نمایش داده می‌شوند.

GitLab همچنین Compliance — ابزارهایی برای رعایت الزامات نظارتی ارائه می‌دهد. Compliance Dashboard وضعیت انطباق همه پروژه‌ها را نشان می‌دهد، Audit Events هر اقدام مدیر و توسعه‌دهنده را ثبت می‌کند، و Compliance Frameworks امکان اعمال اجباری سیاست‌های پیکربندی برای گروه‌های پروژه خاص را فراهم می‌کند. این امر GitLab را به یک انتخاب محبوب در محیط‌های شرکتی با الزامات امنیتی سخت تبدیل می‌کند.

Container Registry و Dependency Proxy

GitLab Container Registry — یک ثبت Docker داخلی یکپارچه با CI/CD است. پس از ساخت تصویر Docker در pipeline، می‌توان آن را بلافاصله در Registry با استفاده از متغیرهای محیطی CI_REGISTRY و CI_REGISTRY_USER منتشر کرد. Registry از کش pull-through، برچسب‌گذاری، سیاست‌های پاکسازی و اسکن آسیب‌پذیری مستقیماً در ثبت پشتیبانی می‌کند.

Dependency Proxy — مکانیزمی برای کش کردن کانتینرها و تصاویر از ثبت‌های خارجی (Docker Hub، Quay، GCR). وقتی pipeline تصویر ubuntu:latest را درخواست می‌کند، GitLab ابتدا کش خود را بررسی می‌کند — اگر تصویر قبلاً بارگذاری شده باشد، دوباره دانلود نمی‌شود. این کار بار روی ثبت‌های خارجی را کاهش می‌دهد، pipeline‌ها را سرعت می‌بخشد و در برابر محدودیت‌های نرخ Docker Hub محافظت می‌کند.

برای توسعه‌دهندگان موبایل، GitLab GitLab Pages را برای میزبانی مستندات و گزارش‌های تست فراهم می‌کند. پس از اجرای تست‌ها، مصنوعات (گزارش‌های HTML، اسکرین‌شات‌ها، لاگ‌ها) را می‌توان به عنوان Pages منتشر کرد و لینکی برای ارسال به تیم QA دریافت کرد. این کار راحت‌تر از بارگذاری گزارش‌ها در فضای ابری است، زیرا همه چیز در همان پروژه GitLab قرار می‌گیرد.

API و Webhook‌های GitLab

GitLab API (REST و GraphQL) دسترسی به تمام منابع پلتفرم را فراهم می‌کند: پروژه‌ها، کاربران، pipeline‌ها، Merge Request، ثبت. API برای خودکارسازی استفاده می‌شود: ایجاد پروژه از الگو، تعیین بازبین، دریافت وضعیت pipeline. Webhook‌ها امکان ارسال اعلان‌های HTTP به سیستم‌های خارجی در رویدادها را فراهم می‌کنند: push، merge، ایجاد Issue. Webhook‌ها با Mattermost، Slack، Telegram و سیستم‌های نظارت داخلی یکپارچه می‌شوند.

GitLab Pages برای مستندات موبایل

GitLab Pages به طور خودکار وبسایت‌های ایستا را از مخزن منتشر می‌کند. برای پروژه‌های موبایل، Pages برای قرار دادن مستندات API، گزارش‌های پوشش تست و نتایج تحلیل lint مناسب است. انتشار پس از pipeline موفق به طور خودکار انجام می‌شود — کافی است مرحله deploy با انتشار در Pages را در .gitlab-ci.yml مشخص کنید. نتیجه در آدرس https://namespace.gitlab.io/name-project قابل دسترسی است.