Déclencher un pipeline YAML dans Azure Devop
Je suis nouveau dans le pipeline de build YAML dans Azure Devops et j'essaie de comprendre la fonctionnalité de déclenchement. Ce qui me dérange, c'est que je veux des déclencheurs différents sur différentes branches mais que je veux utiliser le même pipeline.
Disons que je veux
- Construire sur toutes les vérifications sur la branche principale et cela devrait être déployé sur un serveur
- Chaque nuit, je souhaite créer et déployer la branche de développement sur un autre serveur
Je suis confus car le fichier yaml est également archivé dans Git. J'ai lu que si vous avez programmé un déclencheur, vous ne pouvez pas non plus avoir de déclencheur CI.
Dois-je avoir deux fichiers .yml? Un définissant chacun? Cela ne semble pas cool de répéter toutes les étapes
Ou devrais-je avoir une version différente du même fichier dans chaque branche? Cela ne sera-t-il pas fusionné à un moment donné?
Question bonus: que se passe-t-il si vous poussez un pipeline de build sur la branche Developemt avec un déclencheur sur master? (je deviens étourdi)
Vous dites que vous ne pouvez pas avoir de déclencheur programmé et de déclencheur CI mais ce n'est pas vrai. Veuillez consulter la documentation ici .
Si vous souhaitez exécuter votre pipeline en utilisant uniquement des déclencheurs planifiés, vous devez désactiver les déclencheurs PR et d'intégration continue en spécifiant pr: none et trigger: none dans votre fichier YAML. Si vous utilisez Azure Repos Git, les versions PR sont configurées à l'aide de la stratégie de branche et doivent y être désactivées.
Vous avez donc deux options ici:
- Conservez tout cela dans un fichier YAML et vérifiez quelle branche ou comment la construction a été déclenchée pour effectuer le déploiement sur un serveur approprié
- Vous pouvez avoir deux builds mais pour éviter de vous répéter, extrayez des éléments communs dans le template et réutilisez-les dans la définition de build (donc en fait, dans ce cas, vous allez avoir 3 fichiers yaml).
Quelques exemples:
- vous souhaitez exécuter un travail uniquement pour la branche principale:
jobs:
- job: A
steps:
- script: echo hello
- job: B
dependsOn: A
condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/master'))
steps:
- script: echo this only runs for master
- vous souhaitez extraire les étapes courantes et les réutiliser dans une définition de build
Étapes courantes:
# File: simple-param.yml
parameters:
- name: yesNo # name of the parameter; required
type: boolean # data type of the parameter; required
default: false
steps:
- script: echo ${{ parameters.yesNo }}
Définition de la construction:
# File: Azure-pipelines.yml
trigger:
- master
extends:
template: simple-param.yml
parameters:
yesNo: false # set to a non-boolean value to have the build fail
Vous pouvez lire sur les modèles dans la documentation ou vérifier l'exemple sur mon article de blog .
Si vous souhaitez disposer de pipelines de version classiques, vous devez définir deux pipelines de version avec un déclencheur vers une branche spécifique.
Pour résumer: vous pouvez faire ce que vous voulez et vous disposez de plusieurs moyens pour y parvenir. Ma recommandation personnelle est d'utiliser des pipelines séparés avec un modèle car cela rend la définition de construction plus propre que la condition pour vérifier quelle branche ou comment la construction a été déclenchée.
Dans cette variable Build.Reason vous pouvez vérifier comment votre branche a été déclenchée:
- Manuel: un utilisateur a mis manuellement la compilation en file d'attente.
- IndividualCI: intégration continue (CI) déclenchée par un Git Push ou un check-in TFVC.
- BatchedCI: intégration continue (CI) déclenchée par un Git Push ou un check-in TFVC, et les modifications par lots ont été sélectionnées.
- Planification: déclenchement planifié. ValidateShelveset: un utilisateur a mis manuellement en file d'attente la construction d'un plateau TFVC spécifique.
- CheckInShelveset: déclencheur d'enregistrement fermé.
- PullRequest: la construction a été déclenchée par une stratégie de branche Git qui nécessite une construction.
- BuildCompletion: la build a été déclenchée par une autre build.
- ResourceTrigger: la génération a été déclenchée par un déclencheur de ressource.
Vous pouvez alors utiliser cette variable en condition. Pour plus d'informations, veuillez consulter ici .
En terminant, sachez qu'il existe un type spécial de job appelé deployment pour les déploiements. Veuillez envisager de l'utiliser si vous allez déployer votre application à l'aide du pipeline yaml.
Pour votre question bonus: vous pouvez remplacer les paramètres de votre build. Je veux dire que vous pouvez avoir un déclencheur pour le maître et uniquement pour le maître. Mais vous pouvez toujours exécuter votre build pour d'autres branches (comme la branche de développement) (par exemple par exécution manuelle). Que se passe-t-il alors? Build s'exécutera pour la branche nouvellement définie. À la fin, il s'agit de la définition de la construction et du déclenchement du contrôle des exécutions automatiques de la construction.
Dois-je avoir deux fichiers .yml? Un définissant chacun? Cela ne semble pas cool de répéter toutes les étapes
Après une période de recherche, je vous recommande personnellement d'en utiliser deux .yml fichiers avec différents pipelines de construction.
La question la plus directe est que le code sur la branche master et la branche development n'est pas synchronisé en temps réel. Lorsque le code sur les deux branches est différent, les résultats de la génération sont différents. S'ils sont dans le même pipeline, nous devons manuellement vérifier de quelle branche l'erreur provient lorsque la construction a échoué. C'est une chose douloureuse.
Un autre problème profond est que nous pourrions définir le CI trigger et Scheduled trigger dans un fichier yaml, comme:
trigger:
branches:
include:
- master
schedules:
- cron: "* 10 * * *"
always: true
displayName: Daily midnight build (UTC 22:00)
branches:
include:
- Development
Pour y parvenir, nous devons définir ce yaml sur la branche Development. Si nous modifions un code dans la branche principale, cela déclenchera ce pipeline. Cependant , il ne construit le code que sur la branche Development, il n'inclut pas les modifications code dans le maître . Donc, ce déclencheur CI n'aura aucun sens.
dois-je avoir une version différente du même fichier dans chaque branche? Cela ne sera-t-il pas fusionné à un moment donné?
Je vous recommande personnellement de mieux utiliser différents fichiers yaml avec un nom différent. Comme vous l'avez dit, les mêmes fichiers sont sujets à des risques inutiles lors de la fusion ultérieure de branches.
Ma question bonus était plutôt: Êtes-vous supposé conserver une version différente de votre pipeline de build dans différentes branches? Je veux dire que si je veux créer une branche de développement à chaque fois que je pousse pour développer, ce déclencheur peut-il être défini dans la version de la branche principale du fichier yaml?
La réponse est oui. Vous pouvez définir les déclencheurs CI avec une syntaxe simple dans la version de la branche master du fichier yaml:
trigger:
branches:
include:
- master
- Development
Avec ces paramètres, chaque fois que vous pousserez pour développer une branche, vous déclencherez une construction définie dans la version de la branche principale du fichier yaml.
Remarque: Pour votre question bonus, si nous définissons ci-dessus les déclencheurs CI, le pipeline déclenchera une construction en raison de commits continus sur la branche dev. Parfois, nous modifions simplement un fichier readme, nous ne voulons pas qu'une telle modification déclenche des constructions inutiles, la meilleure façon de résoudre de tels problèmes est d'utiliser déclencheur PR.
J'espère que cela t'aides.