nocodb/scripts/docs/fr/150.engineering/fr-060.builds-and-releases.md

---

titre : "Versions et builds" description : "NocoDB crée Docker et des binaires pour chaque PR" balises : ['Ingénierie']

Constructions de NocoDB

Il existe 3 types de builds Docker dans NocoDB

• Versions de publicationnocodb/nocodb: construit lors de la version NocoDB.
• Constructions quotidiennesnocodb/nocodb-daily: construit toutes les 6 heures à partir de la branche Develop.
• Constructions en temps opportunnocodb/nocodb-timely: construit pour chaque PR et PR déclenchés manuellement.

Vous trouverez ci-dessous un aperçu de la façon de réaliser ces builds et de ce qui se passe dans les coulisses.

Versions de publication

Comment faire un build de release ?

• Cliquez surAction de publication de NocoDB

• Vous devriez voir l'écran ci-dessous

  

• ChangementUse workflow fromàBranch: master. Si vous choisissez la mauvaise branche, le workflow sera terminé.

  

• Il y aurait alors deux cas : vous pouvez soit laisser la balise cible et la balise précédente vides, soit saisir manuellement une valeur.

• La balise cible signifie la version de déploiement cible, tandis que la balise précédente signifie la dernière version à ce jour. La balise précédente est utilisée uniquement pour la note de version - affichant les différences de fichier/validation entre deux balises.

Marquage

La convention de dénomination suivrait étant donné que la balise de version réelle est0.100.0

• 0.100.0-beta.0(première version de la pré-version)
• 0.100.0-beta.1(inclure les modifications de correction de bogues en plus de la version précédente)
• 0.100.0-beta.2(inclure les modifications de correction de bogues en plus de la version précédente)
• et ainsi de suite ...
• 0.100.0(version réelle)
• 0.100.1(version de correction de bug mineur)
• 0.100.2(version de correction de bug mineur)

Cas 1 : laisser les entrées vides

• Si la balise précédente est vide, la valeur sera récupérée à partir dedernier
• Si la balise cible est vide, la valeur sera la balise précédente plus un. Exemple : 0.90.11 (balise précédente) + 0.0.1 = 0.90.12 (balise cible)

Cas 2 : saisie manuelle

Pourquoi? Parfois, nous pouvons gâcher le déploiement de NPM. Comme NPM ne nous permet pas de redéployer à nouveau vers la même balise, dans ce cas, nous ne pouvons pas simplement utiliser la balise précédente + 1. Par conséquent, nous devons plutôt utiliser la balise précédente + 2 et nous la configurons manuellement.

• Après cela, cliquezRun workflowcommencer
• Vous pouvez voir le résumé pour l'état global du travail.
• Une foisrelease-draft-noteetrelease-executablesest terminé, alors allez àsorties, modifiez le brouillon de note et enregistrez-le en tant que brouillon pour le moment.
  • Exemple : ajout d'un en-tête, mettez à jour le contenu si nécessaire et cliquez surAuto-generate release notespour inclure plus d'informations.
• Une foisrelease-dockerest terminé, puis testez-le d'abord localement. On s'attendra à ce que vous voyiezUpgrade Availablenotification dans l'interface utilisateur car nous n'avons pas publié la note de version. (la version est récupérée à partir de là)
• Une fois que tout est terminé, publiez alors la release note et le déploiement est considéré comme TERMINÉ.

Comment fonctionne l'action de libération ?

valider la branche

Pour vérifier sigithub.refest maître. A défaut, les autres succursales ne seront pas acceptées.

entrée de processus

Pour enrichir la balise cible ou la balise précédente si nécessaire.

pr-à-master

Automatisez un PR de la branche de développement à la branche principale afin que nous connaissions les différences réelles entre la balise précédente et la balise actuelle. Nous choisissons la branche master pour une base de déploiement.

version-npm

Créez le frontend et le backend et publiez-les sur NPM. Les modifications lors de la construction, telles que le changement de version, seront validées et poussées vers une branche temporaire et un PR automatisé sera créé et fusionné avec la branche principale.

Notez qu'une fois que vous publiez avec une certaine balise, vous ne pouvez plus publier avec la même balise.

version-projet-note

Générez un brouillon de note de version. Certaines actions doivent être effectuées après cette étape.

version-docker

Créez une image Docker et publiez-la sur Docker Hub. Cela peut prendre environ 15 à 30 minutes.

problèmes clôturés

Problèmes ouverts marqués d'une étiquetteStatus: FixedetStatus: Resolvedsera fermé automatiquement par le bot avec un commentaire mentionnant que le correctif est inclus dans quelle version.

Exemple:

publier des documents

Publish Documentation

chemin de mise à jour du SDK

nocodb-sdkest utilisé en frontend et backend. Cependant, dans la branche de développement, la valeur seraitfile:../nocodb-sdkà des fins de développement (afin que les modifications apportées dans nocodb-sdk en développement soient incluses dans le frontend et le backend). Lors du déploiement, la valeur sera remplacée par la balise cible. Ce travail consiste à les mettre à jour.

synchronisation pour développer

Une fois le déploiement terminé, de nouvelles modifications seront apportées à la branche master. Ce travail consiste à synchroniser les modifications à développer afin que les deux branches n'aient aucune différence.

Constructions quotidiennes

Que sont les builds quotidiens ?

• NocoDB crée toutes les 6 heures à partir des branches de développement et publie sous nocodb/nocodb-daily
• Ceci afin que nous puissions facilement essayer ce qui se trouve dans la branche de développement.

Images Docker

• Les images Docker seront créées et poussées vers Docker Hub (voirnocodb/nocodb-dailypour la liste complète).

Constructions en temps opportun

Que sont les builds opportuns ?

NocoDB a des actions github qui créent un docker et des binaires pour chaque PR ! Et ceux-ci peuvent être trouvés sous forme decommenter le dernier commitdu PR.

Exemple ci-dessous

• Accédez à un PR et cliquez sur le commentaire.

• Cliquez sur le lien pour copier l'image du docker et l'exécuter localement.

C'est pour

• réduire le temps de cycle des demandes d'extraction
• permettre aux rapporteurs/réviseurs de problèmes de vérifier le correctif sans configurer leurs machines locales

Images Docker

Lorsqu'une demande d'extraction non brouillon est créée, rouverte ou synchronisée, une construction en temps opportun pour Docker serait déclenchée pour les modifications incluses uniquement dans les chemins suivants.

• packages/nocodb-sdk/**
• packages/nc-gui/**
• packages/nc-plugin/**
• packages/nocodb/**

Les images Docker seront créées et poussées vers Docker Hub (voirnocodb/nocodb-timelypour la liste complète). Une fois l'image prête, le bot GitHub ajoutera un commentaire avec la commande dans la pull request. L'étiquette serait<NOCODB_CURRENT_VERSION>-pr-<PR_NUMBER>-<YYYYMMDD>-<HHMM>.

Exécutables ou binaires

De même, nous fournissons une version en temps opportun des exécutables pour les utilisateurs non-Docker. Le code source sera construit, conditionné sous forme de fichiers binaires et transféré vers GitHub (voirnocodb/nocodb-timelypour la liste complète).

Actuellement, nous prenons uniquement en charge les cibles suivantes :

• node16-linux-arm64
• node16-macos-arm64
• node16-win-arm64
• node16-linux-x64
• node16-macos-x64
• node16-win-x64

Une fois les exécutables prêts, le bot GitHub ajoutera un commentaire avec les commandes dans la pull request.

NocoDB crée Docker et Binaries pour chaque PR.

C'est pour

• réduire le temps de cycle des demandes d'extraction
• permettre aux rapporteurs/réviseurs de problèmes de vérifier le correctif sans configurer leurs machines locales