Gestion du code source
Connectez le compte GitHub ou GitLab dans lequel vous travaillez et déployez directement depuis une branche : vers Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps ou AWS Amplify — ou sur notre propre hébergement géré, où le dépôt et les fichiers du site restent synchronisés dans les deux sens. Chaque connexion affiche les privilèges dont elle a besoin, est vérifiée auprès de l’API du fournisseur avant d’être stockée, et réside dans Vault. Vous pouvez également vous connecter avec GitHub ou GitLab.
Une connexion est un identifiant que vous confiez à un tiers. La nôtre indique ses prérequis avant que vous ne la créiez, prouve son bon fonctionnement avant de l’enregistrer et peut être révoquée par l’une ou l’autre des parties.
Avant que vous ne créiez un jeton, nous vous indiquons ce qu’il doit pouvoir faire et pourquoi. Aucun périmètre général simplement parce qu’il était plus facile à demander, et aucune découverte a posteriori indiquant que nous en voulions plus que nécessaire pour la tâche.
Nous appelons l’API propre du fournisseur avec votre jeton avant de le stocker. Un jeton erroné, expiré ou dont la portée est incorrecte est rejeté dès le formulaire, plutôt que d’être accepté, affiché comme opérationnel et d’échouer lors du premier déploiement réel.
Pas dans notre code, pas dans un fichier d’environnement, pas dans un journal et pas sur une ligne de commande. Résolu au moment où il est utilisé, par la charge de travail qui l’utilise.
Connectez un compte personnel et celui d’une organisation, ou deux comptes d’organisation. Chaque site choisit celui à partir duquel il est déployé, de sorte que le dépôt d’un client et le vôtre ne partagent jamais leurs identifiants.
Huit hôtes périphériques gérés et notre propre flotte. La destination est une propriété du site et non de la connexion, de sorte que le même référentiel peut publier une branche sur un hôte Pages et un autre site peut fonctionner sur notre matériel.
Bande passante illimitée, utilisation commerciale autorisée et domaines apex gérés chez le même fournisseur qui héberge habituellement votre zone DNS. C’est la première option vers laquelle nous nous tournons pour ces raisons.
Hébergement Cloudflare Pages →Publiez directement depuis le dépôt où se trouve déjà le code. Signalé sur la ligne Footprint-Free, car l’infrastructure partagée github.io constitue en elle-même une empreinte.
Hébergement GitHub Pages →GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps et AWS Amplify sont toutes des destinations vers lesquelles vous pouvez diriger un site, avec la même connexion et le même historique de déploiement.
Hébergement de sites statiques →Une application complète plutôt qu’un paquet compilé — WordPress, PHP, Node. Il s’agit de la destination qui bénéficie d’une synchronisation bidirectionnelle, afin que les fichiers sur la machine et sur la branche restent synchronisés.
Hébergement géré →Un site publié sur un hébergeur qui ne nous appartient pas consomme tout de même un forfait et continue d’apparaître dans votre tableau de bord avec ses déploiements, son temps de disponibilité et ses données SEO, aux côtés de tout ce que vous gérez.
Quotas de sites externes →L’éditeur intégré au navigateur fonctionne sur les mêmes fichiers que ceux renvoyés par la synchronisation bidirectionnelle, de sorte qu’une correction rapide depuis le tableau de bord devient un commit sur votre branche au lieu d’une modification que personne ne pourra retrouver plus tard.
L’éditeur web →Synchronisation bidirectionnelle
Activez-le et les fichiers propres au site seront validés en retour sur votre branche, tandis que les commits sur cette branche redescendront vers le site. Cela fonctionne sur chaque site que nous hébergeons, sur chaque ligne — la seule exigence est que la machine sous-jacente puisse exécuter Git sur ses fichiers, ce qui est demandé au serveur plutôt que supposé à partir de l’offre.
Vous choisissez le répertoire à synchroniser, car un client WordPress souhaite que son thème soit suivi, et non quarante mille fichiers de base. Et elle reste désactivée tant que vous ne l’activez pas : activer une synchronisation est une décision concernant le dépôt de quelqu’un d’autre, et une migration ne doit jamais la prendre à votre place.
Deux modes, et la différence réside dans l’emplacement où s’exécute le build. Tous deux aboutissent au même endroit : une référence que nous récupérons et publions, avec le commit enregistré en regard du déploiement.
GitHub ou GitLab, sous Connexions. Les privilèges sont répertoriés avant que vous ne créiez le jeton et celui-ci est vérifié auprès du fournisseur avant d’être stocké.
Propriétaire, dépôt, branche, et si nous publions un répertoire ou récupérons ce que votre CI a compilé. Nous enregistrons le webhook de push dans le cadre de ce processus.
Un push vers la branche désignée démarre un déploiement, ou vous pouvez déployer à la demande depuis l’onglet Déploiement du site. Les builds s’exécutent en arrière-plan.
L’historique des déploiements indique ce qui a été publié et à quel moment. Activez la synchronisation bidirectionnelle pour que les modifications apportées ici soient réintégrées sous forme de commits sur votre branche.
En cas de problème
Une connexion de dépôt qui semble fonctionnelle et ne reçoit rien est l’échec silencieux classique — un jeton avec une portée incorrecte, une livraison bloquée chez le fournisseur, un webhook retiré manuellement. C’est invisible sur tous les autres écrans, la fiche du dépôt l’indique donc directement : la date de la dernière livraison par le fournisseur et le contenu de son message.
Les livraisons font l’objet d’une vérification de signature avant tout traitement, selon le schéma propre à chaque fournisseur et non selon un schéma supposé universel. Une livraison non vérifiée est rejetée et enregistrée, et non ignorée en toute discrétion.
Identité
En plus d’une adresse e-mail et d’un mot de passe, vous pouvez vous connecter à votre compte Zinn Digital® avec GitHub, GitLab, Google ou Microsoft. La couche d’identité effectue l’établissement de liaison (handshake) ; nous ne voyons jamais le mot de passe de votre fournisseur, et l’association d’un compte de réseau social à un compte Zinn® existant doit toujours être confirmée par e-mail.
Se connecter avec GitHub et connecter GitHub pour les déploiements sont des décisions distinctes et des identifiants distincts. Effectuer l’un ne fait pas l’autre, et supprimer l’un ne supprime pas l’autre.
GitHub et GitLab. Associez le compte avec lequel vous travaillez déjà et nous pourrons déployer depuis ses dépôts, y enregistrer un webhook push et — si vous le souhaitez — synchroniser les fichiers de votre site dans l’autre sens. Les deux passent par la même liaison de compte connecté, de sorte que tout ce qui suit s’applique à l’un comme à l’autre.
Oui, et avec Google ou Microsoft. En plus d’une adresse e-mail et d’un mot de passe, vous pouvez vous connecter à votre compte Zinn Digital® avec l’une des quatre options. La couche d’identité gère l’échange initial et nous ne voyons jamais le mot de passe de votre fournisseur. La connexion avec GitHub est distincte de la connexion de GitHub pour les déploiements — vous pouvez faire l’un, l’autre, les deux ou aucun des deux.
Vers Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps ou AWS Amplify pour un site statique ou généré — ou sur notre propre hébergement infogéré, où le dépôt et les fichiers du site restent synchronisés dans les deux sens. Vous choisissez la destination du site ; la connexion au dépôt est identique dans les deux cas.
L’un ou l’autre. En mode publication, nous prenons la branche telle quelle et publions le répertoire que vous indiquez. En mode CI, le pipeline de votre fournisseur exécute votre commande de build et valide la sortie dans une branche de publication distincte, que nous récupérons ensuite comme n’importe quelle autre référence. La seconde option conserve votre build dans votre propre CI, là où se trouvent déjà vos secrets et votre mise en cache.
Par défaut, oui — nous enregistrons un webhook sur le dépôt et un push vers la branche que vous avez désignée déclenche un déploiement. Vous pouvez désactiver cette option et conserver le webhook, ce qui est plus utile qu’il n’y paraît : la livraison est toujours enregistrée, vous pouvez donc observer l’arrivée de vos pushes avant de nous autoriser à agir dessus.
Les modifications effectuées sur notre matériel deviennent des commits sur votre branche, et les commits sur votre branche reviennent sur le site. Cette fonction est désactivée jusqu’à ce que vous l’activiez, car son activation est une décision qui concerne le dépôt de quelqu’un d’autre et nous ne la prendrons pas à votre place. Vous choisissez le répertoire à synchroniser — généralement un thème ou une extension, et non quarante mille fichiers du cœur de WordPress.
Rien n’est écrasé et rien n’est poussé. La synchronisation s’arrête, vous informe que la branche a évolué au-delà du commit sur lequel nous nous basions, et vous demande quel côté vous souhaitez conserver — le dépôt ou le site. Un site qui n’a jamais été synchronisé et qui pointe vers une branche comportant déjà des commits constitue également un état en soi, et le système pose la question plutôt que de deviner où se trouve la vérité.
Nous vous indiquons les privilèges nécessaires à la connexion avant que vous ne la créiez, nous vérifions le jeton auprès de la propre API du fournisseur lors de la saisie — afin qu’un jeton non valide ou dont la portée est incorrecte ne soit jamais stocké — et nous ne l’écrivons dans Vault qu’après cela. Il n’entre jamais en contact avec notre code, un journal, un fichier d’environnement ou une ligne de commande. Révoquez-le auprès du fournisseur ou supprimez la connexion ici, quand vous le souhaitez.
La carte du dépôt indique quand le fournisseur nous a envoyé des données pour la dernière fois et ce qu’il a transmis. La mention « Jamais remis » est le diagnostic le plus utile de cet écran, car l’état « connecté mais jamais remis » correspond exactement à ce à quoi ressemble un jeton dont la portée est incorrecte ou une livraison bloquée — et cela n’apparaît nulle part ailleurs. Chaque livraison fait l’objet d’une vérification de signature avant toute action de notre part.
Cette option est proposée et signalée. GitHub Pages et GitLab Pages partagent l’infrastructure du fournisseur ainsi que les noms d’hôte publics github.io et gitlab.io, ce qui constitue une empreinte pour les moteurs de recherche — précisément ce que cette ligne vise à éviter. Pour un réseau sans aucune empreinte, déployez plutôt sur un hébergement isolé. Partout ailleurs, Pages est de premier ordre.
Parce que son offre gratuite est concédée sous licence pour un usage non commercial uniquement. Nous déduisons une destination à partir des comptes que vous avez connectés lorsque cela est sûr, et Vercel est délibérément exclu de cette déduction — la connexion d’un compte ne doit jamais placer discrètement un site commercial là où sa licence ne le permet pas. Choisissez-le et il fonctionnera exactement comme les autres.
Oui. Chaque déploiement enregistre le commit qu’il a publié, le moment de son exécution et la manière dont il s’est terminé, et l’onglet Déploiement du site affiche l’historique avec l’URL en direct à côté. Les déploiements s’exécutent en arrière-plan, de sorte que la page s’actualise à mesure que la compilation se termine plutôt que de vous faire attendre devant un indicateur de chargement.
Commencez un essai de 14 jours sans carte bancaire, connectez GitHub ou GitLab et pointez un site vers une branche. Publiez sur un hôte Edge ou sur notre propre hébergement avec synchronisation bidirectionnelle des fichiers.
Commencer gratuitement