search

cake-build / website

:earth_americas: The Cake website: https://cakebuild.net
https://cakebuild.net
MIT License
42 stars 230 forks source link

Change to unified YAML pipeline #1142

Open pascalberger opened 4 years ago

pascalberger commented 4 years ago

Instead of separate build and deployment pipelines we should switch to a unified YAML pipeline

devlead commented 4 years ago

What's the major win vs. current pipeline? Having the release and build separate means we build once and can promote that artifact easily from each stage from directly from Pipelines or Slack. We can change release parameters without rebuilding. Will that still be the case?

pascalberger commented 4 years ago

What's the major win vs. current pipeline?

Current pipelines are defined through UI. Changes are hard to track. A YAML file in the repo would allow to have pipeline logic under version control with history, etc. Also changes would need to go through a pull request. Using a unified YAML pipeline instead of two separate pipelines is the more powerful way to implement the pipeline. IMHO it is also more natural to have a single pipeline for every change, where I see the whole progress from commit into production on one glance.

Having the release and build separate means we build once and can promote that artifact easily from each stage from directly from Pipelines or Slack.

What we do on Slack is approve environments. This is won't change, we still will have the two deployment stages. Just together with a build stage in front.

We can change release parameters without rebuilding. Will that still be the case?

Should be the same. You can edit variables of existing pipelines. In case you change actual pipeline, the pipeline needs to run again. But I don't see this as a limitation which makes a difference in practice.

devlead commented 4 years ago

The current pipeline is versioned and tracked through build.cake and deploy.cake, what gets deployed where is controlled through pipeline variables.

Build could easily be moved to yaml as it just invokes build.cake (which builds the site, create and uploads the artifact)

But is there a major win to having the release in the same yaml pipeline?

Does release gates work with YAML pipelines? I was under the impression that yaml Environments only worked with Kubernetes and virtual machines. Not app services?

pascalberger commented 4 years ago

The current pipeline is versioned and tracked through build.cake and deploy.cake, what gets deployed where is controlled through pipeline variables.

The actual build steps yes, but not the call of Cake, triggers, etc

But is there a major win to having the release in the same yaml pipeline?

What I said: IMHO it is also more natural to have a single pipeline for every change, where I see the whole progress from commit into production on one glance. If more than an occasional PR is made I currently need to switch back and forth between build and release pipeline to keep track of what has build, is currently building, what is deployed and what is ready to deploy. If e.g. 5 changes are merged one after another it is currently very hard to see what already has been deployed to what stage.

Does release gates work with YAML pipelines?

You mean approvals? You can define approvers on an environment

I was under the impression that yaml Environments only worked with Kubernetes and virtual machines. Not app services?

We don't need any app service connection since this is handled by the Cake scripts. While environments only support Kubernetes and virtual machines as resources it should be possible to create an empty environment.