Deploying Updates to App1 with App2 Dependency: A Microsoft DevOps Solution

Ensuring Seamless Deployment and Activation of App1 with App2 Integration

Question

Your company develops an application named App1 that is deployed in production.

As part of an application update, a new service is being added to App1. The new service requires access to an application named App2 that is currently in development.

You need to ensure that you can deploy the update to App1 before App2 becomes available. You must be able to enable the service in App1 once App2 is deployed.

What should you do?

Answers

Explanations

Click on the arrows to vote for the correct answer

A. B. C. D.

A

Feature flags support a customer-first DevOps mindset, to enable (expose) and disable (hide) features in a solution, even before they are complete and ready for release.

Incorrect Answers:

C: Branch policies are an important part of the Git workflow and enable you to:

-> Isolate work in progress from the completed work in your master branch

-> Guarantee changes build before they get to master

https://docs.microsoft.com/en-us/azure/devops/migrate/phase-features-with-feature-flags

To enable the deployment of the update to App1 before App2 becomes available and enable the service in App1 once App2 is deployed, you should implement a feature flag.

A feature flag is a DevOps technique that allows you to toggle functionality on and off without deploying new code. It enables you to manage releases effectively, minimize risks, and reduce the time to market for new features.

By implementing a feature flag, you can deploy the update to App1 with the new service but keep it turned off until App2 becomes available. Once App2 is deployed, you can turn on the feature flag to enable the new service in App1.

Creating a fork or a branch in the build, or implementing a branch policy will not help achieve the desired outcome. A fork in the build refers to copying the code to create a new branch, and a branch policy is a set of rules to enforce on a branch. These techniques are useful for managing code changes but do not address the requirement to deploy the update to App1 before App2 becomes available and enable the service in App1 once App2 is deployed. Creating a branch in the build is also not relevant in this scenario.