کنترل سورس
حساب GitHub یا GitLab مورد استفاده خود را متصل کنید و مستقیماً از یک شاخه مستقر نمایید: در Cloudflare Pages، GitHub Pages، GitLab Pages، Netlify، Vercel، Render، Azure Static Web Apps یا AWS Amplify — یا در میزبانی مدیریت‌شده اختصاصی ما، جایی که مخزن و فایلهای سایت در هر دو جهت همگام باقی می‌مانند. هر اتصال امتیازات مورد نیاز خود را نمایش میدهد، پیش از ذخیره شدن با API ارائهدهنده بررسی میشود و در Vault نگهداری میشود. شما همچنین میتوانید با GitHub یا GitLab وارد شوید.
اتصال، اعتبارنامه‌ای است که به شخص دیگری واگذار میکنید. اتصال ما پیش از ایجاد، نیازهای خود را مشخص میکند، قبل از ذخیره‌سازی کارکرد خود را اثبات می‌نماید و از هر دو طرف قابل لغو است.
پیش از اینکه یک توکن ایجاد کنید، به شما می‌گوییم که چه کاری باید بتواند انجام دهد و چرا. هیچ دامنه دسترسی کلی فقط به این دلیل که درخواست آن آسان‌تر بوده وجود ندارد، و هیچ کشف پس از واقعه‌ای مبنی بر اینکه بیشتر از نیاز کار می‌خواسته‌ایم در کار نیست.
ما توکن شما را پیش از ذخیره‌سازی، با استفاده از API خود ارائهدهنده فراخوانی میکنیم. یک توکن اشتباه، منقضی‌شده یا دارای دامنه نادرست، به‌جای اینکه پذیرفته شود، سالم نشان داده شود و در اولین استقرار واقعی با شکست مواجه گردد، در همان فرم رد میشود.
نه در کد ما، نه در یک فایل محیطی، نه در یک لاگ و نه در خط فرمان. در لحظه استفاده، توسط بار کاری که از آن استفاده میکند حل میشود.
یک حساب کاربری شخصی را به حساب یک سازمان، یا دو سازمان را به یکدیگر متصل کنید. هر سایت انتخاب میکند که استقرار از کدام‌یک انجام شود، بنابراین مخزن مشتری و مخزن شما هرگز اطلاعات اعتبارسنجی مشترکی نخواهند داشت.
هشت میزبان لبه مدیریت‌شده و ناوگان اختصاصی ما. مقصد ویژگی سایت است، نه اتصال؛ بنابراین همان مخزن می‌تواند یک شاخه را در میزبان Pages منتشر کند و سایت دیگری می‌تواند روی سختافزار ما اجرا شود.
پهنای باند نامحدود، مجاز بودن استفاده تجاری، و مدیریت دامنه‌های apex در همان ارائه‌دهنده‌ای که معمولاً منطقه DNS شما را میزبانی میکند. به همین دلایل، این نخستین مقصدی است که به سراغ آن می‌رویم.
میزبانی Cloudflare Pages →مستقیماً از همان مخزنی که کد در آن قرار دارد منتشر کنید. در خط Footprint-Free علامتگذاری شده است، زیرا زیرساخت مشترک github.io خود یک ردپا محسوب میشود.
میزبانی GitHub Pages →سرویس‌های GitLab Pages، Netlify، Vercel، Render، Azure Static Web Apps و AWS Amplify همگی مقاصدی هستند که میتوانید با همان اتصال و همان تاریخچه استقرار، سایتی را به آنها هدایت کنید.
میزبانی وبسایت ایستا →یک برنامه کامل به جای یک بسته ساخته‌شده — WordPress، PHP، Node. این مقصدی است که همگامسازی دوطرفه دریافت میکند، بنابراین فایلهای روی سرور و شاخه هماهنگ باقی می‌مانند.
میزبانی مدیریت‌شده →سایتی که در میزبانی منتشر میشود که متعلق به ما نیست، همچنان سهمیه‌ای مصرف میکند و همراه با استقرارها، آپ‌تایم و داده‌های سئوی خود در کنار سایر مواردی که اجرا میکنید، در داشبورد شما نمایش داده میشود.
سهمیه‌های سایت‌های خارجی →ویرایشگر درون مرورگر روی همان فایل‌هایی کار میکند که همگامسازی دوطرفه آنها را بازمی‌گرداند؛ بنابراین، یک اصلاح سریع از داشبورد، به‌جای تغییری که بعداً هیچ‌کس نتواند آن را پیدا کند، به یک کامیت (commit) در شاخهٔ شما تبدیل میشود.
ویرایشگر وب →همگامسازی دوطرفه
آن را روشن کنید تا فایلهای خود سایت دوباره به شاخه شما کامیت شوند، در حالی که کامیتهای آن شاخه دوباره به سایت بازمیگردند. این قابلیت روی هر سایتی که میزبانی میکنیم و روی هر خط کار میکند — تنها شرط این است که ماشین زیرساخت بتواند Git را روی فایلهای خود اجرا کند، که این مورد به جای فرض شدن بر اساس پلن، مستقیماً از سرور استعلام میشود.
شما انتخاب میکنید که کدام فهرست همگامسازی شود، زیرا یک مشتری WordPress می‌خواهد قالب او ردیابی شود، نه چهل هزار فایل هسته. و تا زمانی که آن را فعال نکنید خاموش می‌ماند: فعال کردن یک همگامسازی تصمیمی در مورد مخزن شخص دیگری است و فرایند انتقال هرگز نباید این تصمیم را به جای شما بگیرد.
دو حالت وجود دارد و تفاوت در محل اجرای بیلد است. هر دو به یک نقطه ختم میشوند: یک مرجع که واکشی و منتشر میکنیم، و کامیت مربوطه در کنار استقرار ثبت میشود.
GitHub یا GitLab، در بخش اتصالات. امتیازات قبل از ایجاد توکن فهرست میشوند و توکن قبل از ذخیره شدن با ارائهدهنده بررسی میشود.
مالک، مخزن، شاخه، و اینکه آیا یک دایرکتوری را منتشر میکنیم یا آنچه را که CI شما ساخته است واکشی میکنیم. ما وبهوک push را به عنوان بخشی از آن ثبت میکنیم.
ارسال (push) به شاخه مشخص‌شده فرآیند استقرار را آغاز میکند، یا میتوانید بنا به درخواست از برگه استقرار سایت اقدام به استقرار نمایید. فرآیندهای ساخت در پس‌زمینه اجرا میشوند.
تاریخچه استقرار نشان میدهد چه چیزی و در چه زمانی منتشر شده است. همگامسازی دوطرفه را فعال کنید تا ویرایش‌هایی که اینجا انجام می‌دهید به‌صورت کامیت در شاخه شما بازگردند.
هنگام بروز مشکل
اتصال مخزنی که سالم به نظر میرسد اما چیزی دریافت نمی‌کند، یک شکست خاموش کلاسیک است — توکنی با محدوده دسترسی نادرست، تحویلی که در ارائهدهنده مسدود شده، قلابی (hook) که فردی به صورت دستی آن را حذف کرده است. این مورد در هر صفحه دیگری نامرئی است، بنابراین کارت مخزن آن را مستقیماً نشان میدهد: آخرین باری که ارائهدهنده به ما تحویل داده است، و پیامی که ارائه کرده است.
تحویل‌ها پیش از اقدام روی آنها از نظر امضا بررسی میشوند، آن هم با طرح اختصاصی هر ارائهدهنده، نه طرحی که فرض کرده باشیم برای همه آنها صدق میکند. تحویلی که تأیید نشود رد شده و ثبت می‌گردد، نه اینکه بدون صدا نادیده گرفته شود.
هویت
در کنار نشانی ایمیل و گذرواژه، میتوانید با GitHub، GitLab، Google یا Microsoft به حساب Zinn Digital® خود وارد شوید. لایه هویت فرآیند دست‌تکانی را اجرا میکند؛ ما هرگز گذرواژه ارائهدهنده شما را نمی‌بینیم و پیوند دادن یک حساب اجتماعی به یک حساب Zinn® موجود همچنان باید از طریق ایمیل تأیید شود.
ورود به سیستم با GitHub و متصل کردن GitHub برای استقرارها، تصمیمات جداگانه و اطلاعات کاربری مجزایی هستند. انجام یکی منجر به انجام دیگری نمیشود و حذف یکی باعث حذف دیگری نخواهد شد.
GitHub و GitLab. حسابی را که در حال حاضر در آن کار میکنید متصل کنید تا بتوانیم از مخازن آن مستقر کنیم، یک وبهوک ارسال روی آنها ثبت نماییم و — در صورت تمایل — فایلهای سایت شما را در جهت دیگر همگامسازی کنیم. هر دو از یک سازوکار حساب متصل یکسان عبور میکنند، بنابراین تمام موارد زیر برای هر دو صادق است.
بله، و با Google یا Microsoft. در کنار آدرس ایمیل و گذرواژه، میتوانید با هر یک از این چهار مورد وارد حساب Zinn Digital® خود شوید. لایه هویت فرآیند تأیید اتصال (handshake) را انجام میدهد و ما هرگز گذرواژه ارائهدهنده شما را نمی‌بینیم. ورود به سیستم با GitHub از اتصال GitHub برای استقرارها مجزا است — شما میتوانید هر کدام، هر دو، یا هیچ‌یک را انجام دهید.
به Cloudflare Pages، GitHub Pages، GitLab Pages، Netlify، Vercel، Render، Azure Static Web Apps یا AWS Amplify برای یک سایت استاتیک یا بیلدشده — یا بر روی هاستینگ مدیریت‌شده خود ما، جایی که مخزن و فایلهای سایت در هر دو جهت همگام باقی می‌مانند. شما مقصد سایت را انتخاب میکنید؛ اتصال مخزن در هر دو حالت یکسان است.
هر کدام. در حالت انتشار، ما شاخه را همانگونه که هست در نظر میگیریم و پوشهای را که مشخص میکنید منتشر میکنیم. در حالت CI، پایپلاین ارائهدهنده شما دستور ساخت شما را اجرا میکند و خروجی را در یک شاخه انتشار مجزا ثبت میکند، سپس ما آن را مانند هر مرجع دیگری دریافت میکنیم. گزینه دوم فرآیند ساخت را در CI خودتان نگه میدارد، جایی که کلیدهای محرمانه و کش شما از قبل در آن قرار دارند.
بهطور پیشفرض، بله — ما یک وبهوک در مخزن ثبت میکنیم و یک پوش (push) به شاخهای که تعیین کردهاید، استقرار را آغاز میکند. میتوانید آن را خاموش کنید و وبهوک را نگه دارید، که بسیار مفیدتر از آن است که به نظر میرسد: تحویل همچنان ثبت میشود، بنابراین میتوانید قبل از اینکه به ما اجازه اقدام بدهید، ورود پوشهای خود را مشاهده کنید.
ویرایشهای انجامشده روی سختافزار ما به کامیتهایی در شاخه شما تبدیل میشوند، و کامیتهای شاخه شما به سایت بازمیگردند. این قابلیت خاموش است تا زمانی که آن را روشن کنید، زیرا روشن کردن آن تصمیمی درباره مخزن شخص دیگری است و ما این تصمیم را به جای شما نخواهیم گرفت. شما انتخاب میکنید که کدام پوشه همگامسازی شود — معمولاً یک پوسته یا یک افزونه، نه چهل هزار فایل هسته WordPress.
هیچ چیزی بازنویسی نمیشود و هیچ چیزی ارسال نمیگردد. همگامسازی متوقف میشود، به شما اطلاع میدهد که شاخه از تعهدی که بر آن تکیه کرده بودیم فراتر رفته است، و میپرسد که کدام طرف را میخواهید — نگهداشتن مخزن یا نگهداشتن سایت. سایتی که هرگز همگامسازی نشده و به شاخهای اشاره دارد که از قبل دارای تعهداتی است نیز وضعیت خاص خود را دارد، و به جای حدس زدن اینکه کدام یک حقیقت است، سؤال میکند.
ما پیش از ایجاد اتصال، مجوزهای مورد نیاز آن را به شما نشان می‌دهیم، توکن را هنگام ورود با API خود ارائهدهنده بررسی میکنیم — تا توکن نامعتبر یا دارای دامنه نادرست هرگز ذخیره نشود — و تنها پس از آن، آن را در Vault می‌نویسیم. این توکن هرگز با کد ما، گزارش‌ها، فایل محیطی یا خط فرمان تماسی نخواهد داشت. هر زمان که تمایل داشتید، آن را نزد ارائهدهنده باطل کنید یا اتصال را از اینجا حذف نمایید.
کارت مخزن نشان میدهد که ارائهدهنده آخرین بار چه زمانی به ما تحویل داده و چه پیامی فرستاده است. عبارت «هرگز تحویل داده نشده» مفیدترین بخش تشخیصی در آن صفحه است، زیرا «متصل اما هرگز تحویل داده نشده» دقیقاً همان حالتی است که برای یک توکن با محدوده دسترسی اشتباه یا یک تحویل مسدودشده رخ میدهد — و در هیچ جای دیگری قابل مشاهده نیست. قبل از اینکه اقدامی روی هر تحویل صورت گیرد، امضای آن بررسی میشود.
ارائه شده و علامتگذاری شده است. GitHub Pages و GitLab Pages از زیرساخت ارائهدهنده و نامهای میزبان عمومی github.io و gitlab.io بهطور مشترک استفاده میکنند، و این یک ردپای سئو است — دقیقاً همان چیزی که این خط برای جلوگیری از آن ایجاد شده است. برای داشتن یک شبکه بدون ردپا، به جای آن روی میزبانی ایزوله مستقر شوید. در هر جای دیگر، Pages درجهیک است.
زیرا سطح رایگان آن فقط برای استفاده غیرتجاری مجوز دارد. در مواردی که ایمن باشد، ما مقصد را از حساب‌هایی که متصل کردهاید استنباط میکنیم، و Vercel عمداً از این استنباط مستثنی شده است — متصل کردن یک حساب هرگز نباید بی‌صدا یک سایت تجاری را در جایی قرار دهد که مجوز آن مجاز نمی‌داند. آن را انتخاب کنید و دقیقاً مانند سایر موارد کار میکند.
بله. هر استقرار، کامیت منتشرشده، زمان اجرا و نحوه پایان آن را ثبت میکند و برگه استقرار سایت، تاریخچه را به همراه نشانی وب زنده در کنار آن نمایش میدهد. استقرارها در پس‌زمینه اجرا میشوند، بنابراین صفحه با تکمیل ساخت به‌روزرسانی میشود، به جای اینکه شما را منتظر نشانگر بارگذاری نگه دارد.
یک دوره آزمایشی ۱۴ روزه بدون نیاز به کارت را شروع کنید، GitHub یا GitLab را متصل نمایید و سایتی را به یک شاخه هدایت کنید. روی یک هاست لبه (edge) یا روی هاستینگ خود ما با همگامسازی دوطرفه فایل‌ها منتشر کنید.
رایگان شروع کنید