De Git à la production

La livraison adossée à Git relie une révision source revue à un artefact immuable, puis au cycle de vie d’une ressource Opfield propriétaire. L’intégration de sources prouve ce qui peut être lu, le Build Worker détient l’exécution isolée, le registre stocke l’artefact, et le Container, le Deployment, le projet Compose ou le projet Pages décide si cet artefact atteint les utilisateurs.

La permission de construire un dépôt n’est pas la permission de modifier une Route de production, et un build réussi n’est pas encore un déploiement réussi.

Les builds Git et le déploiement au push pour les Containers, Deployments, projets Compose et Pages nécessitent Business ou Enterprise ; voir Plans et droits.

Avant de commencer, préparez l’intégration de gestion de sources et le Build Worker. Pour un site statique, consultez aussi Déploiements Git de Pages.

Définir la propriété et la politique de publication

Mettez-vous d’accord sur ces décisions avant de connecter des sources de production :

• quelle intégration et quelle identité de dépôt Opfield peut utiliser ;
• quels dépôts et quelles branches figurent sur la liste d’autorisation ;
• qui peut modifier les paramètres de source et les Build Secrets ;
• si les pushes déclenchent automatiquement des builds ;
• si un build approuvé peut être déployé automatiquement ou nécessite une promotion ;
• quelle politique de vulnérabilités bloque un artefact ;
• quelles vérifications précises côté utilisateur définissent un déploiement réussi ;
• qui peut revenir en arrière ou annuler une opération en cours.

Gardez build automatique et déploiement automatique séparés. Le build automatique crée un artefact candidat. Le déploiement automatique modifie une ressource en cours d’exécution ou un tag Pages et comporte donc un risque différent.

Préparer la frontière d’exécution

Configurez une intégration GitLab, GitHub, Git générique ou External SSH prise en charge dans Settings > Integrations. N’accordez au connecteur que l’accès aux dépôts nécessaire pour la découverte et le clonage. N’intégrez pas d’identifiants dans les URL de dépôts.

Enrôlez un Build Worker dédié et vérifiez qu’il est Online et qu’il signale les capacités d’exécution, d’environnement d’exécution dédié et d’application des ressources requises pour l’admission des builds. Un Build Worker utilise des services BuildKit/containerd dédiés et n’expose pas de socket Docker Engine ordinaire au profil de build.

Considérez l’hôte externe du Build Worker ou son conteneur système non privilégié comme la frontière de sécurité. Il traite des entrées contrôlées par le dépôt et ne doit contenir ni charges de travail sans rapport, ni identifiants d’instance cloud, ni clés de déploiement, ni secrets du plan de contrôle. Le profil de trafic sortant configuré doit correspondre au build : le téléchargement de dépendances publiques peut être nécessaire, mais les plages de métadonnées, privées et du plan de contrôle doivent rester interdites.

Connecter la ressource

1. Créez ou ouvrez le Container, le Deployment, le projet Compose ou le projet Pages cible.
2. Sélectionnez le mode Repository et choisissez l’intégration, le dépôt et la branche approuvés.
3. Configurez le contexte de build et le Dockerfile, ou le fichier Compose borné et les champs build pris en charge. Pour Pages, sélectionnez la détection du gestionnaire de paquets, le script de build, la version de Node et le répertoire de l’artefact.
4. N’ajoutez des Build Secrets limités à la source que si le build en a réellement besoin.
5. Décidez séparément du build automatique et du déploiement automatique.
6. Enregistrez la configuration de la source et vérifiez le chemin de dépôt résolu avant de déclencher un candidat de production.

Les Build Secrets sont montés via le mécanisme de secrets de BuildKit et masqués dans les journaux pris en charge. Ce ne sont pas des arguments de build ordinaires, et ils ne doivent jamais être copiés dans ARG, ENV, des fichiers commités, des labels d’image, des URL de gestionnaires de paquets ou une trace du shell. Un secret utilisé pendant le build peut malgré tout fuiter via un Dockerfile malveillant ; la revue du dépôt fait donc partie de la frontière.

Construire et approuver un artefact

Mettez le build en file d’attente et suivez son enregistrement de tâche durable. Examinez :

• la branche résolue et le commit exact ;
• le Build Worker attribué et la plateforme cible ;
• les journaux de build avec le masquage attendu des secrets ;
• les résultats des analyses de vulnérabilités et de la politique ;
• l’empreinte immuable ou l’artefact Pages produit ;
• l’état d’annulation, de relance ou de remplacement ;
• la ressource propriétaire qui consommera l’artefact.

Un build n’est publiable que lorsque sa décision de politique est approuvée et que l’artefact est disponible dans le registre configuré ou dans le flux de déploiement Pages. Ne substituez pas un tag d’image modifiable si une panne de worker ou de registre empêche la création de l’empreinte approuvée.

Comportement des lots Compose

Un fichier Compose de dépôt peut créer un build enfant pour chaque service doté d’une section build prise en charge. Chaque Build Worker exécute un build à la fois ; un projet peut donc être mis en file d’attente séquentiellement lorsque la capacité est limitée.

Opfield attend que chaque artefact enfant attendu soit approuvé avant de créer la révision Compose immuable épinglée par empreinte. Un enfant en échec, refusé, annulé ou remplacé bloque l’ensemble du déploiement. C’est intentionnel : appliquer un mélange d’anciennes et de nouvelles images de services ferait diverger la révision source de la révision d’exécution.

Les réseaux propres à l’exécution et les surcouches des bases de données managées peuvent être ajoutés à la révision déployée sans réécrire la source Compose rédigée. Examinez la révision finale plutôt que de supposer que le fichier source décrit chaque rattachement d’exécution appartenant à Opfield.

Déployer et vérifier

Promouvez l’artefact approuvé via le cycle de vie de son propriétaire :

• un Container utilise une recréation contrôlée ;
• un Deployment utilise son déploiement blue/green contrôlé par des vérifications de santé ;
• un projet Compose crée et applique une révision immuable ;
• un projet Pages crée un Deployment immuable et déplace le tag prévu.

Vérifiez l’empreinte ou le commit déployés, la santé d’exécution, les journaux, la Route publique et toute liaison de base de données. Pour Pages, vérifiez le HTML renvoyé, les ressources statiques, la configuration d’exécution visible côté client et le tag sélectionné. Pour les charges de travail Docker, confirmez que le nœud cible a récupéré l’empreinte approuvée plutôt qu’un tag au nom similaire.

Consignez le dernier artefact réputé sain avant la promotion. Un retour arrière de source doit être explicite : redéployez l’empreinte approuvée précédente ou ramenez le tag Pages en arrière. Reconstruire plus tard la même branche peut produire un candidat différent si les dépendances ont changé ; ce n’est donc pas équivalent à l’utilisation de l’artefact réputé sain.

Défaillance et reprise

La découverte de la source échoue : vérifiez l’autorisation du connecteur, la liste d’autorisation des dépôts, l’existence de la branche et la racine de l’application. N’élargissez pas l’intégration à toute une organisation sans revue.

Aucun worker n’accepte la tâche : vérifiez l’état du worker et les capacités requises, la possibilité d’écrire dans le registre, les droits du plan et la politique de trafic sortant. Les déploiements existants restent valides ; attendez une capacité de build sûre au lieu de contourner le chemin des artefacts immuables.

La politique refuse l’artefact : examinez les constats et le seuil de la politique. Corrigez, ou modifiez explicitement la politique via le processus de sécurité approuvé ; ne réétiquetez pas la même empreinte comme étant de confiance.

Le déploiement échoue après un build réussi : conservez l’enregistrement du build. Diagnostiquez la ressource propriétaire, la vérification de santé, la capacité du nœud, les secrets et les dépendances externes. Un build réussi prouve la création de l’artefact, pas l’exactitude à l’exécution.

La livraison automatique crée un risque : désactivez d’abord le déploiement automatique tout en conservant les builds automatiques s’ils sont utiles. Cela préserve la génération de candidats sans modifier la production à chaque événement de source.

Carte de diagnostic

Symptôme	À vérifier d’abord	Guide détaillé
Le dépôt n’est pas découvert	Autorisation du connecteur, liste d’autorisation des dépôts, branche, racine de l’application	Intégrations de gestion de sources
Le Build Worker n’accepte pas la tâche	État du nœud, capacités, plan, accès en écriture au registre	Sources Git et Build Workers
Le build est refusé	Constats de la politique et seuil bloquant dans l’enregistrement du build	Sources Git et Build Workers
L’artefact existe mais le déploiement échoue	Tâche de déploiement, nœud cible, journaux, vérification de santé	Tâches, événements et audit
L’image ne peut pas être récupérée	Joignabilité du registre, empreinte et identifiants stockés	Registres et confiance des images

Conservez l’identifiant du build, l’identifiant de la tâche, le commit exact et l’erreur avant de réessayer. Un nouveau build peut masquer si le candidat précédent a abouti, échoué ou est encore en cours.