Quelle est la différence entre Pipeline et Release Pipeline dans les devops azur?


14

Un fichier yaml est généré lorsque vous choisissez cette option ci-dessous:

entrez la description de l'image ici

Dans ce fichier yaml, vous pouvez définir un cycle de déploiement complet à partir de restore -> build -> run tests -> publish and -> deploy to azure app service web app.

alors, pourquoi y a-t-il l'option des versions? Si je peux définir un cycle de vie complet via l' Pipelines -> Pipelinesoption, quel est le but de l' Pipelines -> Releasesoption?

entrez la description de l'image ici


La réponse ci-dessous pourrait-elle vous aider à réaliser ce que vous voulez? Si oui, vous pouvez accepter la réponse afin que les autres utilisateurs SO puissent voir si la solution fonctionne. Si vous rencontrez toujours des problèmes, n'hésitez pas à laisser un commentaire ici :-)
Frank Wang-MSFT

Réponses:


16

Pipelines est un nom dans la dernière interface utilisateur DevOps pour les builds. Dans l'ancienne interface utilisateur, c'est comme ceci: entrez la description de l'image ici

On peut dire que Pipeline(ou Build, ou Build Pipeline) représente CI (intégration continue) dans Azure DevOps. Releasereprésente le CD (livraison continue) dans Azure DevOps. Le pipeline prend généralement du code, le construit, teste et crée un artefact. Release prend l'artefact et le libère / le déploie.

L'utilisation dépend de votre projet.

Si vous avez un petit projet et qu'il n'y a pas besoin de fonctionnalités Release (par exemple, conditions de pré-déploiement et approbations), vous pouvez avoir Pipeline comme vous l'avez mentionné: restore -> build -> tests -> deployet pas besoin dans Release.

Si votre projet est grand avec beaucoup de contributions de développeurs, il est bon d'avoir Pipeline qui construit, exécute des tests unitaires, effectue d'autres automatisations et résultats avec artefact chaque fois que le développeur pousse vers le référentiel commun. Vous pouvez donc être sûr que tout est réglé et que les tests d'intégration ont été réussis. Le pipeline peut également se retrouver avec une tâche de publication / déploiement vers un environnement / serveurs de développement pour le travail interne, l'utilisation et les tests.

Dans les grands projets, vous n'avez pas besoin de déployer chaque push vers un référentiel commun. Vous pouvez donc régler une version qui sera responsable du déploiement dans l'environnement de production. Il a des fonctionnalités conçues pour cela, comme la pré-approbation, donc tout le monde est d'accord pour dire que c'est la bonne construction (ou artefact) pour la production.


Ce n'est pas exactement précis, car les pipelines (lorsqu'ils sont spécifiés en tant que fichiers YAML) prennent également en charge les scénarios de version.
Daniel Mann

2
@DanielMann elle n'a pas dit le contraire, elle répond à l'errance de l'op, en expliquant la différence entre les deux
AymenDaoudi

2

Comme indiqué dans les documents Microsoft, la section "Versions" est leur solution "Editeur classique": Lien

La section "Pipelines" propose de créer des pipelines de deux manières:

  1. Code YAML
  2. Éditeur d'interface utilisateur classique

Ce que Classic signifie essentiellement par eux est la façon originale dont les pipelines Azure DevOps sont créés. Vous créez un pipeline en utilisant un éditeur GUI de manière interactive. Le pipeline créé à partir de YAML , avec l'aide de l'assistant, est la nouvelle méthode .

Ce que la section "Pipelines" a principalement que "Releases" n'est pas qu'en écrivant le code YAML, il vous permet de configurer votre stratégie CI / CD en tant que code, où, la définition de Pipeline vit à côté et avec votre code.

Leurs nouvelles ressources d'apprentissage indiquent également d'utiliser YAML et de créer des étapes de génération et de déploiement dans le même pipeline Déployer des applications avec Azure DevOps

Je recommande:

  • Si vous préférez utiliser l' éditeur Classic UI , utilisez la section "Pipelines" pour les builds et la section "Release" pour les déploiements;
  • Si vous préférez utiliser YAML, utilisez simplement la section "Pipelines" pour les builds et les déploiements et créez un pipeline à plusieurs étapes.

Pipeline à plusieurs étapes


Il est vraiment trompeur de voir comment ils appellent les choses.
AymenDaoudi
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.