Paramètres de projet Orbit

Tous les réglages d'un projet Orbit se trouvent dans l'onglet Paramètres, organisés par catégorie pour faciliter la navigation : informations générales, compilation et déploiement, sécurité, notifications, intégrations, limites d'utilisation, automatisation du déploiement, mise en réseau, observabilité, partage, et une zone de danger en bas de page.

Où se trouvent les paramètres

Ouvrez Orbit, cliquez sur le projet, puis choisissez Paramètres dans la bande d'onglets du projet. La page se décrit comme la configuration du nom de votre projet, des commandes de compilation et de l'intégration Git, ce qui est loin de tout décrire.

Ce guide est une carte. Là où un sujet possède son propre article, il est lié plutôt que répété.

Général

Informations du projet affiche le slug de l'URL, la date de création, le référentiel connecté et l'URL de production, et vous permet de modifier le Nom et la Description du projet.

Git contient la Branche de production. Les poussées vers cette branche déclenchent des déploiements de production.

Badge de statut vous donne un SVG de statut de déploiement en direct avec des boutons de copie pour l'URL, le markdown et le HTML, prêts à être collés dans votre README. Voir Viewing Your Project README In Orbit.

Page de statut publique renvoie à la configuration de la page de statut. Voir Orbit Status Page.

Compilation et déploiement

Paramètres de compilation sont les cinq champs qu'Orbit détecte automatiquement et que vous pouvez remplacer : commande d'installation, commande de compilation, répertoire de sortie, répertoire racine et version de Node.js. Laissez un champ vide pour conserver la valeur détectée. Les détails complets se trouvent dans Configuring Your Build Command and Output Directory.

Runtime comporte quatre commutateurs à comprendre :

• Mode serveur garde la machine de compilation active en exécutant votre commande de démarrage après chaque déploiement. Requis pour tout ce qui s'affiche sur le serveur plutôt que d'exporter des fichiers statiques.
• Aperçus des branches créent automatiquement un environnement pour chaque poussée de branche qui n'est pas la production ou la staging, chacun sur sa propre URL sous branch-*.kaps.run. Voir Branch Previews.
• Restauration automatique en cas d'échec restaure le dernier déploiement de production sain si un déploiement échoue.
• Reconstruction programmée reconstruit la production à intervalle régulier, de chaque heure à chaque semaine, ce qui convient aux sites gérés par contenu qui ont besoin d'une actualisation sans poussée git.

Nouvelle tentative automatique de compilation place à nouveau en file d'attente les compilations qui ont échoué en raison d'erreurs d'infrastructure telles qu'un problème réseau ou un délai d'attente, jusqu'à trois fois. Il ne réessaie pas les erreurs de code, il ne peut donc pas masquer une compilation cassée.

Chemins ignorés et Modèles d'ignorance de branche arrêtent les compilations dont vous n'avez pas besoin : modèles glob pour les fichiers dont les modifications ne doivent pas être déployées, et pour les branches comme dependabot/* qui ne doivent jamais en déclencher une.

Déploiements de balises Git définit le modèle de balise qui transforme une poussée de balise en déploiement de production. Voir Orbit Releases.

Automatisation et protection du déploiement

Protection du déploiement a deux contrôles : Exiger une approbation pour la production, qui pause les déploiements de production déclenchés par une poussée jusqu'à ce que quelqu'un approuve, et Exiger le succès de la staging avant la production, qui maintient la production jusqu'à ce que la staging ait déployé le même commit avec succès.

Contrôles CI requis assujettit les déploiements à votre propre CI. Sur GitHub, vous listez les noms de travaux, qui doivent tous réussir ; sur GitLab, toute valeur non vide attend l'ensemble du pipeline. Un échec CI annule le déploiement.

Calendrier de gel du déploiement bloque les déploiements déclenchés par une poussée en dehors des fenêtres approuvées, soit les week-ends, soit une plage horaire UTC. Les déploiements manuels et les crochets de déploiement ne sont pas affectés.

Protection de branche ajoute des règles de modèle glob qui bloquent les déploiements sur les branches correspondantes jusqu'à ce que les contrôles externes requis réussissent et, éventuellement, qu'un humain approuve.

Promotion automatique de staging promeut la staging à la production automatiquement une fois qu'elle a fonctionné pendant un nombre d'heures configuré sans défaillances de santé et avec les tests de fumée réussis.

Tous ces éléments sont résumés en une seule vue dans l'onglet Orbit Deployment Pipeline.

Portes de santé et de qualité

Contrôle de santé récupère un chemin de votre choix après chaque déploiement de production. Une réponse non-2xx dans les 15 secondes restaure le déploiement précédent sain.

Tests de fumée exécutent des requêtes GET contre jusqu'à dix chemins séparés par des virgules après chaque déploiement réussi et enregistrent réussi ou échoué. Combiné à la restauration automatique, un test de fumée échoué annule le déploiement.

Budgets de performance avertissent ou font échouer les compilations qui dépassent un seuil : taille totale des artefacts en Mo, taille de fichier individuelle en Ko correspondant à un glob, ou temps de compilation en secondes. Chaque budget est défini pour avertir ou faire échouer la compilation.

Staging

Staging a son propre ensemble de cartes : la branche de staging, la protection d'accès avec un mot de passe, une liste blanche d'IP acceptant les adresses IPv4 et les plages CIDR une par ligne, la restauration automatique en cas d'échec, si le staging hérite des variables d'environnement de production à priorité inférieure, et les remplacements de compilation pour l'installation, la compilation, la sortie et le répertoire racine.

Le mot de passe et la liste blanche d'IP sont les deux à définir sur n'importe quel environnement de staging qui n'est pas destiné à être public. Laissez les deux vides et l'URL de staging est accessible par quiconque l'a.

Mise en réseau

Domaines personnalisés ajoute et vérifie les domaines pour l'environnement de production, y compris la fourniture de certificats. Voir Adding a Custom Domain to Orbit.

Redirections et réécritures sont des règles basées sur le chemin appliquées avant la diffusion, testées dans l'ordre avec première correspondance gagnante. Une redirection envoie le navigateur à une nouvelle URL en tant que 301 ou 302 ; une réécriture diffuse silencieusement un chemin différent sans changement d'URL. Les modèles prennent en charge les correspondances exactes, les caractères de remplissage, les paramètres nommés et les éclats. Voir Redirects and Rewrites in Orbit.

En-têtes de réponse appliquent des en-têtes HTTP personnalisés aux chemins correspondants, avec des présets pour HSTS, CSP, no-embed, no-sniff, politique de référent et CORS. Toutes les règles correspondantes sont appliquées, et les entrées ultérieures écrasent les entrées antérieures pour la même clé.

Protection contre le décalage conserve les anciens artefacts de compilation dans le stockage pendant une fenêtre de rétention après le déploiement d'une nouvelle version, de sorte qu'un visiteur qui a chargé la version précédente peut toujours récupérer ses actifs au lieu d'obtenir un 404.

Le magasin de configuration contient les paramètres clé/valeur que votre déploiement lit au runtime, pour les indicateurs de fonctionnalité et les paramètres qui changent sans un redéploiement. Il est géré sous Stockage, pas ici, et c'est gratuit : aucun frais de lecture et aucun frais d'écriture. Les valeurs sont stockées en texte brut, ne mettez donc jamais de secret dedans. Jusqu'à 100 entrées par projet, clés jusqu'à 200 caractères et valeurs jusqu'à 4096. Un instantané nocturne de chaque entrée est pris et trente nuits sont conservées sur tous les plans, donc une entrée que vous supprimez peut être restaurée : voir Snapshots and restore.

Utilisation et limites

Utilisation de la compilation affiche les compilations que ce projet a exécutées.

Plafond de dépenses définit les dépenses mensuelles supplémentaires maximales, couvrant les dépassements de minutes de compilation et de bande passante au-delà de votre allocation de plan. Le minimum est US$6.32 et le maximum US$6,315.79. Les alertes se déclenchent à 50 % et 80 %, et à 100 %, la diffusion s'interrompt jusqu'à ce que vous augmentiez le plafond. Voir Orbit Spending Cap.

Plafond de dépenses de compilation est la limite séparée et plus brutale : un plafond mensuel sur le total des minutes de compilation, après lequel les nouvelles compilations arrêtent de se mettre en file d'attente jusqu'au mois prochain ou vous augmentez le plafond.

Rétention des artefacts définit le nombre d'artefacts de compilation réussis à conserver par environnement. Les anciens sont supprimés quotidiennement, et le déploiement actuellement en direct est toujours conservé indépendamment de la limite.

Expiration de l'aperçu met en pause les environnements d'aperçu après 7, 14, 30 ou 60 jours, ou jamais. Les aperçus en pause ont leur stockage réclamé dans les 24 heures.

Alerte de taille d'artefact vous envoie un e-mail quand un artefact de compilation dépasse une taille que vous avez définie.

Notifications, intégrations et observabilité

Notifications par e-mail de déploiement a trois paramètres : tous les déploiements, les défaillances uniquement, ou désactivé. Une URL de webhook de notification peut être définie à côté, affichant à chaque succès ou défaillance.

Canaux de notification est la version plus riche, avec sélection par événement, historique de livraison et un bouton de test. Le contrôle complet du webhook se trouve sur son propre onglet : voir Orbit Webhooks.

Crochets de déploiement crée des URL secrètes qui déclenchent un déploiement quand quelque chose les poste. Voir Triggering Deployments Via Deploy Hooks.

Drains de journal envoient les journaux de compilation à votre plateforme d'observabilité après chaque déploiement, avec support intégré pour Datadog, Logtail, Axiom et New Relic, ou un webhook personnalisé, filtré éventuellement à un environnement.

Analytique Web vous donne l'extrait de collection Core Web Vitals. Voir Orbit Web Vitals.

Déclencheurs Cron planifie les requêtes HTTP à un environnement choisi, jusqu'à dix par projet. La version plus grande réservée à la production est sur son propre onglet : voir Orbit Cron Jobs.

Partage et équipe

Équipe gère les collaborateurs avec trois rôles : administrateur, développeur et lecteur.

Liens de partage génèrent des liens temporaires sans mot de passe afin qu'un examinateur externe puisse voir un environnement sans mot de passe ni compte. Chaque lien peut expirer en 1 heure, 24 heures ou 7 jours, ou jamais, et affiche son nombre de visites. Révoquez-en un à tout moment.

Groupe de déploiement joint ce projet à un groupe afin que les projets connexes se déploient ensemble, filtré éventuellement par branche.

Cloner l'environnement et Cloner le projet dupliquent la configuration. Le clonage d'un projet copie les paramètres de compilation, la configuration de l'environnement et les variables d'environnement non secrètes ; les secrets ne sont pas copiés.

Zone de danger

Effacer le cache de compilation supprime les dépendances en cache pour chaque environnement, de sorte que le déploiement suivant exécute une installation complète à partir de zéro. Il ne peut pas être annulé, bien que le cache se reconstruit lui-même lors de la prochaine compilation.

Transférer le projet déplace le projet vers un autre compte Kapsule. Voir Transferring an Orbit Project.

Archiver le projet arrête immédiatement la diffusion du trafic. Il est restorable dans les 30 jours à partir de la liste Orbit, après quoi il est définitivement supprimé.

Où aller ensuite

• Orbit Deployment Pipeline pour voir l'effet de chaque paramètre en une seule vue.
• Shared Environment Variable Groups pour les valeurs utilisées dans tous les projets.
• Orbit Plan Limits pour ce que votre plan permet.