Керування версіями
Підключіть обліковий запис 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. Це цільове місце, яке отримує двосторонню синхронізацію, тож файли на сервері та у гілці завжди узгоджені між собою.
Керований хостинг →Сайт, опублікований на хості, яким ми не володіємо, все одно витрачає квоту та відображається на вашій панелі керування разом із даними про розгортання, час безвідмовної роботи та SEO поруч з усім іншим, що ви запускаєте.
Квоти для зовнішніх сайтів →Редактор у браузері працює з тими самими файлами, які повертає двостороння синхронізація, тому швидке виправлення з панелі керування стає комітом у вашій гілці замість зміни, яку згодом ніхто не зможе знайти.
Вебредактор →Двостороння синхронізація
Увімкніть це, і власні файли сайту фіксуватимуться назад у вашу гілку, тоді як коміти з цієї гілки надходитимуть назад на сайт. Це працює для кожного сайту, який ми хостимо, на кожній лінії — єдина вимога полягає в тому, щоб машина під ним могла запускати Git для своїх файлів, що запитується в сервера, а не припускається на основі тарифного плану.
Ви самі обираєте, який каталог синхронізувати, оскільки клієнт WordPress хоче відстежувати свою тему, а не сорок тисяч файлів ядра. І це вимкнено, доки ви самі це не ввімкнете: увімкнення синхронізації — це рішення щодо чужого репозиторію, і міграція ніколи не повинна приймати його за вас.
Два режими, і різниця полягає в тому, де саме виконується збірка. Обидва завершуються в одному місці: посиланні, яке ми отримуємо та публікуємо, а коміт фіксується для розгортання.
GitHub або GitLab, у розділі Підключення. Привілеї перераховуються перед створенням токена, і перед збереженням він перевіряється у постачальника.
Власник, репозиторій, гілка, а також те, чи публікуємо ми каталог, чи отримуємо те, що зібрав ваш CI. У межах цього ми реєструємо push-вебхук.
Надсилання (push) до призначеної гілки запускає розгортання, або ви можете розгорнути за запитом на вкладці Розгортання сайту. Збірки виконуються у фоновому режимі.
Історія розгортання показує, що та коли було опубліковано. Увімкніть двосторонню синхронізацію, і внесені тут зміни повертатимуться як коміти у вашу гілку.
Коли щось іде не так
З'єднання зі сховищем, яке виглядає справним і нічого не отримує, є класичним прихованим збоєм — токен із неправильною областю дії, доставка, заблокована на боці провайдера, вебхук, який хтось видалив вручну. Це невидимо на будь-якому іншому екрані, тому картка сховища показує це безпосередньо: коли провайдер востаннє надсилав нам дані та що саме він повідомив.
Доставки проходять перевірку підпису перед тим, як ми виконуємо дії над ними, за власною схемою кожного постачальника, а не за схемою, яку ми вважали спільною для всіх. Доставка, яка не пройшла перевірку, відхиляється та реєструється, а не ігнорується без повідомлення.
Ідентичність
Окрім адреси електронної пошти та пароля, ви можете входити до свого облікового запису Zinn Digital® за допомогою GitHub, GitLab, Google або Microsoft. Рівень ідентифікації виконує узгодження зв’язку (handshake); ми ніколи не бачимо пароль вашого провайдера, а зв’язування облікового запису соціальної мережі з наявним обліковим записом Zinn® все ще потребує підтвердження електронною поштою.
Вхід за допомогою GitHub та підключення GitHub для розгортань — це окремі рішення та окремі облікові дані. Виконання одного не означає виконання іншого, а видалення одного не видаляє інше.
GitHub та GitLab. Підключіть обліковий запис, у якому ви вже працюєте, і ми зможемо розгортати з його репозиторіїв, реєструвати в них push-вебхук та — за вашим бажанням — синхронізувати файли вашого сайту у зворотному напрямку. Обидва варіанти проходять через той самий механізм підключеного облікового запису, тому все наведене нижче стосується будь-якого з них.
Так, а також через Google або Microsoft. Окрім адреси електронної пошти та пароля, ви можете увійти до свого облікового запису Zinn Digital® за допомогою будь-якого з цих чотирьох способів. Рівень автентифікації керує процесом узгодження зв'язку, і ми ніколи не бачимо пароль вашого провайдера. Вхід через GitHub — це окрема дія від підключення GitHub для розгортання: ви можете обрати будь-що з цього, обидва варіанти або жодного.
На Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps або AWS Amplify для статичного чи зібраного сайту — або на наш власний керований хостинг, де репозиторій і файли сайту синхронізуються в обох напрямках. Ви обираєте місце призначення для сайту; підключення репозиторію однакове в будь-якому разі.
Будь-який варіант. У режимі публікації ми беремо гілку як є та публікуємо вказаний вами каталог. У режимі CI власний конвеєр вашого провайдера виконує вашу команду збирання та фіксує вихідні дані в окремій гілці публікації, яку ми потім отримуємо, як і будь-яке інше посилання. Другий варіант зберігає ваше збирання у вашому власному CI, де вже розміщені ваші конфіденційні дані та кешування.
За замовчуванням так — ми реєструємо вебхук у репозиторії, і push у вибрану вами гілку запускає розгортання. Ви можете вимкнути це та зберегти вебхук, що корисніше, ніж здається: доставка все одно записується, тож ви можете спостерігати за надходженням ваших push-подій, перш ніж дозволити нам діяти за ними.
Зміни, внесені на нашому обладнанні, стають комітами у вашій гілці, а коміти з вашої гілки повертаються на сайт. Цю функцію вимкнено, доки ви не ввімкнете її, оскільки її ввімкнення є рішенням щодо чужого репозиторію, і ми не прийматимемо його за вас. Ви самі обираєте каталог для синхронізації — зазвичай це тема або плагін, а не сорок тисяч файлів ядра WordPress.
Нічого не перезаписується і нічого не надсилається. Синхронізація зупиняється, повідомляє вам, що гілка перемістилася далі коміту, на якому ми базувалися, і запитує, яку сторону ви бажаєте обрати — залишити репозиторій чи залишити сайт. Сайт, який ніколи не синхронізувався і вказує на гілку, яка вже містить коміти, також є окремим станом, і замість того, щоб угадувати, де правда, система запитує про це у вас.
Ми показуємо вам привілеї, необхідні для підключення, перед тим, як ви його створите, перевіряємо токен за допомогою власного API постачальника під час введення — тому недійсний токен або токен із неправильною областю дії взагалі ніколи не зберігається — і лише після цього записуємо його у Vault. Він ніколи не потрапляє в наш код, журнал, файл середовища чи командний рядок. Відкличте його в постачальника або видаліть підключення тут, коли забажаєте.
Картка репозиторію показує, коли постачальник востаннє здійснив доставку до нас і що саме повідомив. «Ніколи не доставлялося» — це найбільш корисна діагностична інформація на цьому екрані, оскільки «підключено, але ніколи не доставлялося» — це саме те, як виглядає токен із неправильною областю дії або заблокована доставка — і це невидимо більше ніде. Кожна доставка перевіряється за підписом, перш ніж ми опрацюємо її.
Це пропонується, і це позначено прапорцем. GitHub Pages та GitLab Pages спільно використовують інфраструктуру провайдера і загальнодоступні імена хостів github.io та gitlab.io, а це слід (footprint) — саме те, для уникнення чого існує ця лінійка. Для мережі з нульовим слідом натомість розгортайте на ізольованому хостингу. В усіх інших випадках Pages — це першокласний вибір.
Оскільки його безкоштовний рівень ліцензовано лише для некомерційного використання. Ми визначаємо призначення на основі підключених вами облікових записів там, де це безпечно, і Vercel навмисно виключено з цього процесу — підключення облікового запису ніколи не повинно непомітно розміщувати комерційний сайт там, де це заборонено його ліцензією. Виберіть його, і він працюватиме точно так само, як і інші.
Так. Кожне розгортання фіксує опублікований коміт, час запуску та результат завершення, а на вкладці Розгортання сайту відображається історія поруч із робочою URL-адресою. Розгортання виконуються у фоновому режимі, тому сторінка оновлюється в міру завершення збірки, а не змушує вас чекати індикатора завантаження.
Розпочніть 14-денний пробний період без банківської картки, підключіть GitHub або GitLab і спрямуйте сайт на гілку. Опублікуйте на крайовому хості або на нашому власному хостингу із двосторонньою синхронізацією файлів.
Почати безкоштовно