We’re announcing a bunch of new things at Connect(); this week.  It’s an exciting time.  Connect(); is an annual developer event where we focus particularly on improving the overall experience for developers.  We’ve queued up a lot of good news and I wanted to share a few highlights – particularly from the DevOps space that I’m deeply engaged in.

Team Foundation Server 2018 final release

I’m excited to announce that we released Team Foundation Server 2018 this week.  We’ve been hard at work on it since we released TFS 2017 Update 2 back in July.  TFS 2018 is a major update to Team Foundation Server and has a ton of improvements you can read all about in the release notes.

• TFS 2018 Release notes
• TFS 2018 web installer
• TFS 2018 ISO image
• TFS 2018 Express web installer
• TFS 2018 Express ISO image

I want to comment on a few of my favorite things:

• Mobile work item experience – We now support a work item experience optimized for phones.  It makes it super easy to check on your work, comment on, share and route issues from any where at any time.

• Wiki – Now you can have rich wiki experiences as part of every one of your projects.  Edit in markdown and create rich pages with links, tables, images and more.

• Git Forks – For years, TFS has supported Git repos and we’ve iterated to make the experience better and better.  Starting with TFS 2018 we now support forking Git repos to better enable collaborating at a distance.

• GVFS support – In May of this year I announced work we were doing to scale Git to the largest code bases on the planet starting with the Microsoft Windows code base.  That work involves improvements both to the client and to the server.  It also involves a new virtual file system we call Git Virtual File System (GVFS) that instantiates portions of the repo on demand.  The result is dramatic – Git commands that run 2 or 3 orders of magnitude faster.  I’m extremely pleased to announce that we are releasing GVFS support built into TFS 2018 so you too can benefit from the best performance in the industry on large Git repos.  In addition to releasing server support in TFS 2018, we are releasing built, signed versions of the client components that we open sourced – making it much easier for you to acquire and install GVFS.  Read more about GVFS announcements in Ed’s post.

• Graphical release definition editor – TFS 2018 includes our new release definition editor that make it really easy to configure and visualize release workflows.

• Deployment groups – TFS 2018 includes our new Deployment groups feature that does agent based deployments across potentially large and complex applications.

These are just a few of the highlights in TFS 2018.  I encourage you to checkout the release notes to learn more – there’s a ton of great improvements.

GVFS Momentum – Scaling Git to the worlds largest code bases

In addition to including GVFS in TFS 2018 and the new client binaries I described above, I want to talk a bit about GVFS momentum.  A lot has happened since we announced our plans to build GVFS for the Windows repo – weighing in at over 300GB and more than 5.5 million files, delivered support in Visual Studio Team Services and open sourced all the client components.  Interest in scaling Git to the largest code bases in the world has been intense.  I’ve had numerous customers reach out to me to learn how to apply Git to their very large code bases.  We’ve also seen tons of interest among other players in the Git ecosystem to make GVFS the defacto standard for really scaling Git. At Connect(); GitHub announced that they are working on adding GVFS support, making scalable Git available to the entire open source world.  Stay tuned for more info from them on timing.  They also will be working closely with us to further improve GVFS and bring it to Mac and Linux users.  I’m excited to partner with GitHub on this.  They have a lot of experience with the Git community and running Git hosting at scale and I believe their partnership can only help us collectively advance the future of Git. Atlassian also joined the GVFS chorus.  They were one of the first to join, adding GVFS support in SourceTree early on.  More recently they released an extension to BitBucket that enables BitBucket customers to use the GVFS client against their backend.  It’s exciting to see another Git provider adding GVFS support. We also have seen continued momentum in the Git client space – with Tower Git and gmaster both adding support. In parallel with the growing industry support, we’ve continued to improve GVFS by iterating on the top performance and scale issues.  The result is that, every month, it is getting faster and more scalable.  Again, I encourage you to read Ed’s GVFS update for more detail.

Azure DevOps Projects

Over the past year or so we’ve been working to make deployment to Azure as easy as possible.  At Connect(); we released a new “Getting Started” experience for developers we call Azure DevOps Projects.  This experience enables you to *very* easily create a new small sample app, using a wide variety of tech stacks (.NET, Java, Node.js, Python, …) and configure a full CI/CD pipeline.  With a few clicks, you get a Git repo with the sample app, a CI build definition, a release pipeline and a provisioned and deployed app.  If you already have your own app in a Git repo, we’ll help you get a CI/CD pipeline set up for that too.  The entire experience is done within the Azure portal and starts by creating a new DevOps Project. You are prompted with a few screens to specify the parameters of your app, like the language… the framework the hosting type And lastly your VSTS account and Azure resources And, when you are done, you get a fully configured DevOps pipeline and deployed app.  Updating and redeploying is as easy as committing a change to master and watching the changes flow through the pipeline!  Magic 🙂  It’s never been easier to get started with a cloud app and a solid CI/CD foundation.

Pipeline as code – YAML public preview

This week we are also releasing a public preview of YAML support for VSTS build definitions.  With YAML, you can represent your build pipeline as a text file that describes the build workflow and actions.  You can then check it in with your code and use Pull Requests to manage changes, revert to previous versions, flow build changes across repos and branches along with associated code changes, and more.  This is an important milestone and evolution in the VSTS CI/CD experience. This does not represent a different build system – it’s not like the transition from XAML builds to Pipelines and Tasks (Build.vnext) – which I know was a big transition and created challenges for people.  Our YAML support is incremental evolution on our Pipelines and Tasks build system currently in TFS and VSTS.  It uses the same build engine and the same agents.  Most importantly, it supports the same task ecosystem – so the hundreds of build extensions in the VSTS marketplace can all be used inside a YAML build definition, just like in the graphical editor. Here’s an example of a base YAML build template for an ASP.NET Core build… This is, of course, a work in progress.  Our YAML build definitions work well and we’ve already adopted them on some of our own teams for our regular builds, but there’s lots more to do.  A few key examples are:

• Over the next 2 weeks we will roll out support (as part of our sprint 126 deployment) for exporting a build definition in the graphical editor as a YAML definition.  This will be a 100% lossless transformation, but it’s one way.  You can’t load a YAML build definition in the graphical editor – you’ll have to choose whether you want each build definition managed as a YAML file or in a graphical editor.
• Over the next few months, we’ll be working to extend our YAML definitions to cover our release pipelines as well as our build pipelines.  Right now, our YAML support only includes build, release is under development.
• Once YAML support is baked and hardened, we will release it in our on-prem TFS product as well.  I don’t know exactly when that will be but I hope sometime in 2018.

Check out Chris’s VSTS Pipelines as YAML blog post for more details or read the Getting Started with YAML docs to just try it out.  I’m really excited about this and I hope you are too.  This retires yet another of our top 10 Uservoice requests (with 662 votes) and I hope you like really it.

Release management gates

An important part of any proper DevOps process is gradually deploying an app across the user base and monitoring progress and health as it rolls out.  Our release management pipeline with environments and approvals provides a great construct to do this.  I’ve mentioned before that we use VSTS release management to deploy VSTS itself and that we have over a dozen scale units organized in to rings of deployments.  A ring is deployed and then we wait about 24 hours to monitor the health of the system before we progress to the next ring.  A new feature we are releasing this week on VSTS allows you to automate this process.  It allows you to create release “gates” that specify conditions necessary to begin or completely finish a deployment to an environment.  For instance, you can configure an environment to deploy and wait 24 hours, ensure there are no blocking work items against the release and ensure there are no monitoring alerts before proceeding with the subsequent environment deployments.  This will enable you to automate a process that is often manual today. Here’s an image of a simple pipeline where I’ve configured a Blocking bugs gate and an Azure monitoring gate. The awesome thing is that you can create any kind of gate that you like.  You can create custom gate logic using Azure Functions, REST APIs or independent services connected via Azure Service Bus.  These custom gates can do anything you like and then return/post back readiness data.  In the next couple of weeks I hope to release a sample release gate, written as an Azure Function, that analyzes Twitter sentiment and presents the result as a release gate status.  The possibilities are endless. Release management gates will help you evolve your release management process to the next level!

VSTS Symbol Server – public preview

For several years now, adding support for TFS/VSTS to host symbols has been a top customer request.  Here’s the latest vote count from UserVoice. I’m incredibly excited to announce a public preview of Symbol Server support in VSTS as part of our Package Management extension.  The updated Index Sources & Publish Symbols task now supports publishing to “Team Services”.  All you have to do is check “Publish symbols” and leave the default Server Type of “Team Services”.  We handle the rest. Lastly, you configure your VS 2017 Update 5 or later to retrieve symbols from your VSTS account and now you can attach to any running build of your code built by VSTS and get source and symbols without ever having the code on your machine.  This is transformational for your ability to debug “it doesn’t happen on my machine” problems.  Read Alex’s Symbol Server post for more details. We plan to bring plan to bring Symbol Server support to our on-prem TFS product, as soon as we can.

Cloud hosted Mac builds in VSTS We also announced preview availability of free, cloud-hosted continuous integration (CI) and continuous delivery (CD) on macOS as part of Visual Studio Team Services (VSTS).  VSTS now supports building and releasing Apple iOS, macOS, tvOS, and watchOS applications without requiring teams to provide and maintain their own Mac hardware.  With this release, VSTS becomes the first CI/CD system in the cloud to offer Linux,  macOS, and Windows in a unified solution. Microsoft keeps hosted macOS installations updated with the latest build tools and SDKs including Xcode, Android, and Xamarin.  The Apple App Store extension in the Visual Studio Marketplace simplifies releasing applications to beta testing and production environments.  The VSTS Secure Files library keeps certificates and provisioning profiles protected during CI and CD.  Furthermore, teams can take advantage of Visual Studio App Center to build, test, distribute, and monitor apps, as well as implement push notifications.

TFS data import service general availability

The TFS Database Import Service has reached GA.  The Import Service enables customers to migrate from their on-premises Team Foundation Server (TFS) and into our cloud hosted SaaS service Visual Studio Team Services (VSTS).  During the preview period, we have used the data import service to help hundreds of customers import their TFS Team Project Collections into a VSTS account.  We now have confidence in it to open it for broad, self-service use. Customers now no longer require approval from Microsoft to onboard and begin their migrations.  To find out more information and get started visit: https://aka.ms/tfsimport.

Visual Studio Team Services CLI (VSTS CLI) – public preview

We’ve made available for download the first preview release of our open source command-line tools for Visual Studio Team Services (VSTS).  In this first release developers using Windows, Linux or Mac will have the ability to authenticate and interact with VSTS via command-line.  Commands available for work items, source repo’s and build tasks enable you to do things like create a Pull Request or queue a build. In future releases we’ll expand support for additional commands against a wider set of VSTS capabilities and further streamline the experience based on customer feedback. So let’s recap…

1. Azure DevOps Projects – A super simple way to get started with a full DevOps pipeline for Azure.
2. TFS 2018 – A major update to TFS with tons of significant improvements like Wikis, Forking, Deployment groups, …
3. GVFS – Installable binaries and a new partnership with GitHub to drive GVFS as the industry standard for Git at scale.
4. YAML – Support for pipelines as code for maximum flexibility in your DevOps pipeline.
5. Release gates – Create automated measures of health and readiness to control your release pipeline
6. Symbol Server – Publish all your symbols to VSTS and make symbols and source easily available anywhere and any time.
7. VSTS command line – A new cross platform command line for automating all your DevOps processes.
8. Hosted Mac agents – Build and release macOS, iOS, tvOS and watchOS code on hosted agents.

It’s mind blowing and these are just a few of the exciting announcements we made at Connect();.  I hope you like all the improvements and we look forward to any feedback you have. Brian