Page 42 - MSDN Magazine, December 15, 2017

in production before a broader rollout. Again, the article “Phases in Build and Release Management” offers insight (bit.ly/2zLrL71).
As discussed, you can orches-
trate deployments across multiple
environments, using manual or
automated approval gates, while
supporting high availability for
your application. Whether you’re
targeting the cloud, the hybrid
cloud, or an on-premises environ-
ment, VSTS is the recommended
Azure DevOps solution. It allows
you to plan, monitor, build and
deploy to Windows, Unix, Android
or iOS, from .NET, Java, PHP,
Python, Ruby, C++, as well as from
many other products such as Ant, Maven, Gradle, msbuild, Junit, NUnit, xUnit, MSTest and Jasmine. Figure 5 shows the range of available solutions.
Both TFS and VSTS support a rich integration model using the same marketplace extension. If you cannot find a task needed for your release pipeline, you can build custom tasks that integrate with your CI and CD. For example, we’re using the open source VSTS Developer Tools Build Tasks extension (bit.ly/2hcqopf) to pack- age and publish our extensions to the Visual Studio Marketplace. Another example, the AWS Tools for Microsoft VSTS extension (bit.ly/2ybJYZZ), delivers tasks for Amazon S3, Beanstalk, CodeDeploy, Lambda and more. It enables you to orchestrate deployments that span both the Azure and AWS clouds.
Mitigating Risk in a CI/CD Pipeline
So far, I’ve explored how VSTS is a pipeline system with a simple, real-world example. The risk of failure grows rapidly as you increase the number and frequency of releases, and add dependen- cies and complexity to pipelines.
Figure 4 View of a Typical Continuous Integration/Continuous Delivery Release Pipeline
Figure 6 summarizes a few lessons from our DevOps transfor- mation, documented by Sam Guckenheimer at bit.ly/2j7x0JY. For example, we work in three-week sprints (1), using this cadence as our common heartbeat to plan and deploy continuously. We man- age debt continuously (2), to avoid the accumulation (or spike) of debt and resultant merge complexity (3) that we saw in the past.
The master branch (4) is our single source of truth, always in a healthy and shippable state. Teams use short-lived feature branches to isolate their work and submit a pull request when the feature is complete (5). On approval of the pull request, we merge the feature into the master branch. Teams repeat the process continuously for added work. The release isolation strategy (6) introduces one or more release branches from the main, enabling concurrent release management, multiple and parallel releases, and exact snapshots of our existing (blue) version at release time.
Pre-merge validation is important! Establish branch policies to ensure that the master branch meets your desired quality criteria. Always encourage developers to submit code changes
Let’s look at a few techniques for gaining visibility into real-time status and mitigating the risk in your CI/CD pipelines.
Garbage in garbage out. The old saying applies to your release pipeline! A reliable and quality release pipeline depends on a healthy source to feed its CI and CD. You can leverage proven branching strategies, like those described in “Adopt a Git Branch- ing Strategy” (bit.ly/2AoQQEA) and in “Branching Strategies with TFVC” (bit.ly/2yaqEMo).Youcanalsoemploy branch policies, and pull requests to maintain a healthy and shippa- ble master branch.
38 msdn magazine
Figure 5 Visual Studio Team Services Is Our Backbone Azure for DevOps Solution
Visual Studio Team Services