Introducing Release Management for Team Foundation Server 2013

Editor's Notes

• #2: In this session we’ll take a look at Release Management for Team Foundation Server 2013.
• #3: Applications, and the associated set of user expectations, have evolved significantly over the past few years. Applications are expected to run on many different platforms, data is expected to be readily available, and social tools built in. In addition, as business needs and technology continues to change rapidly, developers need to be able to quickly deliver value to customers and integrate feedback. In this session, we’re going to dig deeply into how the 2013 wave of developer offerings better enable continuous delivery.
• #4: Managing releases can be a significant challenge. The requirements come from a broad array of sources, and can have technology teams asking a lot of questions. The kinds of questions they come with are “How do we elegantly shift from long release cycles to monthly, or even daily?” Other times, they want to know “How can we help set customer expectations about when bug fixes and feature requests go live?” So many people need to plan their tasks around the release cycle, so teams want to know “How can we make sure everyone understands the release pipeline so they can do their jobs?” And sometimes, there are legal or governmental pressures around compliance and regulation, leading to questions like “How can we feel confident we’re properly tracking, managing, and approving our releases?”.
• #5: As part of this continuous process of delivering value, one component that often gets overlooked is the release phase. As a distinct piece, it’s not always that hard to deploy a single instance of an application to a single environment. However, the promise of continuous value relies on the ability to continuously publish updated versions of an application across a variety of environments for various purposes, which can be very difficult to perform and manage. As a result, Microsoft continually invests a lot of effort in simplifying and scaling this process so that it can become more repeatable, predictable, and transparent.
• #6: When we think about the lifecycle of a specific version of an application, we often break it down into the stages it must go through to see the light of production. You’ll typically start with a development environment for a developer or small team to coordinate on. After the build passes that stage, it’ll need to be run through an integration environment where the work from the entire application unit is brought together. If that all goes well, the app will need to be deployed to a QA environment for greater testing. With success there, it’ll move on to one or more stages of production in order to be accessible to users.[Build]As a build moves down the pipeline toward production, more people get involved and the need for coordination increases significantly. You also have to account for the nature of the deployment environments, especially as load testing and other requirements may result in differences in the topography of the environment itself. You want to make sure each phase has the same build deployed in the same way. And, of course, if you invest in automation, there’s testing time to take into account for the process itself.
• #7: If we approach the process from a developer’s perspective, the steps abstract out a little bit. First, you’ll start off by writing code in your tool of choice. You’ll run builds and package as needed before provisioning an environment, deploying the app, and testing it. At the end, the app is approved and gets pushed out to production.[Build]However, it really turns out that the application is more likely to have lots of different builds deployed and tested before one passes the quality gate and can get pushed through. In addition, a build will likely need to go through the environments we discussed earlier, resulting in a need for the repeatable deployment model.[Build]Microsoft’s ALM platform is designed to support this approach, which makes it easier for issues that get raised during the test process to cycle back through the development cycle so that they can be addressed and pushed through the release cycle again.
• #8: A major goal is the ability to take a single build package and push it out to each environment in the same way.[Build]This drastically reduces the amount of manual effort required to update the environments and can make the entire process much smoother.
• #9: Another important aspect to each release environment is what we’ll refer to as the “stage stack”. This is a simple layout of the steps typically required to get a packaged app from a build location out to a prepared environment, through the necessary install and configuration, through the required tests, and finally approved for migration to the next stage. Microsoft has provided many of the tools to support this stack, although sometimes a little extra work is required to help it all work together.[Build]Lab Manager is available to help provision environments.[Build]PowerShell is ideal for configuring environments.[Build]There are some useful built-in tools for deploying and installing the application itself.[Build]And lots of companies invest in their own custom tools to configure applications.[Build]Running automated tests during the release process is becoming the standard for applications of every type.[Build]Microsoft Test Manager handles the testing aspects.[Build]And now with Release Management for Team Foundation Server 2013, this entire process is only going to get better.
• #10: Release Management for Team Foundation Server 2013 is a continuous deployment solution for .NET teams. It helps automate the deployment process and helps teams manage multiple environments. It also introduces a level of collaboration cross the release process, as well as providing an array or analytics and reporting. It was originally launched in 2009 by InCycle Software as InRelease and was acquired in the summer of 2013.
• #11: The release management authoring components are included with Visual Studio Test Professional, Visual Studio Premium, and Visual Studio Ultimate. The client will remain a separate application for the 2013 release, but it’s packaged and installed with the rest of the toolset. Everything needed to participate in a release process will be included in the Team Foundation Server CAL. Server components are integrated into Team Foundation Server 2013.The Deployment Agent (in the target servers, etc.),which are required for each node you deploy to, will continue to be licensed separately.
• #12: One major benefit of the new Release Management Server for Team Foundation Server 2013 is that it provides all the automated deployment goodness we were discussing earlier.
• #13: It also ensures that the deployments are pushed out the same way to all stages.
• #14: Not only does it automate the overall workflow, but it provides the ability to automate approvals where necessary, such as early phase deployments. You can still keep manual approvals for deployments deeper in the release cycle.
• #15: Finally, the whole process is recorded so that you can enjoy full traceability throughout the process. This is extremely valuable in scenarios where there are strict compliance requirements for legal or other reasons.
• #16: Let’s take a look at how the new release management infrastructure fits into your development environment.[Build]First, you’ll deploy Release Management Server.[Build]Next, you’ll install deployment nodes on the target systems in your deployment environments.[Build]You can then configure Release Management Server to pull builds from TFS and push them out to the specified environment.[Build]There is also a client app and Web UI that allow users to interact with the release management, workflow, and reporting features.A release typically gets triggered by an automated event, whether it’s a check-in or on a schedule. However, you can manually create a release as well. Once a release is begun, it works its way down the “release path”, which might be “Dev to QA to Production” with automated and/or manual gates at each.The paths are composed on the various servers grouped into environments on which the testing for the stage is performed. Once an application needs to be deployed to a new environment, the server will queue deployment requests to all the required target servers for each component of the application. This allows an atomic deployment of all the components.The Release Management Deployment Agent running on each target server monitors the Release Management Server continually, at a configurable interval, and will pick the installation requests for the one or many components it needs to install locally.The Deployment Agent will then find and download the release package, provided by the Release Management Server. RMS calculates the location using the TFS API, if built by TFS, or using a predefined UNC path if not. Finally, the Deployment Agent downloads any additional executables, such as batch files, PowerShell scripts, EXEs, etc, to be run as part of the installation. These are additional deployment activities beyond the installation itself. Creating test data or triggering automated tests are common scenarios here.
• #17: See script.
• #18: Release Management Server automates all the manual tasks involved in releasing applications, with a focus on the error-prone and repetitive tasks that delay time-to-release. Thanks to its centralized configuration, development, operations, and quality assurance teams are able to define every application, component, and release path they need. Remember, Release Management Server is not a packaging solution or a MSI. However, it can work with your packaging tool or MSI to automate and track complex deployments from TFS to your target environment.The process editor provides a drag & drop experience that supports parallel deployments of any complexity. You can configure the workflow to include an array of built-in actions, or define your own. These range from running batch scripts local to a server or even managing armies of virtual machines hosted in Windows Azure. There is broad support for deploying applications and components out to IIS, SharePoint, SQL, and other target platforms. And if anything goes wrong, you can have your rollback, or rollforward, plans built right in.
• #19: Release Management Server provides a fully configurable workflow where you can manage every step and follow the status changes of your release. With its common platform for development, operations, and quality assurance, Release Management Server optimizes the release process by removing down time between approval and deployment. For example, a deployment can be automatically triggered by approval at the previous stage.Approvals can be defined by person or by group. The defined approver can also start, stop, approve, reject, restart, retry, abandon and even reassign releases.
• #20: To initiate a release, Release Management Server leverages your Team Foundation Server (TFS) source control and build automation. There are many ways to take advantage of this, such as by triggering a build from Release Management Server using a label or build actions. You can also use TFS build definitions to filter out builds to deploy for manually triggered releases. TFS build definitions can be leveraged to configure components and calculate the drop locations. The TFS API is also available to define TFS connections to deploy components from different TFS servers, and TFS groups can be used in the security configuration.
• #21: Release Management Server provides valuable insights into the entire release process. Armed with relevant and timely information, managers can achieve greater efficiencies by monitoring for continuous improvement. For example, you can keep track of the trend in releases, the amount of traffic in the release pipeline, any possible bottlenecks, and even get performance insights.
• #22: See script.
• #23: One challenge for releasing to multiple environments is dealing with different settings in each location. QA probably has a different DB server than Production, they might use different Oauth settings, etc. The custom work required for this to elegantly scale across an unknown number of potential environments is pretty substantial. However, Release Management for TFS offers an excellent solution.Its custom build process template also contains the logic to tokenize your configuration files. This logic assumes that in your solution, you have two version of your configuration files. One version is your normal configuration file used during local development, and the other is a corresponding file that has the same content, except that instead of having local values for your variables, tokens have been put there. The build activity will swap those two files before doing the build, so that you end up with the tokenized version of the configuration files in the drop location.
• #24: The release management services provide a configuration experience that is very familiar to anyone who has set up the Visual Studio test or lab infrastructure. Similar steps, dialogs, and processes are used to make it very easy to configure.
• #25: Release Management Server provides granular control for the entire release process that includes many stakeholders, including Development, QA and Ops. You can limit which group can view, edit, or create a given release template. You can also decide who can edit approvers for each release stage. For example, the development group can modify the approvers in the Dev stage but cannot modify approvers for the Production stage. Another example is how you can limit which group can edit the configuration values for each release stage. For example, the development group can modify the values in the Dev and Integration stages but cannot modify Production. Finally, you can limit the stage types a given environment can support. For example, you can limit which production servers can be used.
• #26: When something fails during the deployment process, it can often be difficult to track down exactly what went wrong. And even once the issue is discovered, there is often a lag in communication for letting other people who what happened. With Release Management Server, there is much greater traceability and transparency for the entire process.
• #27: In summary, the new release management features for Visual Studio 2013 and Team Foundation Server 2013 provide a robust offering that helps deliver on the promise of continuous delivery. Teams will be able to release more frequently, and customers will benefit from better software, faster. Stakeholders throughout the organization will have better insight as to the status of the product and its release cycle. And finally, managers will feel confident that they’re meeting their compliance and regulation requirements along the way.
• #28: Preview URL: http://www.microsoft.com/visualstudio/inrelease/