<p>A build process is likely to be linked to code changes, such as when committing a set of changes into source control, or merging changes into a main branch.</p>
<p>Builds typically take care of anything which should be consistent across all environments, or where there is no meaningful value in repeating per-environment;  for example, static code analysis (lint), coding style checks, and anything else which is specific to the code.     A build process might also generate some kind of artefact such as a zip/archive, that archive may be published upto an artefact registry somewhere, with version number too.</p>
<p>Deployment happens per-environment, ideally with minimal variation such as environment-specific configuration parameters and the target resources.  For example, it may be useful to deploy into an ephemeral environment for development testing,  then some other test environments for QA or integration testing,  and finally for at least one production environment (possibly more than one if the strategy involves a passive failover environment, which should obviously be identical to the active production environment)</p>
<p>The difference boils down to looking at each task performed in the process and asking whether that task should happen just once when the code is committed and/or merged, or whether the task should happen every time the code or artefact is deployed, and applied to each target environment.</p>

CC BY-SA 4.0
2022-08-25T21:31:00.590Z
2022-08-25T21:37:02.983Z
2022-08-25T21:37:02.983Z
Ben Cottrell
<p>Most of the time I have seen that Infrastructure build and deployment have separate YAML configuration build and release respectively.</p>
<p>Why do we do that?
What If infrastructure build and deployments are contained in a single YAML file?</p>
<p>I want to know both disadvantages and advantages.</p>

<azure-devops><continuous-deployment><azure-pipelines><infrastructure-as-code>
Why are Release and Build pipeline separated?
bruno
# Why are Release and Build pipeline separated?

(Asked by: username_0 on 2022-08-25)

Most of the time I have seen that Infrastructure build and deployment have separate YAML configuration build and release respectively.

Why do we do that?
What If infrastructure build and deployments are contained in a single YAML file?

I want to know both disadvantages and advantages.

**Tags:** azure-devops, continuous-deployment, azure-pipelines, infrastructure-as-code


---

## 1 answers

### Answer by username_1 on 2022-08-25. Score: 0 | Accepted answer

A build process is likely to be linked to code changes, such as when committing a set of changes into source control, or merging changes into a main branch.

Builds typically take care of anything which should be consistent across all environments, or where there is no meaningful value in repeating per-environment; for example, static code analysis (lint), coding style checks, and anything else which is specific to the code. A build process might also generate some kind of artefact such as a zip/archive, that archive may be published upto an artefact registry somewhere, with version number too.

Deployment happens per-environment, ideally with minimal variation such as environment-specific configuration parameters and the target resources. For example, it may be useful to deploy into an ephemeral environment for development testing, then some other test environments for QA or integration testing, and finally for at least one production environment (possibly more than one if the strategy involves a passive failover environment, which should obviously be identical to the active production environment)

The difference boils down to looking at each task performed in the process and asking whether that task should happen just once when the code is committed and/or merged, or whether the task should happen every time the code or artefact is deployed, and applied to each target environment.


---

