Page 40 - MSDN Magazine, December 15, 2017
P. 40

Figure 3 Deploy with Confidence from Azure
such a pipeline, read the in-depth paper, “CICD Pipeline for Your Extensions with Visual Studio Team Services,” before continuing. You can download the PDF from bit.ly/2hCAZKX.
Our journey starts with the team committing its code to a Git repository or service provider such as VSTS (Git and Team Foundation Version Control), GitHub, BitBucket or Subversion. When a developer commits changes to the team’s repository (1), continuous integration is optionally triggered (but strongly recom- mended) to check the associated pull request before you commit changes and after you successfully merge changes to a specified branch. VSTS not only automates your build, testing, and other validation tasks, it gives you an insight and traceability into every- thing in the build, including code changes, review comments, test results, and code coverage.
CD, started by the build, is the process of validating, configuring and deploying your changes to one or more environments. You can choose to have a predefined schedule and conditions to trigger the deployment for each environment in your release pipeline. In addition, you can define approvers for each environment before and after deploying an environment. Approvals can be set to be automatic or can be executed by one of many specific users, all users in any order, or all users in sequential order. When a group is speci- fied as an approver, only one of the users in that group needs to act.
In the example for this article, we’re automatically processing the Canaries environment (2), which privately deploys the extension to the Visual Studio Marketplace (3). We’re using private extensions initially, so that they’re not discoverable on the public marketplace. Private extensions are in production for the customer, but only visible to the customer’s nominated VSTS accounts. See the previ- ously mentioned white paper for details on the publishing process. It’s important to emphasize that your release pipeline could deploy to a variety of destinations, but we’re targeting the Marketplace as we are deploying a VSTS extension in this example.
CD proceeds with a parallel (forked) deployment to the On- Prem Validation (4) and the Early Adopters (5) environments. The former proceeds automatically, as indicated by the pre-deployment approvers icon (  ) in the pre- deployment condition. The latter introduces the pre-deployment manual approvers icon (  ), which shows that third-party approval is needed before the deployment can begin. In addition, the exam- ple specifies that the environment trigger fires only if changes apply to the master branch (6), effectively shielding production from other branches.
Youcanimplementseveralcon- trol goals to progressively expose your changes to subsequent envi- ronments, keeping an existing
(blue) version live, while deploying and validating a new (green) version. If an issue is discovered, the pipeline allows you to stop the deployment to minimize impact to end users.
VSTS not only automates your build, testing and other validation tasks, it gives you insight and traceability into everything in the build, including code changes, review comments, test results and code coverage.
CD continues with a joined deployment pipeline, where deploy- ment to the Users environment (7) occurs only after successful deployments to both the Early Adopters and On-Prem Validation environments. See “Phases in Build and Release Management” (bit.ly/2zLrL71) for details on running tasks on different agents, man- ual interventions, and conditions under which tasks will process or stop your release pipeline.
We’ve used deployment rings to limit impact on end users, while gradually deploying and confirming change in the production environments. We evaluate the impact, sometimes called the “blast radius,” through observation, testing, diagnosis of telemetry and, most important, user feedback. The Canaries environment is the first stage in the ring deployment model we’re using to expose the private extension to a controlled user group to test the new version
36 msdn magazine
Visual Studio Team Services






















































































   38   39   40   41   42