web-dev-qa-db-fra.com

Emploi Pipeline Multibranch vs Pipeline

Maintenant que le type de travail Pipeline multibranches a mûri, existe-t-il une raison d'utiliser le type de travail Pipeline simple? Même si vous n’avez qu’une branche aujourd’hui, il est probablement sage de prendre en compte la possibilité de créer plusieurs branches à l’avenir. Quelle est donc la motivation qui pousse à utiliser le type de travail Pipeline pour votre pipeline Jenkins par rapport à l’utilisation systématique du type de travail Multibranch Pipeline, en supposant que vous stockiez votre fichier Jenkins dans SCM? Existe-t-il une parité des fonctionnalités entre les deux types de tâches maintenant?

jenkinsjenkins-pipeline
14
Neil

D'après mon expérience des pipelines multibranches, le SEUL inconvénient est que vous ne pouvez pas voir les dernières colonnes succès/échec/durée sur la page principale de Jenkins. Ils affichent simplement "NA" sur la page d'accueil de Jenkins puisqu'il s'agit techniquement d'un "dossier" de sous-travaux. 

Autre que cela, je ne peux penser à aucun autre "contre" à l'utilisation de multibranches. 

Je ne suis pas d’accord avec l’autre réponse… dans ce cas, c’est que la multibranche envoie des modifications pour «n’importe quelle» branche. Ce n'est pas nécessairement vrai. Si un fichier Jenkins existe sur une branche de caractéristiques aléatoire, mais que cette branche n'est pas définie dans le pipeline, vous pouvez simplement ne rien utiliser avec les conditions if/else habituelles.

Par exemple:  

node {
  checkout scm
  def workspace = pwd()

  if (env.BRANCH_NAME == 'master') {
    stage ('Some Stage 1 for master') {
      sh 'do something'
    }
    stage ('Another Stage for Master') {
      sh 'do something else here'
    }
  }

  else if (env.BRANCH_NAME == 'stage') {
    stage ('Some stage branch step') {
      sh 'do something'
    }
    stage ('Deploy to stage target') {
      sh 'do something else'
    }
  }

  else {
    sh 'echo "Branch not applicable to Jenkins... do nothing"'
  }
}
4
emmdee

Dans une situation de CI/CD, il peut ne pas être souhaitable d’envoyer chaque branche à l’environnement cible. L'utilisation de pipeline et la spécification d'une seule branche vous permettraient de filtrer et d'envoyer uniquement/maître aux environnements de transfert ou de production. Multibranch serait utile pour envoyer tout changement sur une branche spécifique à un environnement de test. 

D'autre part, si le processus d'assurance qualité/automatisation est suffisamment approfondi, le risque lié à l'envoi d'une succursale à la production pourrait être acceptable.

3
tommy tom

Multibranch Pipeline fonctionne bien si votre travail Jenkins traite d’un seul référentiel git. D'autre part, le travail en pipeline peut être neutre vis-à-vis d'un référentiel, d'une branche neutre et très flexible lorsque vous travaillez avec plusieurs référentiels git avec un seul travail Jenkins. 

Par exemple, supposons que vous avez l'artefact-1 de repo-1, l'artefact-2 de repo-2 et des tests d'intégration de repo-3. Et l'artefact-2 dépend de l'artefact-1. Un travail Jenkins doit créer l'artefact-1, puis l'artefact-2 et enfin exécuter des tests d'intégration à partir de repo-3. Et supposez que votre changement de code aille dans une branche feature-1 de repo-1 et une branche feature-1 pour de nouveaux tests dans le repo-3. Dans ce cas, le travail Jenkins crée feature-1 pour artefact-1, puis utilise la branche "dev" par défaut de repo-2 (si feature-1 n'est pas détectée dans le repo-2) et exécute "feature-1" à partir de repo-3 pour les nouveaux tests d'intégration. Comme vous pouvez le constater, le travail fonctionne bien avec trois référentiels git. Un travail de pipeline avec référentiel neutre/branche neutre est idéal dans ce contexte. 

1
nick w.