DevOps

راه اندازی CI/CD با GitLab CE، Runner و Jenkins

راه اندازی CI/CD یعنی هر بار که کد را push می کنید، ساخت، تست و deploy به شکل خودکار و تکرارپذیر انجام شود. تیم فنی پیکوهاست GitLab CE با Runner یا Jenkins را روی سرور شما نصب می کند و pipeline پروژه تان را می نویسد.

در یک نگاه

راه اندازی CI/CD یعنی نصب ابزاری مثل GitLab CE با Runner یا Jenkins و نوشتن pipeline که کد را build، تست و روی سرور deploy می کند. وقتی deploy دستی کند یا پرخطاست به آن نیاز دارید. تیم فنی پیکوهاست ابزار، pipeline و دسترسی امن secrets را روی سرور شما آماده می کند.

سطح های خدمت

دامنه کار را با توجه به وضعیت سرور شما انتخاب می کنیم؛ قیمت هر سطح بعد از بررسی گفته می شود.

چه کارهایی انجام می شود

GitLab CE

نصب روی سرور، تنظیم دامنه و SSL، ایمیل اطلاع رسانی و کاربران اولیه

GitLab Runner

نصب و ثبت Runner با executor مناسب (shell یا Docker)

Jenkins

نصب، تنظیم کاربران و نصب افزونه های لازم برای پروژه

pipeline

تعریف مرحله های build، test و deploy در .gitlab-ci.yml یا Jenkinsfile

deploy

انتشار روی سرور مقصد از طریق SSH یا ساخت و اجرای ایمیج

secrets

نگهداری کلیدها و توکن ها در متغیرهای محافظت شده، نه داخل کد

سرور مقصد

ساخت کاربر مخصوص deploy با دسترسی محدود و کلید SSH جدا

چه زمانی به این خدمت نیاز دارید

  • انتشار نسخه تازه به یک نفر و چند دستور دستی وابسته است و گاهی اشتباه می شود.
  • تست ها را فقط گاهی و روی سیستم یک توسعه دهنده اجرا می کنید.
  • چند نفر روی یک مخزن کار می کنند و می خواهید قبل از ادغام، کد خودکار بررسی شود.
  • بعد از هر انتشار برای برگرداندن نسخه قبلی راه مشخصی ندارید.
  • پروژه تان با Docker اجرا می شود و ساخت ایمیج هر بار دستی انجام می شود. برای این حالت نصب و راه اندازی داکر پیش نیاز مناسبی است.

مراحل کار

  1. ۱

    در تیکت نوع پروژه، زبان یا فریم ورک، محل مخزن کد و سرور مقصد را می نویسید.

  2. ۲

    تیم فنی ابزار را روی سرور انتخابی نصب و پایه امنیتی آن را تنظیم می کند.

  3. ۳

    Runner یا agent به مخزن وصل و یک pipeline ساده با مرحله های build و test اجرا می شود.

  4. ۴

    مرحله deploy اضافه می شود: ساخت کاربر deploy، کلید SSH و اسکریپت انتشار.

  5. ۵

    secrets در متغیرهای محافظت شده ثبت و اجرای کامل pipeline روی یک شاخه آزمایشی بررسی می شود.

  6. ۶

    فایل های pipeline و توضیح کوتاه نگهداری به شما تحویل داده می شود.

چه چیزی از شما لازم داریم

  • دسترسی به مخزن کد یا اعلام محل آن، و اگر مخزن خصوصی است، یک توکن با دسترسی فقط خواندن.
  • دسترسی مدیریتی به سرور که از طریق فیلدهای خصوصی تیکت یا یک حساب موقت داده می شود. رمز root را در متن عادی تیکت ننویسید. حساب موقت بعد از اتمام کار حذف می شود.
  • دستور ساخت و تست پروژه، یا توضیح این که هر انتشار فعلی چه مراحلی دارد.
  • مشخصات سرور مقصد و محیط های لازم، مثل staging و production.
  • اگر پروژه تست خودکار ندارد، اعلام این موضوع. در این حالت pipeline فقط build و deploy را انجام می دهد.

چه چیزی تحویل می دهید و چه چیزی تضمین نمی شود؟

تحویل کار شامل ابزار نصب شده و کار می کند، pipeline نوشته شده برای پروژه شما، کاربر و کلید deploy با دسترسی محدود و یادداشتی از نحوه افزودن پروژه یا متغیر تازه است.

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

سوالات پرتکرار

GitLab بهتر است یا Jenkins؟
هیچ کدام در همه حالت بهتر نیست. GitLab CE مخزن، pipeline و مدیریت کاربر را یک جا دارد و برای تیم های کوچک ساده تر است. Jenkins برای پروژه هایی که ابزار و محیط های متنوع دارند انعطاف بیشتری می دهد ولی نگهداری افزونه هایش وقت می برد.
deploy از طریق SSH امن است؟
اگر درست تنظیم شود، بله. برای هر pipeline یک کاربر جدا با کلید مخصوص و دسترسی محدود ساخته می شود و رمز عبور یا کلید داخل مخزن ذخیره نمی شود. کلیدها در متغیرهای محافظت شده می مانند.
GitLab CE چقدر منبع لازم دارد؟
بسته به تعداد کاربران و پروژه ها فرق می کند و مقدار دقیقی که برای همه درست باشد وجود ندارد. در بررسی اولیه منابع سرور شما را می سنجیم و اگر کم باشد، قبل از نصب اعلام می کنیم. مستندات رسمی را در docs.gitlab.com می توانید ببینید.
می توانم pipeline را بعدا خودم تغییر بدهم؟
بله. فایل pipeline داخل مخزن پروژه است و با همان روند عادی commit تغییر می کند. برای دیدن نتیجه تغییر و خطاها می توانید به مانیتورینگ سرور هم اتصال بدهید.