An yaml file is generated while you choose this option shown below:
In this yaml file, you can define an entire deployment cycle starting from restore -> build -> run tests -> publish and -> deploy to azure app service web app
.
then, why there is the releases option? If i can define an entire lifecycle via the Pipelines -> Pipelines
option, what is the purpose of the Pipelines -> Releases
option?
Conclusion. The Azure DevOps Server provides two different types of pipelines to perform build, deployment, testing and further actions. A Build Pipeline is used to generate Artifacts out of Source Code. A Release Pipeline consumes the Artifacts and conducts follow-up actions within a multi-staging system.
Azure Pipelines releases can deploy artifacts produced by a wide range of artifact sources. such as Azure Pipelines build, Jenkins, or Team City. Define the release pipeline using stages and restrict deployments into or out of a stage using approvals. Define the automation in each stage using jobs and tasks.
Stages filters for pipeline resource triggers requires Azure DevOps Server 2020 Update 1 or greater. You can trigger your pipeline when one or more stages of the triggering pipeline complete by using the stages filter. If you provide multiple stages, the triggered pipeline runs when all of the listed stages complete.
Pipelines is a name in latest DevOps user interface for Builds. In old UI it's like this:
It can be said that Pipeline
(or Build, or Build Pipeline) represents CI (continuous integration) in Azure DevOps. Release
represents CD(continuous delivery) in Azure DevOps. Pipeline usually takes code, builds it, tests and creates an artifact. Release takes the artifact and releases/deploys it.
The usage depends on your project.
If you have a small project and there is no need in Release features (e.g. pre-deployment conditions and approvals), then you can have Pipeline like you mentioned: restore -> build -> tests -> deploy
and no need in Release.
If your project is big with a lot of developers contribution, it's good to have Pipeline which builds, runs unit tests, does other automation and results with artifact every time developer pushes to the common repo. So you can be sure all is settle and integration tests passed. Pipeline also can end up with release/deploy task to development environment/servers for internal work, usage, testing.
In large project you don't need to deploy every push to common repo. So you can settle a Release which will be responsible for deployment to production environment. It has features designed for this, like pre-approval, so everyone is agree it's the right build (or artifact) for production.
As noted in Microsoft docs, the "Releases" section is their "Classic editor" solution: Link
"Pipelines" section offer to create pipelines in two ways:
What Classic basically means by them is the original way Azure DevOps pipelines are created. You build a pipeline by using a GUI editor in an interactive way. Pipeline created from YAML, with the help of the assistant is the newer way.
What "Pipelines" section mainly have that "Releases" doesn't is that by writing YAML code it enables you to configure your CI/CD strategy as code, where, the Pipeline definition lives alongside and together with your code.
Their newest learning resources also indicate to use YAML and create build and deployment stages in the same pipeline Deploy applications with Azure DevOps
I recommend:
Pipeline with multiple stages
Edit: Update May 11, 2020, Pipelines YAML CD features now generally available
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With