مشکل SFTP و deploy های دستی
deploy با کشیدن فایلها روی SFTP همان راهی است که سایتها نیمهخراب از آب درمیآیند: یک فایل جا میماند، composer اجرا نمیشود، یک migration فراموش میشود، و cache همچنان bundle قدیمی را ارائه میدهد. هیچ سابقهای از آنچه منتشر شده نیست و هیچ راه تمیزی برای بازتولید آن. GitHub Deploy این را با یک خط تولید تعریفشده گرهخورده به مخزن شما جایگزین میکند، بنابراین یک انتشار نتیجه قطعی یک commit بهعلاوه یک مجموعه ثابت از گامهاست — یکسان در هر بار، توسط هرکس در تیم.
گامهای build شما، بهصورت پیوسته اجراشده
یک deploy واقعی چیزی بیش از کپی فایلهاست: وابستگیها باید نصب شوند، داراییها کامپایل شوند و migration های دیتابیس به ترتیب درست اعمال گردند. آن گامها را یکبار تعریف میکنید — برای مثال composer install، یک build از نوع npm یا دارایی، و یک دستور migration — و در هر deploy روی دقیقاً همان commit در حال انتشار اجرا میشوند. این کل آن دسته باگهایی را از بین میبرد که در آن تولید متفاوت رفتار میکند چون کسی گامها را به ترتیب دیگری اجرا کرده یا یکی را زیر فشار جا انداخته است.
deploy های دستی و auto-deploy با webhook
تیمهای مختلف تریگرهای متفاوتی میخواهند. یک تیم محتاط deploy ها را دستی نگه میدارد و پس از بازبینی در پنل روی deploy کلیک میکند تا یک انتشار یک اقدام عمدی باشد. یک تیم پُرشتاب webhook را فعال میکند تا هر push به شاخه تولید بهصورت خودکار منتشر شود و git push را به یک deploy تبدیل کند. هر دو همان خط تولید را اجرا میکنند؛ تنها تفاوت این است که چه چیزی ماشه را میکشد، و میتوانید دستی شروع کنید و پس از اعتماد به جریان، webhook را روشن کنید.
مخازن خصوصی و token های امن
بیشتر کد واقعی در مخازن خصوصی است، بنابراین پلتفرم با یک token که شما فراهم میکنید احراز هویت میکند بهجای اینکه کد را عمومی بخواهد. token بهعنوان یک secret ذخیره و تنها برای clone در زمان deploy استفاده میشود؛ پس از ذخیره هرگز در لاگها یا UI ظاهر نمیشود، و چون جدا از کد شماست میتوانید آن را مستقل بچرخانید یا باطل کنید. تحویلهای webhook با یک secret امضاشده تأیید میشوند بنابراین یک POST تصادفی نمیتواند یک انتشار را راه بیندازد.
auto-purge آخرین شکاف را میبندد
رایجترین باگ پس از deploy این است که یک انتشار تازه پشت یک edge cache کهنه پنهان میماند — CSS یا JS جدید منتشر شده، اما بازدیدکنندگان همچنان bundle قدیمی و cacheشده را بارگذاری میکنند. GitHub Deploy، edge cache را بهعنوان بخشی از انتشار purge میکند، بنابراین deploy تا وقتی cache فایلهای جدید را بازتاب ندهد پایانیافته محسوب نمیشود. این گام flush دستی را که مردم فراموش میکنند حذف میکند، و یعنی آنچه منتشر کردهاید همان چیزی است که بازدیدکنندگان واقعاً دریافت میکنند.
تحویل تکرارپذیر برای تیمها و آژانسها
وقتی هر پروژه به همان روش deploy میشود، onboarding و تحویل دیگر دانش قبیلهای نیستند. وضعیت deploy، زمان آخرین deploy و گامهای پیکربندیشده در پنل قابلمشاهدهاند، بنابراین هرکس میتواند ببیند آیا آخرین push به تولید رسیده و چه چیزی اجرا شده است. برای آژانسها این یعنی یک مدل تحویل استاندارد در سراسر پروژههای مشتری، جایی که سپردن یک سایت به توسعهدهنده دیگر نیازمند مهندسی معکوس یک آیین deploy سفارشی و بدون سند نیست.
راهنمای گامبهگام deploy
مخزن و شاخه را متصل کنید
در پنل اپلیکیشن خود را باز کنید، به GitHub Deploy بروید، و URL مخزن و شاخهای را که از آن deploy میکنید وارد کنید — معمولاً main یا production. شاخهای که انتخاب میکنید همان است که زنده میشود، بنابراین شاخههای feature هرگز بهطور تصادفی منتشر نمیشوند.
یک مخزن خصوصی را مجاز کنید
اگر مخزن خصوصی است، یک personal access token یا deploy token اضافه کنید تا پلتفرم بتواند آن را clone کند. token بهعنوان یک secret ذخیره میشود، تنها برای pull کد در زمان deploy استفاده میگردد، و میتوان آن را بدون دست زدن به اپلیکیشن باطل یا چرخاند.
گامهای build و migration را تعریف کنید
دستورهایی را تنظیم کنید که یک checkout را به یک انتشار در حال اجرا تبدیل میکنند — برای یک اپلیکیشن PHP معمولاً composer install --no-dev، یک build دارایی فرانتاند و یک migration دیتابیس. این گامها با اپلیکیشن ذخیره میشوند بنابراین هر deploy همان خط تولید یکسان را اجرا میکند، نه هر آنچه کسی بهخاطر میآورد تایپ کند.
دستی یا auto-deploy با webhook را انتخاب کنید
با یک دکمه در پنل در صورت نیاز deploy کنید، یا webhook را فعال کنید تا یک push به شاخه متصل، بهصورت خودکار deploy را راه بیندازد. webhook از یک secret امضاشده استفاده میکند، بنابراین تنها push های واقعی از مخزن شما میتوانند یک انتشار را شروع کنند.
منتشر کنید، purge کنید و تأیید کنید
هنگام deploy، پلتفرم شاخه را pull میکند، گامهای شما را اجرا میکند و انتشار جدید را فعال میکند؛ edge cache برای داراییهای تغییریافته بهصورت خودکار purge میشود تا فایلهای کهنه به بازدیدکنندگان ارائه نشود. پنل وضعیت deploy و زمان آخرین deploy را نشان میدهد تا زنده بودن انتشار را تأیید کنید.
نمونه سناریوها
یک push به main، composer install، یک build دارایی و migration ها را راه میاندازد، سپس انتشار منتشر میشود و edge cache بهصورت خودکار purge میگردد.
یک آژانس یک مخزن خصوصی GitHub را با یک deploy token محدود متصل میکند و کد را بسته نگه میدارد در حالی که پلتفرم همچنان آن را pull و deploy میکند.
یک تیم auto-deploy را خاموش نگه میدارد و پس از بازبینی کد در پنل روی deploy کلیک میکند، بنابراین هر انتشار تولیدی یک اقدام عمدی و ثبتشده است.
پرسشهای پرتکرار
آیا GitHub Deploy یک image داکر میسازد یا کد منبع را deploy میکند؟
کد منبع اپلیکیشن را روی runtime پلتفرم deploy میکند — شاخه شما را pull و گامهای build و migration شما را روی خودِ کد اجرا میکند. این انتخاب طبیعی برای اپلیکیشنهای PHP و فریمورکی است. اگر بهطور خاص میخواهید یک image از نوع container ساخته و اجرا شود، بهجای آن از Container Apps با یک image از پیش ساختهشده یا Docker Compose Instant Deploy استفاده کنید.
در یک push از نوع webhook دقیقاً چه اتفاقی میافتد؟
یک push به شاخه متصل، یک webhook امضاشده به پلتفرم میفرستد، که امضا را تأیید میکند، آن commit را clone یا fetch میکند، گامهای build و migration تعریفشده شما را اجرا میکند، انتشار جدید را فعال و edge cache را purge میکند. سپس پنل وضعیت deploy و زمان آخرین deploy را بهروزرسانی میکند تا فرود آن را تأیید کنید.
access token من چگونه محافظت میشود؟
token بهعنوان یک secret ذخیره و تنها برای clone مخزن در زمان deploy استفاده میشود. پس از ذخیره نمایش داده نمیشود و در build log ها ظاهر نمیگردد، و چون جدا از کد شما زندگی میکند میتوانید آن را در GitHub بچرخانید یا باطل کنید بدون تغییر چیزی در اپلیکیشن.
اگر یک deploy خراب شود میتوانم rollback کنم؟
چون deploy ها به commit ها و گامهای تعریفشده گره خوردهاند، بازیابی به معنای deploy یک commit سالم شناختهشده است — deploy را به commit کاری قبلی اشاره میدهید یا روی شاخه revert میکنید و میگذارید خط تولید آن را منتشر کند. تکرارپذیر نگه داشتن deploy ها دقیقاً همان چیزی است که بازگشت را قابلاتکا میکند نه یک تقلا.
کدام شاخه زنده میشود، و آیا میتوانم از بیش از یکی deploy کنم؟
شاخهای را که از آن deploy میکنید انتخاب میکنید، معمولاً main یا یک شاخه اختصاصی تولید، و تنها همان شاخه منتشر میشود — push به شاخههای feature دیپلوی نمیکند. این کار در حال انجام را از تولید بیرون نگه میدارد در حالی که همچنان به شما امکان میدهد بهمحض merge به شاخه انتشار، deploy کنید.
آیا با GitLab یا میزبانهای دیگر Git کار میکند، یا فقط GitHub؟
گردشکار حول یک URL مخزن Git، یک شاخه و یک token ساخته شده، بنابراین بهطور خاص محدود به GitHub نیست — هر مخزنی که با یک URL و یک access token به آن دسترسی داشته باشید با همان مدل جور درمیآید. GitHub حالت رایج است، به همین دلیل به نام آن نامگذاری شده، اما مکانیک آن Git استاندارد است.