-1

I'm setting up a VSTS CI environment for the first time. Our application has several components including a Web App and several API apps. We are using development, testing and production environments.

I currently have separate release definitions for each component on each environment. Recently, someone suggested running a single release definition that took all of the artifacts and deployed them across multiple environments.

What's best practice in a situation like this? Maintaining several definitions is a pain when something in our environment changes, because I need to edit each of the definitions to correct it. On the other hand, an all-in-one release generates a new release and deploys 5 apps to dev any time any component's repo is updated, which seems a big waste of resources. Any advice welcomed.

1 Answers1

-1

Actually it's all based on your requirements.

You have the absolute control for separate release definitions for each component on each environment, just trigger the specific release definition as needed. But Just as you said Maintaining several definitions is a pain when something changes in your environment.

Single release definition with multiple environments. Just only change the settings for this release definition once something changed in your environment. You can link all the related artifacts and download the needed ones by selecting the Artifact download.

However in CI/CD you need to set the Deployment Conditions, thus you can define which environments will be automatically deployed and which ones will not be triggered automatically.

Besides, you can use the Variable Group and Task Group in your build/release definition, thus you can only need to change the settings for the specific Variable Group or Task Group, and the changes will apply to all the build/release definitions which used the the corresponding Variable and Task Groups.

Please see below articles for more information about the release management:

Andy Li-MSFT
  • 28,712
  • 2
  • 33
  • 55