Контрол на изходния код

Внедрявайте от хранилището, което вече използвате — девет места, където да го разположите

Свържете профила в GitHub или GitLab, в който работите, и внедрявайте директно от клон: към Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps или AWS Amplify — или към нашия собствен управляван хостинг, където хранилището и файловете на сайта остават синхронизирани в двете посоки. Всяка връзка показва привилегиите, които изисква, проверява се чрез API на доставчика, преди да бъде запазена, и се съхранява във Vault. Можете също така да влизате с GitHub или GitLab.

Комит, преминаващ през конвейер от хранилище към действащ сайт.
  • GitHub + GitLabСвържете профила, който вече имате
  • Девет дестинацииосем крайни хоста, плюс нашия собствен автопарк
  • Двупосочно синхронизираневсеки сайт, всеки ред
  • Съхранявано във Vaultвалидирано при въвеждане, никога в регистър
  • Токенът е проверен преди съхранениетокен с прекалено широк обхват никога не се прилага
  • Изтласкване за внедряванес проверен подпис и по избор
  • Вашият клон, вашето компилиранепубликувайте директория или стартирайте собствен CI
  • Прекъснете връзката чистопремахваме точно куката, която създадохме

Свържете се веднъж и вижте с какво се съгласявате

Връзката е идентификационни данни, които предоставяте на някой друг. Нашата посочва от какво се нуждае, преди да я създадете, доказва, че работи, преди да я запази, и може да бъде оттеглена от двете страни.

Привилегиите, посочени предварително

Преди да създадете токен, ние ви казваме какво трябва да може да прави той и защо. Без всеобхватен обхват само защото е било по-лесно да се поиска, и без да установяваме впоследствие, че сме искали повече, отколкото е било необходимо за задачата.

Проверено спрямо доставчика, не е прието на доверие

Извикваме собствения API на доставчика с Вашия токен, преди да го съхраним. Грешен, изтекъл или с неправилен обхват токен се отхвърля още във формуляра, вместо да бъде приет, показан като изправен и да се провали при първото реално внедряване.

Съхранява се във Vault и никъде другаде

Не в нашия код, не във файл на средата, не в лог и не на команден ред. Разрешава се в момента, в който се използва, от работното натоварване, което го използва.

Повече от един акаунт, избран за всеки сайт

Свържете личен акаунт и акаунт на организация, или две организации. Всеки сайт избира от кой да се внедрява, така че хранилището на клиента и вашето собствено никога да не споделят едни и същи идентификационни данни.

Девет места, където може да попадне хранилище

Осем управлявани крайни хоста и собствен автопарк. Дестинацията е свойство на сайта, а не на връзката, така че едно и също хранилище може да публикува един клон към Pages хост, а друг сайт може да работи на нашия хардуер.

Cloudflare Pages

Неограничена честотна лента, разрешено търговско използване и управление на apex домейни при същия доставчик, който обикновено поддържа Вашата DNS зона. Това е първият избор, към който се обръщаме поради тези причини.

Хостинг на Cloudflare Pages →

GitHub Pages

Публикувайте директно от хранилището, в което кодът вече се намира. Отбелязано на реда Footprint-Free, тъй като споделената инфраструктура на github.io сама по себе си представлява отпечатък.

Хостинг на GitHub Pages →

GitLab Pages, Netlify, Vercel и останалите

GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps и AWS Amplify са дестинации, към които можете да насочите сайт, със същата връзка и същата история на внедряване.

Хостинг на статични сайтове →

Нашият собствен управляван хостинг

Цялостно приложение, а не компилиран пакет — WordPress, PHP, Node. Това е дестинацията, която получава двупосочна синхронизация, така че файловете на машината и в клона да остават съгласувани.

Управляван хостинг →

Сайтове на чужда периферия

Сайт, публикуван на хост, който не притежаваме, все пак изразходва лимит и продължава да се показва във вашето табло за управление със своите внедрявания, време на непрекъсната работа и SEO данни редом с всичко останало, което управлявате.

Квоти за външни сайтове →

Или го редактирайте тук

Редакторът в браузъра работи със същите файлове, които двупосочната синхронизация връща обратно, така че бърза корекция от контролния панел се превръща в commit във Вашия клон, вместо в промяна, която никой не може да открие по-късно.

Уеб редакторът →

Двупосочно синхронизиране

Вашето хранилище и вашият сайт на живо, в пълна хармония

Включете го и собствените файлове на сайта ще бъдат комитнати обратно във вашия клон, докато комитите в този клон се връщат обратно към сайта. Работи на всеки сайт, който хостваме, на всеки ред — единственото изискване е машината отдолу да може да изпълнява Git спрямо своите файлове, което се изисква от сървъра, а не се предполага от плана.

Вие избирате коя директория да се синхронизира, тъй като клиентът на WordPress иска да се проследява неговата тема, а не четиридесет хиляди основни файла. И тя е изключена, докато не я включите: активирането на синхронизация е решение относно чуждо хранилище и миграцията никога не трябва да го взема вместо вас.

  • Редакциите на нашия хардуер стават къмити във вашия клон
  • Промените във вашия клон се връщат към сайта
  • Синхронизирайте една директория — тема, плъгин — а не цялата главна директория на документите
  • Изключено по подразбиране, включително за всеки вече съществуващ сайт
Файл, отворен в редактор, със същия файл, показан като подаване (commit) в хранилище.

Публикувайте директория или позволете на вашата собствена CI система да я изгради

Два режима, като разликата е къде се изпълнява компилацията. И двата завършват на едно и също място: препратка, която изтегляме и публикуваме, със запис на комита към внедряването.

  • Режимът на публикуване взема вашия клон такъв, какъвто е, и публикува посочената от вас директория — празно поле означава корена на хранилището.
  • Режимът на CI изпълнява Вашата команда за компилиране в собствения конвейер на Вашия доставчик и записва изходните данни в отделен клон за публикуване, който ние изтегляме както всяка друга референция.
  • Клонът, от който се публикува внедряването, винаги се посочва изрично с името си, а не просто като „клона по подразбиране“ — клонът по подразбиране може да се промени неочаквано, а хронология, която не може да покаже от кой клон е публикувано, не е никаква хронология.
  • Автоматичното внедряване е включено по подразбиране и може да бъде изключено, без да премахвате уебхука, за да можете да наблюдавате пристигането на доставките, преди да разрешите тяхното действие.
  • Всяко внедряване записва своя комит, резултат и време и се изпълнява във фонов режим — страницата се актуализира при завършване на компилацията.
  • Прекъсването на връзката премахва точно създадения от нас уебхук чрез неговия идентификатор и нищо друго във вашето хранилище.

От хранилището до работещия сайт

  1. Свързване на профила

    GitHub или GitLab, под Връзки. Привилегиите са изброени, преди да създадете токена, и той се проверява спрямо доставчика, преди да бъде съхранен.

  2. Насочване на сайт към хранилище

    Собственик, хранилище, клон и дали публикуваме директория, или изтегляме компилираното от вашия CI. Регистрираме push уебкуката като част от този процес.

  3. Бутнете или натиснете бутона

    Пушването към посочения клон стартира внедряване, или можете да внедрите при поискване от раздела за внедряване на сайта. Компилациите се изпълняват във фонов режим.

  4. Гледайте го и синхронизирайте обратно, ако желаете

    Историята на внедряванията показва какво е било публикувано и кога. Включете двупосочната синхронизация и редакциите, които правите тук, ще се връщат като камити във вашия клон.

При възникнал проблем

„Свързан, но никога недостатъчен“ е състояние, за което действително ще ви уведомим

Връзка с хранилище, която изглежда изправна и не получава нищо, е класическият тих срив — токен с грешен обхват, блокирана доставка при доставчика, кука (hook), премахната ръчно от някого. Това е невидимо на всеки друг екран, затова картата на хранилището го отразява директно: кога доставчикът за последно ни е доставил данни и какво е съобщил.

Доставките се проверяват за подпис, преди да предприемем действия по тях, със собствената схема на всеки доставчик, вместо с такава, за която сме предположили, че се прилага за всички. Доставка, която не се потвърди, се отхвърля и записва, а не се пренебрегва тихо.

  • Време и съобщение за последната доставка, на картата
  • Посочва се „Никога не е доставяно“, а не се оставя празно
  • Подписът е потвърден за всеки доставчик преди стартирането на каквото и да било
  • Куката, която създадохме, се премахва по идентификатор, когато прекъснете връзката
Доставка на уебкука пристига и се проверява, преди да задейства каквото и да било.

Самоличност

Влизане с GitHub или GitLab — или Google, или Microsoft

Освен с имейл адрес и парола, можете да влезете в своя акаунт в Zinn Digital® чрез GitHub, GitLab, Google или Microsoft. Слоевете за идентичност извършват ръкостискането; ние никога не виждаме вашата парола при доставчика, а свързването на социален акаунт със съществуващ акаунт в Zinn® все още трябва да бъде потвърдено по имейл.

Влизането с GitHub и свързването на GitHub за внедрявания са отделни решения и отделни идентификационни данни. Извършването на едното не води до другото, а премахването на едното не премахва другото.

  • Вход с GitHub, GitLab, Google и Microsoft
  • Ключове за достъп и двуфакторна автентификация в един и същ акаунт
  • Данните за вход и за внедряване остават отделни
Делегиран достъп за вашия екип
Няколко души, влизащи в един акаунт чрез различни доставчици.

Често задавани въпроси

Кои доставчици на системи за контрол на версиите мога да свържа?

GitHub и GitLab. Свържете профила, в който вече работите, и ние ще можем да внедряваме от неговите хранилища, да регистрираме push webhook за тях и — ако желаете — да синхронизираме обратно файловете на сайта Ви. И двата преминават през една и съща връзка на свързан профил, така че всичко по-долу важи и за двата.

Мога ли да вляза с GitHub или GitLab?

Да, а също и с Google или Microsoft. Наред с имейл адрес и парола, можете да влезете в своя Zinn Digital® акаунт с всеки от четирите метода. Идентификационният слой управлява установяването на връзка и ние никога не виждаме паролата ви при доставчика. Влизането с GitHub е отделно от свързването на GitHub за внедрявания — можете да направите едното, и двете или нито едното.

Къде мога да внедря хранилище?

Към Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps или AWS Amplify за статичен или компилиран сайт — или към нашия собствен управляван хостинг, където хранилището и файловете на сайта остават синхронизирани и в двете посоки. Вие избирате дестинацията за сайта; връзката с хранилището е една и съща и в двата случая.

Можете ли да изградите моя сайт, или той трябва да бъде предварително изграден?

И двете. В режим на публикуване вземаме клона такъв, какъвто е, и публикуваме посочената от Вас директория. В режим на CI собственият пайплайн на Вашия доставчик изпълнява Вашата команда за изграждане и записва изходните данни в отделен клон за публикуване, който след това изтегляме както всяка друга референция. Вторият начин запазва изграждането във Вашия собствен CI, където вече се намират Вашите тайни ключове и кеширане.

Автоматично ли се внедрява push?

По подразбиране, да — регистрираме уебкука (webhook) в хранилището и всяко подаване (push) към посочения от Вас клон стартира внедряване. Можете да изключите това и да запазите уебкуката, което е по-полезно, отколкото изглежда: доставката все още се записва, така че можете да наблюдавате пристигането на Вашите подавания, преди да ни разрешите да предприемем действия по тях.

Какво представлява двупосочната синхронизация?

Редакциите, направени на нашия хардуер, се превръщат в съмити (commits) във вашия клон, а съмитите във вашия клон се връщат към сайта. Функцията е изключена, докато не я включите, тъй като включването ѝ е решение относно чуждо хранилище и ние няма да го вземем вместо вас. Вие избирате коя директория да се синхронизира — обикновено тема или плъгин, а не четиридесет хиляди основни файла на WordPress.

Какво се случва, ако и двете страни са се променили?

Нищо не се презаписва и нищо не се изпраща. Синхронизирането спира, уведомява Ви, че клонът е преминал отвъд ангажимента, на който сме се базирали, и пита коя страна искате — да запазите хранилището или да запазите сайта. Сайт, който никога не се е синхронизирал и сочи към клон, който вече има ангажименти, също е в собствено състояние и вместо да гадае коя е истината, той пита.

Как е защитен моят токен за достъп?

Показваме ви привилегиите, от които се нуждае връзката, преди да я създадете, проверяваме токена спрямо собствения API на доставчика при въвеждане — така че невалиден токен или токен с грешен обхват изобщо да не бъде съхраняван — и едва тогава го записваме във Vault. Той никога не се докосва до нашия код, лог файл, конфигурационен файл на средата или команден ред. Отменете го при доставчика или премахнете връзката оттук, когато пожелаете.

Как да разбера дали действително получавате моите push заявки?

Картата на хранилището показва кога доставчикът за последно ни е предоставил данни и какво е съобщено. „Никога не е доставяно“ е най-полезната диагностика на този екран, тъй като „свързано, но никога недоставяно“ изглежда точно като токен с неправилен обхват или блокирана доставка — и това е невидимо навсякъде другаде. Всяка доставка се проверява за валиден подпис, преди да предприемем действия по нея.

Мога ли да използвам внедряване на Pages в линията Footprint-Free?

Предлага се и е отбелязано. GitHub Pages и GitLab Pages споделят инфраструктура на доставчика и публични хост имена github.io и gitlab.io, а това представлява отпечатък за търсачките — единственото нещо, което тази линия цели да избегне. За мрежа с нулев отпечатък разгърнете вместо това на изолиран хостинг. Навсякъде другаде Pages е от първокласно ниво.

Защо трябва изрично да избера Vercel?

Тъй като безплатният му план е лицензиран само за нетърговска употреба. Ние извличаме дестинация от свързаните от Вас акаунти, където това е безопасно, а Vercel умишлено е изключен от това извличане — свързването на акаунт никога не трябва тихомълком да поставя търговски сайт на място, което лицензът му не позволява. Изберете го и той ще работи точно както останалите.

Мога ли да видя какво е било внедрено и кога?

Да. Всяко внедряване записва къмита, който е публикувало, кога е стартирано и как е завършило, а разделът за внедряване на сайта показва хронологията с активния URL адрес до него. Внедряванията се изпълняват във фонов режим, така че страницата се актуализира при завършване на компилацията, вместо да се налага да чакате въртящ се индикатор.

Внедряване от вашето хранилище

Започнете 14-дневен пробен период без карта, свържете GitHub или GitLab и насочете сайт към клон. Публикувайте на краен хост или на нашия собствен хостинг със синхронизиране на файловете в двете посоки.

Започнете безплатно