Motivation et présentation Les aperçus de construction ne sont rien de nouveau ou d'innovant. Heroku les avait depuis des années. Cependant, si vous construisez sur Google Cloud Platform, les choses sont un peu plus difficiles. Google Cloud Build peut être utilisé pour déployer sur Cloud Functions, Cloud Run, Kubernetes, App Engine, etc. etc. C'est ce qui rend les aperçus légèrement compliqués, car Cloud Build ne sait pas où vous déployez votre application ou votre service. Ils ont une application GitHub pour connecter les référentiels et afficher l'état de la construction dans GitHub, mais c'est tout. Pas d'aperçus, de commentaires ou de trucs "normaux" auxquels nous sommes habitués avec des produits comme Heroku, Vercel ou Fly. Il existe un moyen "simple" de publier un commentaire sur une requête d'extraction GitHub à partir de Cloud Build avec une simple requête HTTP. Mais pourquoi facile quand vous pouvez utiliser l' . API GitHub Deployments Avec cette API, vous pouvez créer des environnements, avoir différentes variables par environnement et afficher l'état de construction et de déploiement directement sur une demande d'extraction. Et une fois le déploiement effectué sur votre plate-forme CD, vous pouvez ajouter l'URL à l'état du déploiement. C'est ce que nous allons faire dans cet article. Statut de déploiement GitHub Encore une fois, il existe une autre façon de procéder en utilisant l'API Deployments directement avec les requêtes HTTP. Cela peut parfois être délicat et vous devrez définir un jeton d'accès personnel pour vous authentifier auprès de GitHub. Au lieu de cela, nous avons décidé de créer un petit service Node.js qui utilise GitHub Apps pour générer un jeton d'application et interagir avec l'API Deployments. Cela permet un contrôle un peu plus fin du processus de déploiement. Clause de non-responsabilité Cet article est exclusivement écrit pour Google Cloud Platform et GitHub. Une compréhension de base de Google Cloud Platform, Google Cloud Build et des autorisations IAM est supposée. Vous devez avoir configuré un projet Google Cloud Platform. Déployeur GitHub (Node.js & Docker) GitHub Deployer est un petit service Node.js autorisé avec une application GitHub et interagit avec l'API GitHub Deployments. Les commandes sont prédéfinies et certaines informations doivent être intégrées à l'image Docker, sinon la configuration d'exécution dans Cloud Build deviendrait trop complexe. L'image Docker n'est pas prête à être créée ; vous devrez le construire vous-même et le pousser dans votre registre. Le meilleur endroit est Google Artifact Registry où les images de votre application sont également stockées (Container Registry est obsolète) : Si ce n'est pas déjà fait, créez un dépôt Artifact Registry Créez une application GitHub et installez-la sur votre organisation Créer une application GitHub Autorisations requises : 'pull_requests', 'deployments', 'metadata' Copiez l'ID de l'application (à partir de l'écran Paramètres de l'application) et l'ID d'installation de l'application (après avoir cliqué sur "Configurer", vous trouverez l'ID d'installation dans l'URL. Aucune idée d'où cela peut être trouvé) Créez et téléchargez une clé privée et convertissez-la en base64 ( ) base64 -i your.private-key.pem Créer l'image Docker Source Cloud Build s'exécute sur , nous avons donc besoin pour créer l'image pour la plate-forme x86 : amd64 buildx docker buildx build --platform linux/amd64 . -t us-central1-docker.pkg.dev/[PROJECT]/docker/gh-deployer \ --build-arg GH_APP_ID=[GITHUB_APP_ID] \ --build-arg GH_APP_PRIVATE_KEY=[GITHUB_PRIVATE_KEY_BASE_64] \ --build-arg GH_APP_INSTALLATION_ID=[GITHUB_INSTALLATION_ID] \ --build-arg GH_OWNER=[GITHUB_ORG] Poussez l'image vers votre registre : docker push us-central1-docker.pkg.dev/[PROJECT]/docker/gh-deployer Exécutez l'image Docker localement docker run -it -e REPO_NAME=test -e REF=main -e ENVIRONMENT=test us-central1-docker.pkg.dev/[PROJECT]/docker/gh-deployer:latest create Variables d'environnement requises : : le nom du référentiel (par exemple ) REPO_NAME requis gh-deployer : la branche, la balise ou le SHA à déployer (par exemple, ) REF nécessite main : l'environnement de déploiement (par exemple, ) ENVIRONMENT nécessite preview : si défini sur , le déploiement sera supprimé après un certain temps TRANSIENT_ENVIRONMENT optionnel/false true : une description du déploiement DESCRIPTION facultatif Les commandes suivantes sont disponibles en premier argument : - crée un nouveau déploiement create - la construction est en attente pending - la construction est en cours in_progress - la construction est mise en file d'attente queued - le déploiement a réussi success - quelque chose s'est mal passé error - le déploiement a échoué failure Avec Cloud Build, les options sont actuellement un peu limitées. Il n'y a pas d'état , car Cloud Build doit démarrer pour créer le déploiement initial. n'a pas beaucoup de sens non plus, donc dans notre propre configuration, nous utilisons ce qui suit : pending queued pour créer le déploiement transitoire pour un commit gh-deployer/create directement après la création pgh-deployer/ending Exécutez kaniko build pour créer l'image Docker pour le déploiement une fois la construction terminée et avant le déploiement de l'image gh-deployer/in_progress après le déploiement de l'image gh-deployer/success Encore une fois, avec Cloud Build, nous ne savons pas où se déroulera le déploiement. Il existe donc deux façons de transmettre l'URL de déploiement à l'étape : success Dans une étape de génération, écrivez l'URL dans /workspace/deployer_environment_url Passez un deuxième argument à l'image Docker après success Nous utilisons Cloud Run pour nos déploiements. Voici donc l'étape de compilation permettant de récupérer l'URL de déploiement pour un numéro de demande d'extraction donné : - nom : gcr.io/google.com/cloudsdktool/cloud-sdk env: - PR_NUMBER=$_PR_NUMBER script: >- gcloud run services list --project [project] --filter preview-$PR_NUMBER --format "value(status.address.url)" > /workspace/deployer_environment_url Configuration de la création cloud/Terraform cloudbuild.yaml cloudbuild.yaml Voici un exemple complet utilisant le fichier de configuration . Nous utilisons Kaniko pour compiler et Cloud Run comme cible de déploiement. cloudbuild.yaml Si vous travaillez avec Terraform, un fichier Terraform est également disponible : preview.tf Actions GitHub En utilisant l'API Deployments, vous pouvez déclencher des actions GitHub sur . Cela facilite l'exécution de contrôles d'assurance qualité, de tests de bout en bout, etc. sur chaque version d'aperçu. Voici un exemple d'exécution sur chaque aperçu à l'aide de l' transmise pour l'état : deployment_status de Playwright environment_url success dramaturge-qa : if: ${{ github.event.deployment\_status.state == 'success' }} timeout-minutes: 60 runs-on: ubuntu\-latest steps: \- uses: actions/[\[email protected\]](/cdn-cgi/l/email-protection) \- uses: actions/setup\-[\[email protected\]](/cdn-cgi/l/email-protection) with: node-version: 20 cache: 'npm' \- run: npm ci \- name: Install Playwright Browsers run: npm exec playwright install \-\-with\-deps \-y \- name: Run Playwright tests run: pnpm exec playwright test env: BASE\_URL: ${{github.event.deployment\_status.environment\_url}} \- uses: actions/upload\-[\[email protected\]](/cdn-cgi/l/email-protection) if: always() with: name: playwright\-report path: playwright\-report/ retention-days: 30 Optimisations l'image de base est relativement grande. Vous pouvez pour accélérer les compilations. gcr.io/google.com/cloudsdktool/cloud-sdk créer votre propre petite image gcloud avec des composants Cloud Run Conclusion Statut de déploiement GitHub terminé Les commentaires sur les requêtes d'extraction GitHub sont faciles au début, mais lorsque vous avez plusieurs déploiements par requête d'extraction, des builds défaillants, etc., ils n'offrent pas beaucoup de flexibilité et sont difficiles à maintenir/mettre à jour. L'API GitHub Deployments offre un moyen élégant de créer et de gérer des déploiements à partir de n'importe quel système CI/CD tiers. Avec le nous avons essayé de rationaliser l'interaction avec l'API de déploiement et de prendre en charge certains effets secondaires ou pièges impossibles à résoudre uniquement avec l'API HTTP. GitHub Deployer Un autre avantage de l'utilisation de l'API GitHub Deployments est que vous pouvez utiliser le déclencheur pour les actions GitHub et obtenir l' directement avec la charge utile de l'événement. deployment_status environment_url Vous pouvez trouver des instructions d'installation/construction un peu plus détaillées et tout le code sur le dépôt GitHub , n'hésitez pas / ou . Si vous avez des questions ou des commentaires à nous contacter sur BlueSky Twitter à participer à la discussion sur GitHub Également publié ici.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Developers: Build Less. Deliver More. [Learn how]	

Déploiements GitHub (préversion) avec Google Cloud Platform : un guide essentiel

Trop long; Pour lire

Zentered

STORY’S CREDIBILITY

Guide

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

Déploiements GitHub (préversion) avec Google Cloud Platform : un guide essentiel

Trop long; Pour lire

Zentered

STORY’S CREDIBILITY

Guide

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

HISTOIRES CONNEXES