This covers best practices in managing feature releases in TFS / Visual Studio and using Azure.
Build once and have it deploy to multiple environments. The concept is to de-couple the build from deploy. The deploy is a pipeline, from dev to int to stage to prod. In between these steps are approvals. Release Management can automate and manage all this for you.
Releases are tied to a build. In other words, output of a build = input to a release.
Observe the following concepts
User your build to prepare a release
Make the build output environment agnostic
Separate build stuff from release stuff
Variables are your friend variables used at release level and environment level
Create a release definition in TFS, there are 3 types
Azure Cloud Service
Build Definitions must be linked to Release Definitions
In the prior build section, it had all the steps for release to environment (like copy files). These steps should be part of the release, not build. So copy those steps into the release definition.
The release and build definitions can be cloned for each of the environments. For example, the following release definition deploys to dev and qa
On code check-in, automatically kick off the build and release definition. This can be done under the Release definition under Triggers
Setting an approver for a particular release. Goto configure and set the approver
Dealing with deployments through branches.
This is the common flow � features get merged into dev and dev gets merged into main. Then from main we create the release branches, of which from each release branch there are sub branches for each version.
Every new feature gets a configuration value, a feature flag that is on / off. When that feature is ready (all unit tests passed), the flag is set on. Then on release, it just grabs those features that have the flag set as on. Doesn�t care about branches.
This approach requires some work in the code. Its temporary code that would be removed later. As such, Feature Flags are a type of Technical Debt.