<p>I have a project with N git repos, each representing a static website (N varies). For every git repo there exists a build definition that creates an nginx docker image on Azure Container Registry. These N build definitions are linked to N release defenitions that deploy each image to k8s (also on Azure). Overall, CI/CD works fine and after the releases have succedded for the first time, I see a list of environments, each representing a website that is now online.</p>

<p><a href="https://i.stack.imgur.com/FW1iK.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/FW1iK.png" alt="environments VSTS CI/CD release pipelines"></a></p>

<p>What I cannot do though with VSTS CI/CD is to declare how these environments are torn down. In GitLab CI (which I used before), there exists a concept of <a href="https://docs.gitlab.com/ce/ci/environments.html#stopping-an-environment" rel="nofollow noreferrer">stopping an environment</a> and although this is just a stage in <code>.gitlab-ci.yaml</code>, running it literally removes an environemnt from the list of the deployed ones.</p>

<p>Stopping an environment can be useful when deleting autodeployable feature branches (aka Review Apps). In my case, I'd like to do this when an already shared static website needs to be removed.</p>

<p>VSTS does not seem to have a concept of unreleasing something that has already been released and I'm wondering what the best workaround could be. I tried these two options so far:</p>

<ol>
<li><p>Create N new release definition pipelines, which call <code>kubecetl delete ...</code> for a corresponding static websites. That does make things clear at all, because an environment called <code>k8s prod (website-42)</code> in one pipeline is not the same one as in another one (otherwise, I could see whether <code>web → cloud</code> or <code>web × cloud</code> was called last):</p>

<p><a href="https://i.stack.imgur.com/ubFGc.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/ubFGc.png" alt="environment cards (multiple release definitions)"></a></p></li>
<li><p>Define a new environment called <code>production (delete)</code> in the same release defenition and trigger it manually.</p>

<p><a href="https://i.stack.imgur.com/iMnf9.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/iMnf9.png" alt="environment cards (single release definitions)"></a></p>

<p>In this case 'deploy' sits a bit closer to 'undeploy', but its hard to figure out what was last (in the example above, you can kind of guess that re-releasing my k8s resources happened after I deleted them – you need to look at the time on the cards, which is a pretty poor indication).</p></li>
</ol>

<p>What else could work for deleting / undeploying released applications?</p>

Alexander Kachkaev
<p>VSTS has not the feature "stop environment" (auto delete the deployed things on the environment) in release management. But you can achieve the same thing in <a href="https://learn.microsoft.com/en-us/vsts/pipelines/build/yaml?view=vsts" rel="nofollow noreferrer"><strong>VSTS YAML build</strong></a>.</p>

<p>So except the two workarounds you shared, you can also stop the environment by VSTS YAML build (similar as the mechanism in GitLab).</p>

<p>For YAML CI build, you just need to commit the file end with <code>.vsts-ci.yml</code>. And in the <code>.vsts-ci.yml</code> file, you can specify with the tasks to delete the deployed app.</p>
