Versions d'Orbit

The Releases tab turns your git tags into a version history you can read: every tagged deployment, in order, with its commit, its author, its status and a link straight to the tag in your repository.

L'onglet Releases transforme vos balises git en un historique de versions que vous pouvez consulter: chaque déploiement balisé, dans l'ordre, avec son commit, son auteur, son statut et un lien direct vers la balise dans votre dépôt.

Où se trouve Releases

Ouvrez Orbit, cliquez sur le projet, et choisissez Releases sous le groupe Deployments dans la bande d'onglets du projet. La page s'intitule Releases et se décrit comme des déploiements basés sur des balises: une release est créée quand une balise git correspond à votre motif de balise.

L'onglet voisin Deployments répertorie chaque build, balisé ou non. Releases est la vue filtrée: uniquement ceux que vous avez marqués comme version.

Définir le motif de balise

Les releases commencent par un motif. Ouvrez Settings, trouvez la carte Git tag deploys, et entrez un glob tel que v* ou release-*. Le laisser vide désactive entièrement les déploiements par balise, c'est pourquoi l'espace réservé du champ indique v* (disabled).

Avec un motif défini, pousser une balise correspondante déploie en production et enregistre le résultat comme une release. Sans un, l'onglet Releases affiche un état vide vous invitant à pousser une balise et à définir un motif dans Settings.

Un motif de balise vous donne un second chemin explicite vers la production en parallèle des poussées vers la branche de production. Les équipes qui veulent que les déploiements soient un acte délibéré plutôt qu'un effet secondaire de la fusion désactivent souvent le déploiement automatique des branches et pilotent la production à partir des balises uniquement.

Créer une Release

Le flux entier de votre côté est deux commandes git:

git tag -a v1.4.0 -m "Checkout flow rebuild"
git push origin v1.4.0

Orbit reçoit la balise, la fait correspondre à votre motif, déploie le commit balisé en production, et enregistre une release. Elle apparaît sur cet onglet avec un badge Building et passe à Deployed quand elle arrive, ou Failed si la build a échoué.

Utilisez des balises annotées plutôt que des balises légères. Une balise annotée porte un message, un auteur et une date, qui finissent tous par apparaître sur la release.

Baliser un Déploiement Existant

Vous n'avez pas à pousser une balise git pour obtenir une release. Tout déploiement peut être balisé à partir de sa page de détail, et une balise qui ressemble à un numéro de version est repérée ici.

Une balise en forme de version est une comme 1.4, 1.4.0, v1.4.0 ou v2.0.0-rc1. Tout le reste reste comme une simple balise de déploiement et ne crée pas d'entrée de release.

C'est l'échappatoire pour le cas où une release est sortie avant que vous configuriez le motif, ou où un hotfix a été déployé manuellement et que vous le voulez dans l'historique de version de toute façon.

Lire une Release

Chaque ligne de release affiche:

La balise, comme titre de la release.
Le commit et son message.
L'auteur, affiché comme by name.
L'environnement vers lequel elle s'est déroulée, codé par couleur selon le type.
Un badge de statut: Deployed, Building ou Failed.
Un lien View on vers la balise dans votre dépôt.
Un lien vers le déploiement sous-jacent.

Le lien View on pointe au bon endroit par fournisseur: la page des releases sur GitHub, la page de balise sur GitLab, ou la source à cette balise sur Bitbucket.

Notes de Release

Si vous publiez une release dans votre dépôt pour une balise, les notes sont tirées et attachées au déploiement, de sorte que l'onglet Releases porte le même texte que vous avez écrit dans votre dépôt plutôt que de vous obliger à conserver deux copies.

Cela fait du dépôt le seul endroit où écrire les notes de release. Écrivez-les une fois, où vos contributeurs sont déjà, et elles apparaissent ici.

Une Release Par Balise

La liste est dédupliquée par balise: si une balise a été déployée plus d'une fois, par exemple parce que la première build a échoué et que vous avez réessayé, seul le déploiement le plus récent pour cette balise est affiché.

Le compteur en haut donne le total, et la liste couvre une fenêtre généreuse de déploiements balisés récents plutôt que tout l'historique du projet.

Bien Utiliser les Releases

Balisez à la fusion, pas sur la branche. Balisez le commit qui est réellement sur votre branche de production. Baliser un commit de branche de fonctionnalité qui n'a pas été fusionné produit une release qui ne correspond à rien sur main.

Utilisez les versions sémantiques. Elles trient correctement, elles sont reconnues comme en forme de version, et tout le monde sait déjà comment les lire.

Ne déplacez jamais une balise. Re-pointer une balise existante vers un nouveau commit signifie que la release dans cette liste et la balise dans votre dépôt ne s'accordent maintenant sur ce qui a été expédié. Coupez plutôt une nouvelle version de patch.

Une poussée de balise se déploie directement en production si elle correspond à votre motif. Cela ne contourne rien d'autre: les verrous de déploiement, les exigences d'approbation et les fenêtres de gel s'appliquent toujours selon la configuration. Mais cela signifie qu'une balise poussée par erreur est un déploiement en production, pas un brouillon. Voir Deploying Your Project pour les portes disponibles.

Annuler une Release

Les releases sont des déploiements, donc en annuler une est le flux de rollback ordinaire: ouvrez le déploiement et restaurez le précédent réussi. Voir Rolling Back a Deployment.

Après, coupez une nouvelle balise pour le correctif plutôt que de supprimer la mauvaise. La release échouée restant visible dans l'historique est une information utile, pas du désordre.

Dépannage

Une balise a été poussée mais aucune release n'est apparue. Vérifiez le motif dans Settings, puis vérifiez que la balise a réellement atteint le serveur distant. git push origin v1.4.0 pousse une balise; git push seul n'en pousse aucune.

La release affiche Failed. La build a échoué, exactement comme elle le ferait pour une poussée de branche. Ouvrez le déploiement et lisez le journal: Reading Build Logs.

Le lien View on est manquant. Le projet n'a pas de dépôt connecté, il n'y a donc nulle part où créer un lien. Connectez-en un: voir Connecting a GitHub Repository.

Un déploiement balisé manuellement n'est pas répertorié. La balise n'est pas en forme de version. Renommez-la en quelque chose comme v1.4.0.

Les notes de release sont vides. Les notes sont tirées d'une release publiée dans votre dépôt. Une simple balise sans objet de release n'a pas de notes à tirer.

Où aller ensuite

Deploying Your Project pour le cycle de déploiement complet et ses portes.
Rolling Back a Deployment quand une release tourne mal.
Orbit Timeline Annotations pour enregistrer ce qu'une release a changé.