Quelle est la différence entre Pipeline et Release Pipeline dans Azure Devops?
Un fichier yaml est généré lorsque vous choisissez cette option ci-dessous:
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 le Pipelines -> Pipelines option, à quoi sert le Pipelines -> Releases option?
Pipelines est un nom dans la dernière interface utilisateur DevOps pour les builds. Dans l'ancienne interface utilisateur, c'est comme ceci: 
On peut dire que Pipeline (ou Build, ou Build Pipeline) représente CI (intégration continue) dans Azure DevOps. Release repré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 -> deploy et pas besoin de 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.
Comme indiqué dans les documents Microsoft, la section "Versions" est leur solution "Éditeur classique": Lien
La section "Pipelines" propose de créer des pipelines de deux manières:
- Code YAML
- É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 le nouvelle façon .
Ce que la section "Pipelines" a principalement que "Versions" ne contient pas est qu'en écrivant du 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 UI classique , 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.