چگونه GitHub از GitHub Actions برای ساخت و آزمایش GitHub.com استفاده می کند؟

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

اخیراً، ما تلاش کرده‌ایم تا با استفاده از ویژگی جدید GitHub منتشر شده، Actions large runners، تجربه CI خود را بهتر کنیم تا CI خود را اجرا کنیم.

تیم Developer Experience (DX) در GitHub با تعدادی از تیم‌های دیگر برای انتقال سیستم یکپارچه‌سازی پیوسته (CI) گیت هاب به GitHub Actions همکاری کرد تا از توسعه و مقیاس‌بندی خواسته‌های تیم مهندسی گیت هاب پشتیبانی کند. هدف گیت هاب به عنوان یک تیم این است که مهندسان خود را قادر به ارسال با اطمینان و سریع نرم افزار کند. برای این منظور، آن ها روی ارائه مسیرهای هموار، مجموعه‌ای از ابزارها و برنامه‌های خودکار برای ساده‌سازی توسعه، پلتفرم‌های زمان اجرا و استقرار خود کار کرده اند.

اخیراً، گیت هاب تلاش کرده است تا با استفاده از ویژگی جدید GitHub منتشر شده، Actions large runners، تجربه CI خود را بهتر کند تا CI خود را اجرا کند.

در ادامه می خوانید تا ببینید چگونه 15000 work CI را در یک ساعت در 150000 هسته محاسبات اجرا می شود!

GitHub Actions چیست؟

GitHub Actions یک سرویس اتوماتیک ارائه شده توسط GitHub است که توسعه‌دهندگان می‌توانند از آن برای تعریف و اجرای جریان‌های کاری مختلف بر روی پروژه‌های خود استفاده کنند. این جریان‌های کاری می‌توانند از ایجاد و تست کد تا تولید نسخه‌های برنامه و تحویل به محیط‌های مختلف شامل تولید‌محیط تست، محیط‌های توسعه و حتی محیط‌های تولید باشند.

تاریخچه مختصر CI در GitHub

گیت هاب در طول تاریخ خود بر روی انواع مختلف سیستم های CI سرمایه گذاری کرده است. با هر سیستم، هدف آن ها ارتقای تجربه توسعه برای مهندسین GitHub در نوشتن و استقرار کد و برای مهندسانی که سیستم‌ها را نگهداری می‌کنند، بوده است.

با این حال، با سیستم‌های CI گذشته، گیت هاب در مقیاس‌بندی سیستم برای برآوردن نیازهای تیم مهندسی خود برای ارائه محیط‌های ساخت پایدار و زودگذر با چالش‌هایی مواجه بودند. هیچ یک از این چالش‌ها به آن ها اجازه نمی‌داد تا تجربه بهینه توسعه‌دهنده را ارائه کنند.

سپس، گیت هاب GitHub Actions larger runners را منتشر کرد. این به آن ها فرصتی داد تا نه تنها به یک سیستم کاملاً مشخصه CI بروند، بلکه سیستم‌هایی را که برای مشتریان خود ایجاد می کردند نیز، توسعه دهند و از آنها استفاده کردند. برای تیم GitHub DX، این انتقال فرصتی عالی بود تا از حفظ سیستم‌های CI گذشته خود دور شوند و در عین حال یک تجربه توسعه‌دهنده برتر را ارائه کنند.

رانر های بزرگتر(larger runners) چیست؟

رانر های بزرگتر، رانر های GitHub Actions هستند که توسط GitHub میزبانی می شوند. آنها ماشین های مجازی مدیریت شده (VMs) با RAM، CPU و فضای دیسک بیشتر نسبت به رانرهای استاندارد میزبانی GitHub هستند. انواع مختلفی از اندازه‌های مختلف ماشین برای رانرها و همچنین برخی ویژگی‌های اضافی در مقایسه با رانرهای استاندارد میزبانی GitHub وجود دارد.این امکان را به توسعه‌دهندگان می‌دهند تا برنامه‌های پیچیده‌تر را بسازند و از ویژگی‌های پیشرفته GitHub Actions مانند ماتریکس‌ها و محیط‌های تست متعدد بهره‌برند.

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

رانر های بزرگتر برای تیم GitHub و مشتریان GitHub Enterprise Cloud در دسترس هستند. برای کسب اطلاعات بیشتر در مورد runner های بزرگتر، این داکیومنت را بررسی کنید.

چرا گیت هاب رانر های بزرگتر را انتخاب کردند؟

مقیاس خودکار و مدیریت شده
با توجه به تکرارهای قبلی سیستم‌های CI GitHub، آن ها به توانایی ایجاد ماشین‌های CI در صورت تقاضا نیاز داشتند تا چرخه‌های بازخورد سریع مورد نیاز مهندسان GitHub را برآورده کنند و با نرخ تغییر سایت مقیاس صورت گیرد.

با رانر های بزرگتر، آن ها توانایی مقیاس خودکار سیستم CI خود را حفظ کردند، زیرا GitHub به طور خودکار چندین نمونه از یک رانر را ایجاد می کند که برای مطابقت با خواسته های شغلی مهندسان ، افزایش و کاهش می یابد. یک مزیت اضافه شده این است که تیم GitHub DX دیگر لازم نیست نگران مقیاس بندی رانر ها باشد زیرا تمام این پیچیدگی ها توسط خود GitHub مدیریت می شود!

تعدادی اعداد خام در مورد حداکثر استفاده فعلی گیت هاب از رانر های بزرگتر به این صورت می باشد:

از 4500 رانر 32 هسته ای همزمان استفاده می کند
125000 دقیقه ساخت در ساعت اجرا می شود
در عرض یک ساعت تقریباً 15000 work را در صف می گذارد و اجرا می کند
حدود 150000 هسته محاسباتی را اختصاص می دهد

پشتیبانی از تصویر VM سفارشی (بتا)

GitHub Actions ابزارهای زیادی را در اختیار رانر ها قرار می‌دهد که قبلاً در آن ساخته شده‌اند، که برای پروژه‌های مختلف در سراسر گیت هاب کافی و راحت است. با این حال، برای برخی از خدمات GitHub تولیدی پیچیده، رانرهای از پیش ساخته شده همه نیازهای آن ها را برآورده نمی‌کنند.

برای حفظ یک سیستم CI کارآمد و سریع، تیم DX به توانایی ارائه ماشین‌ها با تمام ابزارهای مورد نیاز برای ساخت این خدمات تولیدی نیاز داشت. سپس آن ها زمان بیشتری را صرف نصب ابزارها یا کامپایل پروژه‌ها در طول کارهای CI انجام دادند.

و در حال حاضر در حال ساختن ویژگی‌ها در رانرهای بزرگتر هستند، بنابراین آنها می‌توانند از یک تصویر VM سفارشی به نام تصاویر سفارشی راه‌اندازی شوند. در حالی که این ویژگی هنوز در مرحله بتا است، استفاده از تصاویر سفارشی به چند دلیل یک مزیت بزرگ برای چرخه حیات CI GitHub است.

اول، تصاویر سفارشی به GitHub اجازه می‌دهد تا تمامی نرم‌افزارها و ابزارهای مورد نیاز برای ساخت و آزمایش سرویس‌های بلبرینگ تولید پیچیده را باندل کند. هر چیزی که مختص GitHub یا یکی از پروژه‌های آن ها باشد، می‌تواند قبل از شروع یک work flow GitHub Actions از قبل روی تصویر نصب شود.

دوم، تصاویر سفارشی GitHub را قادر می‌سازد تا با عمل به عنوان یک حافظه پنهان بوت استرپ برای برخی پروژه‌ها، سرعت work flow های GitHub Actions را به طرز چشمگیری افزایش دهد. در طول ایجاد تصویر سفارشی، آن ها یک نسخه از پیش ساخته شده از کد منبع پروژه را در تصویر قرار دادند. متعاقباً، هنگامی که پروژه یک work flow GitHub Actions را شروع می‌کند، می‌تواند از نسخه ذخیره‌شده کد منبع خود و هر مصنوع ساخت دیگری برای سرعت بخشیدن به فرآیند ساخت خود استفاده کند.

کد منبع پروژه ذخیره شده روی تصویر VM سفارشی می تواند به سرعت به دلیل سرعت توسعه سریع در GitHub منسوخ شود. این به نوبه خود باعث افزایش مدت زمان work flow می شود. تیم DX با تیم مهندسی GitHub Actions برای ایجاد یک API در GitHub کار کرد تا به‌طور منظم تصویر سفارشی را چندین بار در روز به‌روزرسانی کند تا منبع پروژه به‌روز بماند.

در عمل، این زمان بوت استرپ پروژه ها را به میزان قابل توجهی کاهش داده است. بدون تصاویر سفارشی، work flow از ابتدا تا انتها حدود 50 دقیقه طول می کشد، در حالی که امروز 12 دقیقه طول می کشد. این یک تغییر بازی برای مهندسان گیت هاب است.

ویژگی های مهم GitHub Actions

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

Work flow قابل استفاده مجدد
یکی از اهداف تیم DX این است که مسیرهایی را برای همه مخازن برای اجرای CI بدون ایجاد تکرار غیر ضروری در مخازن هموار کند. قبل از GitHub Actions، تنظیمات single job ایجاد کرده بودند که می‌توانست در چندین پروژه استفاده شوند. در GitHub Actions، این کار به این آسانی نبود، زیرا هر مخزن می تواند work flow خود را تعریف کند. work flow قابل استفاده مجدد برای نجات!

ویژگی work flow قابل استفاده مجدد در GitHub Actions راهی برای مدیریت مرکزی یک work flow در یک مخزن ارائه می دهد که می تواند توسط بسیاری از مخازن دیگر در یک سازمان استفاده شود. این در انتقال آن ها از سیستم CI قبلی به GitHub Actions بسیار مهم بود.سپس آن ها توانستند چندین work flow از پیش ساخته شده را در یک مخزن ایجاد کننند و بسیاری از مخازن می توانند از آن work flow استفاده کنند. این باعث می شود که فرآیند افزودن CI به یک پروژه موجود یا جدید بسیار زیاد باشد.

در مخزن مرکزی که میزبان work flow های قابل استفاده مجدد است، work flow به شرح زیر تعریف می شود:

on:
  workflow_call:
    inputs:
      cibuild-script:
        description: 'Which cibuild script to run.'
        type: string
        required: false
        default: "script/cibuild"
    secrets:
      service-api-key:
        required: true

jobs:
  reusable_workflow_job:
    runs-on: gh-larger-runner-medium
    name: Simple Workflow Job
    timeout-minutes: 20
    steps:
      - name: Checkout Project
        uses: actions/checkout@v3
      - name: Run cibuild script
        run: |
          bash ${{ inputs.cibuild-script }}
        shell: bash

و در مصرف مخازن، آنها به سادگی می توانند از work flow قابل استفاده مجدد، تنها با چند خط کد استفاده کنند!

name: my-new-project
on:
  workflow_dispatch:
  push:

jobs:
  call-reusable-workflow:
    uses: github/internal-actions/.github/workflows/default.yml@main
    with:
      cibuild-script: "script/cibuild-my-tests"
    secrets:
      service-api-key: ${{ secrets.SERVICE_API_KEY }}

یکی دیگر از مزایای بزرگ ویژگی work flow قابل استفاده مجدد این است که runner را می توان در work flow قابل استفاده مجدد تعریف کرد، به این معنی که ما می توانیم تضمین کنیم که همه کاربران work flow در استخر بزرگتر تعیین شده اجرا می شوند. اکنون، پروژه‌ها نیازی به نگرانی در مورد اینکه کدام رانر باید استفاده کنند، ندارند!

استفاده مجدد از نتایج گردش کار قبلی (بتا) 

برای بهینه‌سازی تجربه توسعه‌دهنده‌، تیم DX با تیم مهندسی گیت هاب برای ایجاد قابلیتی برای GitHub Actions کار کرد که به work flow اجازه می‌دهد تا از نتیجه یک work flow قبلی استفاده کنند، جایی که نتایج یکسان هستند.

در برخی موارد، محتویات فایل یک مخزن بین اجراهای work flow که روی commit های مختلف اجرا می شوند دقیقاً یکسان است. یعنی شناسه درخت Git برای commit فعلی مانند commit قبلی است (تفاوت فایلی وجود ندارد). در این موارد، با استفاده مجدد از نتایج work flow قبلی، بررسی‌های CI را دور زدند و به مهندسان اجازه نداند تا برای اجرای مجدد CI منتظر بمانند.

این ویژگی مهندسان GitHub را از اجرای 300 تا 500 work flow در روز نجات می دهد!

سایر چالش های پیش رو

دسترسی به خدمات خصوصی
در طول برخی از جریان‌های کاری GitHub Actions داخلی، work flow به توانایی دسترسی به برخی از سرویس‌های خصوصی GitHub در یک ابر خصوصی مجازی GitHub (VPC) از طریق شبکه نیاز دارند. اینها می توانند منابعی مانند ذخیره سازی مصنوعات، خدمات فراداده برنامه و سایر خدماتی باشند که فراخوانی مهار تست ما را امکان پذیر می کنند.

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

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

این راه حل دسترسی از راه دور بر اساس اصل برش توکن OIDC در GitHub Actions کار می کند، رمز OIDC را به دروازه دسترسی از راه دور منتقل می کند که درخواست را با اعتبارسنجی نشانه OIDC مجاز می کند و سپس درخواست را به سرویس خصوصی ساکن در یک شبکه خصوصی پروکسی می کند. .

با این راه حل، توانسنتد به طور ایمن دسترسی از راه دور را از رانرهای بزرگتر که GitHubActions را اجرا می کنند، به منابع خصوصی خود در VPC ارائه دهند.

گیت هاب داربست های اصلی این دروازه دسترسی از راه دور را در مخزن github/actions-oidc-gateway-example منبع باز کرده است، پس حتماً آن را بررسی کنید!

نتیجه

GitHub Actions یک تجربه توسعه دهنده قوی و روان را برای مهندسین GitHub که در GitHub.com کار می کنند فراهم می کند. آن ها توانسته‌اند این کار را با استفاده از قدرت ویژگی‌های GitHub Actions، مانند work flow قابل استفاده مجدد و نتایج work flow قابل استفاده مجدد، و با استفاده از مقیاس‌پذیری و مدیریت اجراهای بزرگتر GitHub Actions انجام دهند.و همچنین از این تلاش برای بهبود محصول GitHub Actions استفاده کرده اند. به بیان ساده، GitHub روی GitHub اجرا می شود.