容器化和DevOps已成行业热词，微软自然不会错过相关生态的布局，之前就成功而及时地与Docker达成了深度合作。在这个领域，微软做了三件看起来非常具有前瞻性的事情，一是与Docker合作催生Windows容器，包括Windows Server Core和Windows Nano Server两种形式，以方便传统Windows应用程序向Docker容器迁移；二是着力优化Windows作为Docker宿主的能力和体验，使得Linux容器能够通过Docker for Windows稳定轻快地运行于开发人员Windows上，Docker的原生支持也添加进了Windows Server 2016中；三是不失时机地推出了Azure容器服务（Azure Container Service），使得基于容器的大规模应用程序能够顺利地在微软云中部署生根。

受益于上述策略的不断落地，在Visual Studio 2017中进行流畅的容器化应用开发可谓水到渠成。我们可以轻松地为相关Project添加Dockerfile打包应用进容器，并在Solution层面使用Docker Compose进行容器编排。笔者曾尝试在较短时间内建立起若干简单的Asp.Net Core微服务，并互相组合形成了基于微服务架构的应用程序，然后通过Visual Studio在本机的多个Linux容器上一键部署运行。更方便的是，Visual Studio 2017还帮助生成了.Net Core调试相关的Docker配置，使得调试模式下运行在Linux容器内的代码轻松地命中了VS内的预设断点！这样的单机多容器“远程”调试确乎是一种奇妙的体验。

Azure容器服务是微软云的容器解决方案，支持多种编排引擎

前面提到的Azure容器服务，值得再略着一些笔墨。有不少人认为，容器生态的不断发展对于传统PaaS形成了强而有力的挑战，因为细粒度的容器一定程度上可以替代PaaS，同时提供更大的灵活度以及可移植性——很多情况下的确如此。在这一问题上，Azure选择了两边下注，在继续不断发展PaaS的同时（比如积极投入Azure Functions这样的Serverless计算框架），也拥抱容器生态，推出并不断改进Azure Container Service 。保留不同粒度的抽象，把选择权留给客户，的确是最佳方案。目前Azure容器服务已支持Docker Swarm、Mesosphere DC/OS和Kubernetes三大编排引擎，同时底层利用Azure VM Scale Set特性优美地实现了弹性扩容。

VSTS/TFS提供了现代的持续集成能力

真正的DevOps离不开持续集成pipeline的搭建和管理。在大家的印象中，Visual Studio一直有比较好的手动发布支持，可以方便地一键部署应用程序至本地或云端。Visual Studio 2017已更进一步，通过与云端Visual Studio Team Service(VSTS)或本地Team Foundation Server(TFS)的深度配合，可彻底将CI/CD的流程串联并打通，实现自动编译、测试、发布和部署。

最新版本的VSTS/TFS不但让完整的DevOps流程开箱即用，并且从设计理念上充分考虑了开放性，可以在CI/CD pipeline的不同环节使用不同的技术：如使用GitHub的仓库进行源代码获取和编译触发，又如支持以Docker为构建和发布的基本单位，再如使用Octopus Deploy进行部署等。此间，Azure也扮演重要角色，既可以提供动态伸缩的Build Agent，又能够作为应用最终部署的目的地。

DevOps流程中容易忽视的一个痛点在于关系型数据库schema的版本控制和升级，实践中往往需要依赖手动编写的迁移脚本进行人工操作——这与DevOps的精神是相违背的。为了尝试解决这一问题，微软与第三方工具提供商Redgate进行了合作，首次将价值不菲的Redgate Data Tools内置于Visual Studio 2017企业版中。Redgate相关工具的妙处在于，不仅能够将数据库schema进行完善的源代码管理和编译检查，更能记录不同版本的演化细节，并在VSTS的配合下自动地增量更新到CI pipeline的各个数据库中，包括在审批后到达最终的生产环境。

　　展望与期待

不知不觉，Visual Studio已经走过20个年头。 Visual Studio 2017是一个重要的里程碑，同时也是一个新的开始。我们有理由相信VS2017还将不断升级，把握新的机遇。事实上，微软已经开始为VS2017准备后续的更新，并紧锣密鼓地发布了Visual Studio Preview，使得开发者们能够在正式的Update发布之前就可以率先尝试即将到来的新特性。

通过Visual Studio Preview我们可以知道，在未来的VS2017 Update1中，全新的Python开发环境将粉墨登场，还会带来支撑Windows 10 Creator Update新特性的UWP套件更新。之后，还会有针对数据科学和分析类应用程序（Data science and analytical applications）开发的专属支持。相信这些将来的更新都会广受欢迎。

针对中国的开发者群体和市场环境，Visual Studio团队想必也会越来越重视。近期微软与华为的合作就是一个很棒的成功案例：华为通过使用VS2017进行面向Linux的C++开发，大幅提升了生产效率。 在此，我们也期待Visual Studio未来能够做得更多更好。其实除了解决部分组件水土不服的问题外，Visual Studio还大可以尝试与国内的公司、平台和生态进行更深入的合作。让我们大胆试想，如果VS能够支持微信小程序的开发，或是在VS中能够方便地对接使用阿里云的基础设施，是不是听上去就更有诱惑力了呢？

　　写在最后

"Any Developer, Any App, Any Platform"，Visual Studio 2017在这样的新口号下酝酿和诞生。开放而非封闭，合作而非拒绝，兼容而非分裂，这是属于微软的改变，这是属于微软的进化之道。众多微软技术生态爱好者们期待已久的春天，似乎真的要到来了。也许有一天，我们不再需要强调“微软技术栈”，因为它本就是开放技术世界的组成部分，互相融合，难分彼此。

注：本文仅代表作者个人观点。作者个人与文中所提及商业公司均无利益关系。

　　作者介绍

何恺铎，供职于国双科技(Nasdaq:GSUM)，现任高级技术总监，负责网站与流量分析产品线。曾参与架构和设计了国双多个面向数字营销和社交聆听的大数据解决方案。个人关注的技术领域包括.Net生态系统、云计算、大数据技术栈等。