关于《在 Windows 与.NET 平台上的持续交付实践》的问答录

  • João Miranda
  • 邵思华

2016 年 5 月 8 日

话题:.NETWindowsC#Windows AzureDevOps

《在 Windows 与.NET 平台上的持续交付实践》(Continuous Delivery with Windows and .Net)(免费下载)是由 Matthew Skelton 与 Chris O'Dell 所编著的一本简短的书籍。对于在 Windows 与.NET 环境中工作的开发者而言,本书可以说是由 Jez Humble 与 Dave Farley 所编著的《持续交付》(Continuous Delivery)这本书的一本非常实用的补充读物。

本书在第一章及最后几章介绍了持续交付的理论基础以及它对组织的结构所带来的影响,但本书的主体部分还是专注于介绍各种工具,通过这些工具实现成功的持续交付实践。

事实上,可以说本书最突出的优点就是为读者提供了一个一站式的资源集,使读者能够了解各种适合在 Windows 平台上使用的工具。正如本书的作者所指出的那样,“本书可以作为由 Jez 与 Dave 所编著的那本著作的补遗,目的是鼓励更多在 Windows 及.NET 平台上进行工作的团队实施持续交付实践。”本书的第二至第六章涵盖了持续交付中必不可缺的各种工程实践,包括:版本控制、持续集成、部署管道、监控及基础设施的自动化。

在本书的各个部分,你将看到真实世界用户案例的实际感想,这让本书的各种推荐实践变得更有说服力。这些案例包括 LateRooms.com 通过部署管道的实施实现了高达 700 倍的部署周期改进,以及 JustGiving 用于批发业务的基础设施自动化使其能够满足峰值时期的需求。

第二章介绍了各种版本控制工具与实践。读者对于 Windows 世界中最常见的工具,例如 Git 或 TFS 将有一个初步的了解。作者指出了一些方式,可避免长期存在的分支,以及持续集成实践中的某些令人深恶痛绝的做法,例如特性的开关。这一章的最后对于包管理提出了一些建议,与 Linux 平台相比,这方面的实践对于 Windows 平台来说还比较新颖。第三章则为持续集成与构建自动化工具列举了一份非常详尽的清单,同时也提出了一些特定于.NET 平台的建议,帮助读者设置.NET 项目的结构(例如:“为每个组件或服务创建一个.sln 文件”)。第四章的重点在于部署管道,其中描述了一些常见的部署技术,例如蓝 / 绿部署和金丝雀部署、解耦文件的交付以及特性的激活,并介绍了如何实现数据库变更的自动化以及数据迁移。接下来,本书专门用一章的内容介绍了监控方面的内容,作者首先鼓励读者不要将监控工作单纯地理解为对性能计数器结果的收集(尽管在 Windows 平台上这是获取各项指标最常见的做法),并采用其他监控与应用性能管理方式,实现日志的聚合,让开发者能够对指标进行收集。最后,作者对 Windows 平台上的基础设施自动化模式以及最佳实践进行了描述,与 Linux 平台上的基础设施自动化相比,读者仍然需要进行心态以及实现方式方面的转变。

InfoQ 与本书的作者进行了一次访谈,希望从访谈中更多地了解在 Windows 与.NET 平台上实施持续交付实践的现状。

InfoQ:你们为什么觉得有必要编写这样一本书呢?

Chris O'Dell:有一种已经被普遍接受的观点,即持续交付只适用于 Linux 平台,而在.NET 平台上无法支持这种开发实践,我希望能够打破这种偏见。没错,在.NET 平台上实现 CD 实践曾经是一个困难的任务,但时代已经不同了,微软已经作出了巨大的改进以拥抱 CD。

Matthew Skelton:我编写本书有两方面的原因:首先,当 Jez Humble 与 Dave Farley 在 2010 年推出了《持续交付》这本著作时,其中描述的许多模式在 Windows 与.NET 平台下都是极难实现的。自那之后,Windows 与.NET 平台上的自动化与 API 特性,以及相关的工具都已得到了极大地改进。其次,在过于几年中,我所合作过的许多客户都在使用 Windows 与.NET 平台,因此,我也留意到了对于使用这些技术的许多组织而言显得比较常见的一些做法。通过编写这本书,让我能够有效地将从中学到的思想以及见解组织在一起。

InfoQ:你们希望读者从本书中能够得到哪些收获?

Chris O'Dell:希望本书能够推动读者开始尝试在 Windows 与.NET 技术栈上实施持续交付实践。

Matthew Skelton:在 2016 这个时间点上,在 Windows 与.NET 平台上实现持续交付不仅仅是能够做到的,并且实际上是非常便捷的,至少从技术角度来说是如此!

InfoQ:长期以来,Windows 与.NET 环境在持续交付与 DevOps 工具和支持方面始终落后于 Linux 世界。这方面的差距如今是否已经完全消失,还是说目前仍有某些领域显得不够成熟?

Chris O'Dell:对于 ASP.NET 与.NET Framework 的最近几次修订引入了一些架构上的变化,它让 web 应用的部署变得简单许多,因为所有必需的包都可以包含在所部署的文件中。随着.NET

Core 的出现,部署将变得更为方便,因为.NET 与 Windows 之间不再存在着必然的绑定了。

Matthew Skelton:最大的不足之处是对于容器的支持。自从我们编写本书(自 2015 年 8 月起)以来,微软又取得了几项重大的进展,包括可运行在 Linux 上的 SQL Server!,在 Windows 平台上对于 Docker 的支持,以及 Windows Nano 等技术的出现。能够在 Windows 这个舞台上看到这么多创新的举措真是太好了,很遗憾我们无法将这些东西加入本书,否则我们永远也完不成这本书了。

InfoQ:从另一个角度来看,你们认为有哪些 Windows 与.NET 的功能是 Linux 平台所不具备的吗?

Chris O'Dell:恐怕我无法很自信地回答你这个问题,因为我在 Linux 平台上所投入的时间没有在 Windows 平台上那么多。

Matthew Skelton:我相信.NET 是一个优秀的运行时,因此看到像 OSX 与 Linux 这些非 Windows 的操作系统也能够通过.NET Core 支持这个运行时真是太棒了。而在 Visual Studio Code 上实现的多平台支持也是个好消息,因为每个人都将能够开始利用 Visual Studio 的丰富特性。

InfoQ:Windows 与 Linux 平台上的运维文化曾经具有极大的不同,这也反映出不同操作系统之间的不同哲学。在你看来,Windows 上的文化对于持续交付的启动是否会带来一系列不同的挑战?

Chris O'Dell:虽然我对于 Linux 没有足够的经验以进行完整地比较,但我认为结论很可能如此。

虽然许多公司内的 CD 实现都能够应用 Windows 与.NET 开发栈,但以我所见,在 Linux 服务器上的实施还提供了监控、指标以及日志记录等方面的工具。

Matthew Skelton:在某些组织中依然存在着传统的只用 Windows(或只用微软)技术的文化,但我们已经开始看到一些更偏向实用主义的做法出现,人们开始钻研其他方面的技术,尤其是在辅助性工具这一领域(包括日志记录、指标分析以及监控等等)。

InfoQ:某些组织同时具备 Linux 与 Windows 这两个平台上的生态系统,对他们来说,实施持续交付的最佳方式是什么?是应当将他们的实现尽量统一起来,还是应当分别看待这两个不同的生态系统呢?

Chris O'Dell:这取决于他们选择某一种特定实现的原因,以及为此提供持续性支持的能力,然后再选择对他们来说最佳的实现。

Matthew Skelton:你不能简单地说某种方式是“更好”的,这种说法并不恰当。重点在于,团队需要找到合适的工具,并有足够的时间去钻研及学习(通过使用指标及日志记录),才能了解哪种方式是他们是最合适的。

InfoQ:在你看来,持续交付在 Windows 上的短期、中期以及长期发展中的哪些方面是最令你感到兴奋的呢?

Chris O'Dell:.Net Core 将成为.NET 平台上的游戏改变者,.NET Framework 与 Windows 平台的分离使.NET 平台能够招揽大量新开发者的青睐,并实现各种不同的部署策略。此外,由于我主要使用云服务,因此我也十分期待 Windows Nano 的出现。它将减少镜像的资源占用,希望这能够提高镜像的设置速度。

Matthew Skelton:对容器的支持以及 Windows Nano 等轻量级 host 的出现将为使用 Windows 平台的团队带来大量丰富的选择。很明显,我们也将看到 Azure 平台上的持续创新。我也期待像 AppVeyor 以及 Octopus 等工具能够进一步地进行演变,以支持 Windows、.NET 与 Azure 平台上的更多特性。

查看英文原文Q&A on Continuous Delivery with Windows and .Net

.NETWindowsC#Windows AzureDevOps