Azure Devops所涉及的必须了解运用求职的重要服务

介绍Devops的概念、特性与流程以及神州数码云基地devops的最佳实践。从沟通协作、CI/CD、微服务、基础设施与代码、监控与日志记录、Paas、版本控制等角度，对比分析AWS、Azure、Github对devops的工具支持。

AWS、Azure、Github的DevOps支持工具分析

作为软件开发团队，我们知道拥有合适的开发工具是多么重要，毕竟，我们才是在各种开发工作中使用各种开发工具的人。现在，随着越来越多的公司进行数字化转型，开发应用程序的要求越来越严格，软件团队也要求越来越敏捷，这就需要开发和运营团队的更加密切地进行合作，以提高他们的构建速度，比以前任何时候都能够交付更新、更快、更好的解决方案。

众所周知，这就是DevOps实践的来源，用敏捷方式交付是软件开发速度不断增长、质量不断优化的关键，这也是我们所期待的，但是什么样的DevOps工具适合这项工作呢？当开发团队有更多选择的时候，我们怎么知道所使用的工具是最合适的呢？

目前海外市场上对DevOps支持相对比较完善的有AWS、Azure和Github，我们来看看他们分别对DevOps的支持如何、有何异同，对比分析他们如何支持DevOps的。

第一章 认识DevOps

一、概念定义

首先DevOps并不是某一种新型的技术和理论成果，而是一种集文化理念、实践操作和应用工具于一体的企业研发流程和模式，也是一种促进软件企业高效开发的方法论，其目的是提高组织高速交付软件和服务的能力，DevOps与传统的开发流程和基础设施管理方法相比，能够帮助组织更快地开发和优化产品，进而这种方法流程就进一步提高了企业研发团队的开发效率和速度，能够使企业更好地服务于客户并在市场上更有竞争力。

二、DevOps原理

1．DevOps

在DevOps开发流程和模式中，开发团队和运营团队会协同合作，或者合并成一个独立的团队，可以将其命名为“DevOps团队”，团队里面的工程师可以统一称呼为“DevOps工程师”，DevOps工程师会在软件的整个生命周期中互相协作，致力于服务其他项目研发团队，提高业务研发团队的软件开发效率，让他们能够将精力聚焦于项目业务和代码，由于“DevOps团队”是开发运营团队的集合，所以DevOps工程师需要具备不限于某一单一领域的专业技能。

2．DevSecOps

在某些特殊的DevOps模式中，质量保证团队和安全团队也会与开发运营团队（DevOps团队）一起协作，并紧密结合在一起，服务于整个软件研发周期，这个时候如果安全和质保是整个团队的工作核心时，“DevOps”就会变成“DevSecOps”。

3．技术&工具

DevOps的实施需要一系列工具的的支持，DevOps团队成员需要掌握并快速地使用它们来支持开发团队开发软件程序，这些工具还可以帮助工程师们独立地完成通常需要其他团队协作才能完成的工作，比如部署代码和预置基础设施，从而进一步提高团队的工作效率。

三、传统开发模式下的困境

1．老旧刻板的瀑布模式

传统的瀑布式开发模式自首次提出至今已有了快半个世纪的时间了，虽然比较传统，但是仍然是比较主流的开发模式之一，在传统的瀑布式开发模式下，开发团队必须严格遵守该模式下预先计划的需求分析、设计、编码、集成、测试、维护的步骤阶段进行工作，步骤成果作为每一个阶段进度的标准，开发人员只要拿到一份描述详尽的需求文档，不需要反复确认需求，开发人员也不会被打断思路，专心Coding，然后按照步骤严格控制产出物的质量，然后测试部署上线就行了。

在这种理想的情况下，瀑布流可能是开发团队首选的开发模式，但是理想归理想，现实却是变化莫测的，显然老旧刻板的瀑布流开发模式无法满足现实的开发场景，最终导致老旧刻板的瀑布模式更适合小作坊式较为稳定的开发项目，各个阶段之间的隔离使得瀑布模式下开发团队彼此信息难以同步，甚至在不同阶段中让某些信息被刻意阻断，前期需求的变更更是让开发人员的工作量巨大，整个项目的进行必须在每一个阶段完美结束才能逐步推进，某个阶段没完成的话，就无法进行下一个阶段的工作，所以整个项目的周期通常会很长。

2．不完美的迭代模式

在迭代开发模式下，项目被划分成多个短小的、定期的“小项目”或者迭代周期，每一个迭代周期内都完整地包括了需求定义、需求分析、开发编码和测试的工作，和传统的瀑布流式开发模式相比，迭代式开发虽然没有瀑布式如此刻板，也不要求每个阶段都要完美结束才能进行下一步，而是以一种循环往复的迭代来弥补前期的不足，并完成一个“不完美的项目”甚至提交上线，最后在用户的吐槽声中，基于这个“不完美的项目”产出的“不完美的产品”进行优化迭代。

这种开发模式虽然弥补了瀑布模式的一些缺点，并具有较高的成功率和效率，但是这种模式容易造成系统功能的堆叠，每一次迭代周期遗留下来的问题到最后会积少成多，最后的正式发布的时候漏洞百出，陷入无限加班的尴尬境地，所以这种开发模式无异于在不稳定的地基上建造高楼，不断地在还没有建好的楼层上面加层，最终越来越危险，在最后一次迭代的时候，却发现前期的“不完美”已经让系统病入膏肓需要改造的时候，却由于系统上已经叠满了各种正在工作的功能而无从下手。

3．风险驱动的螺旋模式

螺旋模型其实就是在瀑布模型的基础上引入风险评估的阶段化应用，在项目的每一个迭代周期中都使用瀑布模型并引入严格的项目风险评估，该模型下项目的每一个阶段都包括需求定义、风险评估、开发实施和评审，每完成一个迭代项目就推进一个阶段，风险评估的引入使得项目成员对项目每一个阶段中潜在风险都有所了解，并对其采取防范措施，也能够避免迭代模式下迭代周期中“不完美”的叠加导致的问题，最重要的是每个阶段的风险评估让项目中所有潜在的风险都能够被确定并被避免，降低了项目的总体风险，所以螺旋模型比较适合庞大、复杂、周期加长且高风险大型项目。

可是正因为如此，螺旋模型在项目中的应用就非常局限，首先需要项目经理拥有丰富的项目管理和风险评估经验和专业知识，对项目来说，使用螺旋模型的项目最好是大规模的高风险项目，且风险评估的执行不会增加项目成本，否则螺旋模型反而会增加项目的成本，毕竟每个阶段的瀑布流必然会增加项目周期，而且对于利益相关者来说，项目每个阶段中评估的风险需要让相关人员接受并认可这种风险的存在，故而企业内部项目最佳，这些限制条件就使得风险驱动的螺旋模型的应用受到很大的限制。

第二章 神州数码云基地的DevOps实践

一、文化理念

首先在文化理念方面，神州数码云基地一直秉持“工程师文化”，并将工程师文化注入到神州数码云基地的团队建设中，在DevOps方面，也一直致力于消除传统软件开发模式中互相独立的软件开发模式和运营团队之间的沟通壁垒，打破彼此之间传统架构中固有的“隔阂墙”，实现两个团队的融合统一和协作，实现两个团队的融合统一和协作。

在DevOps开发模式下，神州数码云基地打破了开发和运营团队之间的独立性，工程师身兼两职，或者利用DevOps流程，两个团队彼此携手合作，共同致力于提高开发人员的生产力，同时提高运营团队的可靠性，力求打破团队限制频繁沟通、提高效率，改善客户服务的质量，在这种环境中相关团队或人员能够完全掌握自己的服务，并且能够经常越过自己既定的角色和职能的传统工作范畴，思考最终用户的需求并解决用户的需求。

此外，我们也期望DevOps团队也可以和质保和安全团队进行合作，当然其他团队也可以，总之在DevOps模式中，无论团队的组织架构如何，相关团队都会将自己的职能贯穿到整个开发和基础设施生命周期中。

二、实践说明

DevOps对软件开发最基本的实践经验就是要实现快速并频繁的的小规模更新和发布，这也是我们神州数码云基地为解决客户快速更新所提供的解决方案和实践，所以在神州数码云基地的DevOps模式中，模块化的微服务架构既能够提升软件自身的灵活性，也可以提高团队开发的灵活性，同时也能够加速团队创新的步伐和效率。

然而，软件中微服务的架构方式所导致的较高的发布和部署频率必然会导致运营的挑战和压力，对此神州数码云基地在DevOps实践经验中采用持续集成和持续交付来解决运营压力的问题。未来安全机制的导入也能让团队以安全可靠的方式快速交付软件。

另一方面，神州数码云基地通过集成相关工具进行监控和记录来帮助工程师追踪和监控应用程序和基础设施的性能指标，以便工程师能够及时发现问题并找到问题的根源，进而在短时间内予以解决。

三、DevOps实践

1．敏捷管理

在项目及开发模式方面，神州数码云基地采用了敏捷项目管理及开发模式，在工具上采用项目管理上常用的Jira作为敏捷项目管理工具，使用Jira自有的看板和Scrum两种方式来支持工作规划和跟踪、代码缺陷以及问题报告的工作，在项目文档管理及团队协作和知识共享方面，神州数码云基地使用Confluence作为协作及知识共享平台。

2．微服务

DevOps开发模式中倡导将软件拆分为多个微服务的架构，神州数码云基地对所有遵循DevOps开发模式的项目都进行微服务架构的改造进而推动微服务架构和DevOps开发模式的落地实践，截止目前神州数码云基地已经将所有进行中的进行了微服务改造，在短短半年时间内形成了共计上百个微服务项目。

为此，神州数码云基地基于Rancher搭建了共享的自有云容器平台来为项目的微服务架构改造和DevOps实施方案落地提供基础设施资源的支持，可以自动在一个容器集群中选择一个工作容器供使用，用户可直接在容器平台上运行项目的微服务，同时为开发工程师提供代码存储、测试和部署的环境平台，并划分出开发、测试和生产三大环境供开发者使用。

3．持续集成&持续交付（CI/CD）

为缓解微服务架构带来的运营压力，神州数码云基地采用了DevOps开发模式所提倡的持续集成和持续交付来解决运营压力，持续集成（CI，Continuous Integration）是一种软件开发实战经验，也是DevOps开发模式所极力倡导的最佳实践，其中所谓的“持续”并非常规理解的“一直执行”，而是“随时可以执行”，将集成视为一直常态，时刻准备着，在采用持续集成方法的时候，开发人员可以随时将他们提交的代码变更合并到项目团队的中央代码存储库中，系统在获得变更的信号之后就会自动触发构建和测试的流程操作，持续集成的目的就是通过快速的集成和测试，以更快的速度看到变更导致的效果，进而更快地发现并反馈其中存在的错误，在更短的时间内将错误修正过来，以保证最终合并的代码没有问题，并缩短验证和发布新软件更新所需要的时间，提高软件质量。

在持续集成（CI）的基础上，我们通过持续部署和持续交付（CD）进一步拓展持续集成，以便软件构建在通过所有测试时自动部署并持续交付到最终用户手中，得到用户对新版本的最新反馈，并快速处理了关于新版本新功能的任何意外缺陷，在这样CI/CD的流程中，最后一步的构建产生软件包后将自动部署到开发人员想要的环境中。

基于上述流程，神州数码云基地对此集成Gitlab和Jenkins作为执行上述CI/CD流水线的工具，并集成第三方开源代码扫描工具SonarQube作为代码质量检测平台，将开发人员每次提交的代码的质量数据反馈到DevOps管理平台中，以确保最终合并到主分支的代码的综合质量。

4．版本控制

版本控制作为DevOps开发模式基本实践操作，帮助团队协同工作，合理的版本控制策略可以帮助开发团队明确功能开发任务的划分，提高团队协作性，也可以在意外的情况下通过版本的回滚来降低意外事故产生的负面影响，对此神州数码云基地使用Git作为版本控制工具，并基于Gitflow分支管理规范结合基地项目情况进行了调整。

5．基础架构即代码

基础设施即代码（IaC）是DevOps开发模式中倡导的基础设施最佳管理实践，通过代码和软件部署技术将基础设施代码化并加以预置和管理，同时开发人员和系统管理员通过云端API驱动模式用代码的形式与基础设施进行大规模的交互和管理操作，进而摆脱了繁杂的手动配置和资源管理工作，进一步提高团队的运营能力和效率。

在之前传统模式下，神州数码云基地所有项目都各自申请VM资源搭建项目平台，很多VM的资源利用率不高，同时项目发布阶段，VM环境远远比容器复杂，发布和运行效率都很低，所以神州数码云基地在这种背景下决定向DevOps开发模式转型，为此神州数码云基地基于第二代的Rancher容器管理平台搭建了基地共享的云容器平台，并从各个项目组中回收VM资源，统一管理，并将容器平台和DevOps实施方案相衔接。

所以在共享的容器平台的基础上，为了便于基础资源的预置和管理，神州数码云基地利用定义和运行多容器Docker应用程序的工具——Docker Compose来为应用程序预置资源及服务，用户使用YAML文件来定义应用程序的环境。

6．平台及服务

“平台即服务” (PaaS) 是指一组基于云的服务，可帮助企业用户和开发人员以本地部署解决方案无法企及的速度创建应用程序。对此神州数码云基地面向开发人员和管理人员开发出了DevOps一站式集成管理平台，并集成了Gitlab、Jenkins、SonarQube等相关工具，通过平台开发人员可以方便地创建项目，同时Gitlab、Jenkins等集成的平台工具中也会创建同名项目，用户无须申请虚拟机或对资源进行预置和管理，只需要按照自己的项目情况修改Jenkinsfile文件、Dockerfile、Deploy,yaml/Docker-compose.yaml文件，提交代码并通过测试即可部署应用程序，后期项目和资源的监控DevOps平台和容器平台都会自动完成。

7．监控&记录

DevOps最佳实践经验中倡导通过对软件服务和基础设施资源进行实时监控和告警来实现来及时了解其服务基础设施运行的情况，解决系统出现的异常问题，及时做出行动并解决问题，对此神州数码云基地采用第三方开源监控和日志分析工具——Zabbix、Grafana、Elasticseach、Kibana和Filebeat来对运行在容器平台的服务和底层的基础设施资源进行实时监控和告警。

第三章 公有云对DevOps支持对比

前文中大概介绍了我们神州数码云基地利用第三方开源DevOps工具搭建的DevOps实施方案和实践，没有使用到基于云的DevOps支持工具，当然这也不表明公有云对DevOps的支持不友好，AWS、Azure等云厂商对DevOps也提供了非常丰富的工具，下面来简单介绍并对比一下AWS、Azure以及流行的面向开源及私有软件项目代码托管平台Github如何支持DevOps开发模式。

一、AWS对DevOps支持分析

1．AWS的DevOps解决方案

在DevOps开发模式中，每一个阶段都有一系列的开发工具对DevOps流程予以支持，帮助团队建立工作流程来快速可靠地面向客户进行创新业务支持，借助着一系列的工具体系，团队可以从繁琐的手动作业中解放，整体提高团队的工作效率，大规模管理基础设施和环境，工具是工程师团队实现DevOps理想的高效开发的杀手锏。

针对DevOps开发模式，AWS提供了非常全面且灵活的服务工具，并结合AWS云资源配合使用相关服务，各大企业可以结合自身情况合理选择AWS相关工具，在DevOps最佳实践经验的指导下完成DevOps研发体系的构建，快速、可靠地完成软件产品的开发和交付。从流程上来讲，AWS所提供的一系列工具和服务可以划分为基础资源配置管理、软件代码集成部署、软件发布流程自动化及最后软件和基础设施性能监控和告警。

2．工具分析

(1) 微服务

对于DevOps开发模式倡导的微服务架构最佳实践，AWS也提供了针对微服务的利用容器和无服务计算来构建和部署微服务软件架构的工具服务——Amazon ECS（Amazon Elastic Container Service）和AWS Lambda。

1）Docker生成平台（Amazon Elastic Container Service）

Amazon Elastic Container Service (ECS) 是AWS针对微服务架构提供的一项高度可扩展的高性能容器管理服务，支持Docker容器，开发团队能够在托管的 Amazon EC2 实例集群上轻松运行应用程序。

2）无服务器计算（AWS Lambda）

类似于Amazon Elastic Container Service (ECS)，AWS Lambda也是针对微服务架构提出的计算服务，于2014年推出，使用AWS Lambda服务，开发团队无须配置和管理服务器即可运行代码，可以更加专注于自己的业务，全称无须任何人为管理，需要注意一点的是，AWS Lambda等无服务器计算服务并非真的没有服务器，而是将复杂的服务器管理工作进行自动化并未用户提供更加贴近业务的接口，将用户从服务器管理工作中解放，实际上采用的技术是AWS自研的Firecracker 技术，对开发用户来说更加安全和快速。

(2) 持续集成&持续交付（CI/CD）

AWS对持续集成（CI）和持续交付（CD）提供了AWS CodeBuild、AWS CodeDeploy 及AWS CodePipeline等工具来构建CI/CD工作流，让开发团队能够安全地对软件开发源代码进行存储和版本控制，并在自动构建、测试软件后将其部署到AWS云环境或者本地环境。

AWS CodePipeline是AWS对DevOps开发模式支持的一项最基本的功能，其很大程度简化了开发团队管理CI/CD工具的方式，能够与 Jenkins、GitHub 和 CodeDeploy 等第三方开源工具或AWS服务工具集成，是开发团队能够非常直观地看到从构建到生产的软件开发全流程。

1）统一的CI/CD 服务（AWS CodeStar）

AWS CodeStar是AWS推出的一体化的持续集成和交付的工具，开发人员能够利用Codestar快速建立完整的持续集成和交付工作流，进而快速开发、构建和部署软件，并支持和兼容其他CI/CD服务和工具，如下图所示。

2）软件发布工作流（AWS CodePipeline）

AWS CodePipeline是AWS为开发者提供的一种CI/CD服务，开发人员可以根据自定义的构建发布流程模型，以此来构建、测试和发布代码，快速可靠地提供软件功能和基础设施的更新。

3）构建和测试代码（AWS CodeBuild）

AWS CodeBuild是一项托管的构建服务，用于编译源码、运行测试及生成待部署的软件包，无需配置即可管理和拓展自己的构建服务器，值得强调的一点是CodeBuild可以并行处理多项构建任务，开发人员无须在构建任务的时候等待。

4）自动化部署（AWS CodeDeploy）

AWS CodeDeploy是AWS推出的自动部署服务，能够将代码自动化地部署到任何资源中，不仅仅AWS自己的Amazon EC2，还包括本地资源，开发团队通过CodeDeploy服务可以轻松快速更新软件功能，避免在软件部署的过程中出现意外导致的失败，同时也能够简化软件的更新发布的工作。

(3) 版本控制

在DevOps模式实践中，版本控制是较基本的实践，可以帮助团队协同工作，便于给开发团队成员划分任务，以版本的形式存储所有代码，以便在意外情况下进行恢复。

AWS CodeCommit是AWS推出的用于源代码版本控制的私有Git托管服务工具，通过该服务工具，开发团队能够方便地私有Git代码仓库，并且能够与用户现有的第三方Git工具进行兼容。

(4) 基础设施即代码

DevOps开发模式中倡导的基础设施即代码是基础设施的最佳管理实践，AWS对此也有相关的管理工具来使用代码和模板化软件部署技术将AWS基础设施资源进行代码化管理和预置，同时能够对基础设施资源进行大规模监控和合规性追踪。

1）模板化的基础设施配置（AWS CloudFormation）

AWS CloudFormation是AWS向开发人员提供的在AWS上实践基础设施即代码的最主要的服务工具之一，通过该服务开发团队能够预置的模板定义、配置和管理AWS云资源，并且通过有序、可预测的方式对资源进行配置和更新，这种模板化的操作能够有减少团队重复性的劳动，提高效率。

2）Chef 配置管理（AWS OpsWorks）

AWS OpsWorks是AWS提供的完全托管的配置管理服务工具，提供 Chef 和 Puppet 的托管EC2虚拟机资源，两者都是自动化管理平台，都允许用户通过代码来自动化管理和配置基础设施资源，借助AWS OpsWorks，开发团队可以使用使用 Chef或Puppet 自动完成所有 EC2 实例或本地计算环境中的服务器配置、部署和管理，AWS OpsWorks分别提供了一下三种工具：

3）配置管理（AWS Systems Manager）

AWS Systems Manager是AWS提供的通用型管理服务，通过AWS Systems Manager服务工具，开发团队可以简单地配置和管理AWS EC2资源实例、本地资源，还包括其他云环境中基础设施资源，还可以帮助开发团队自动收集软件服务及资源信息，进而定义并跟踪资源信息，防止出现错误偏差，确保资源的合规性。

4）策略即代码（AWS Config）

AWS Config是AWS提供的一种完全托管的服务，为用户提供AWS资源库存、配置历史记录和配置更改的通知服务，以确保资源的安全性和方便管理，开发团队借助AWS Config可以找到现有AWS资源并查看现有资源的详情及其配置信息，同时Config Rule提供规则的创建，进而实现对现有AWS资源的查看管理、合规性检查、安全分析、资源变更管理和故障排除。

(5) 平台即服务

平台即服务（PasS）是一种云中的完整的开发和部署环境，为开发用户提供完整的软件研发平台，用户可以使用其中的资源进行不同类型软件的开发交付，并通过安全的网络连接访问这些云资源。

对此AWS推出了专门的运行和管理软件应用的服务工具——AWS ElasticBeanstalk作为开发支持服务，通过AWS ElasticBeanstalk服务，开发人员无须使用其他工具对资源进行预置和管理即可部署软件程序，是在AWS上部署应用最快和最简便的方式，用户只需要上传自己的程序代码即可，ElasticBeanstalk会自动处理后续的部署工作，包括从资源预置到最后的应用监控的所有环节，用户也能通过ElasticBeanstalk完全控制底层的AWS资源并通过安全连接访问。

(6) 监控&记录

对资源和服务的监控方面，AWS推出了相应的服务工具对此予以支持，提供了Amazon CloudWatch、AWS X-Ray和AWS CloudTrail三个主要服务工具。

1）云和网络监控（Amazon CloudWatch）

Amazon CloudWatch是AWS监控服务工具之一，是一项面向DevOps工程师、IT项目经理的针对AWS运行资源或在AWS上运行的程序的监控服务，其通过日志、指标和事件的形式收集监控和运营数据，为用户提供统一的视图以查看软件程序、基础设施资源及范围内容的性能数据变化和运营情况，进而为开发团队优化资源利用提供数据参考，同时开发团队也可以利用CloudWatch检测环境的异常行为、设置告警、排查问题以确保环境和系统运行正常。

2）分布式跟踪（AWS X-Ray）

AWS X-Ray是AWS是针对微服务架构推出的帮助开发人员分析和调试分布式软件架构的服务工具，通过AWS X-Ray，开发团队可以了解软件程序及其底层服务的执行方式，从而识别和排查导致性能问题和错误的根本原因。

3）活动和 API 使用情况跟踪（AWS CloudTrail）

AWS CloudTrail是AWS针对AWS账户活动记录的日志服务，用户通过AWS CloudTrail可以对AWS账户进行监管、操作审核、风险评估和合规性检查，该服务中通过CloudTrail事件的概念来记录AWS账户的活动信息，包括AWS账户的用户、角色或 AWS 服务执行的操作等。

3．工具体系

从整体来看，在DevOps整套流程中，AWS对其的支持比较全面，从最初的开发到最后的运营都有相应的支持工具，包括基础设施的管理和预置，都给予了很全面的支持，开发者可以用AWS开发工具完成这个DevOps 的搭建和实践。

二、Azure对DevOps支持分析

1．Azure DevOps

Azure DevOps是微软2018年发布的一款产品，提供Git仓库托管、项目管理、自动构建、软件包管理、测试和发布管理功能，其源自VSTS(Visual Studio Team Service)，是微软将其结合其他工具后并更名的产品，与VSTS(Visual Studio Team Service)相对应的还有一个孪生产品——TFS(Team Foundation Server)，只是TFS是本地版本，所以Azure DevOps也有两个服务版本，分别是在Azure云平台托管的云版服务——Azure DevOps Service和在本地自托管的本地版服务——Azure DevOps Server，Azure DevOps主要的功能组件如下图所示：

2．云版本&本地版本

Azure DevOps云版和本地版，云版本为：Azure DevOps Service，地址：http://dev.azure.com，使用微软账号登录；本地版为：Azure DevOps Server，需要下载安装和托管，地址为：https://azure.microsoft.com/zh-cn/services/devops/server/

云版本和本地版本的对比如下：

3．Azure的DevOps支持方案

Azure DevOps不仅与Azure云资源之间有密切的集成联系，还能够与第三方DevOps工具相兼容，为开发团队提供了一套基于Azure的DevOps开发工具，以构建专属的开发工作流，开发团队可以使用Azure相关工具或者选择使用第三方开源的DevOps工具来实现自己的DevOps实践方案，Azure对DevOps开发模式的支持链路是最广的，从项目最初的需求和项目管理到开发集成和资源管理到最后的监控服务都能够予以一定的支持。

4．Azure DevOps提供的服务工具

首先Azure DevOps毫无疑问地也提供了集成功能，用户可以通过浏览器或者IDE客户端进行访问，Azure DevOps为用户提供了如下服务工具：

除上述工具外还有自定义的团队仪表盘、内置的信息共享平台及可配置的通知工具，此外，Azure DevOps具有很好的兼容和拓展性，能够与其他第三方服务工具（如Trello、Slack和Campfire等）集成，以此来支持用户自定义的拓展。

5．工具分析

(1) 敏捷管理

不同于AWS的是Azure DevOps提供了项目开发前期的需求和项目管理工具——Azure Boards，使用Azure Boards提供了一组敏捷开发工具，该服务类似于Jira，使用Kibana和Scrum的两种敏捷方法来支持工作规划和跟踪、代码缺陷以及问题报告的工作。

Azure Boards提供了丰富的项目管理功能，包括对看板和Scrum的本地支持、可定制的仪表板和集成报告。

(2) 微服务

类似于AWS，对于DevOps开发模式所倡导的微服务架构最佳实践，Azure也提供了针对微服务的无服务器计算来构建和部署微服务软件架构的工具服务——Azure Functions和Azure Kubernetes。使用Azure Functions 提供无服务器计算服务，使用Azure Kubernetes Service服务 (AKS) 提供无服务器 Kubernetes（一种整合的持续集成和持续交付 (CI/CD) 体验）以及企业级安全性和治理，使用Service Fabric 提供了一种高效构建、部署和升级微服务的基础结构。

1）Azure Functions

Azure Functions 是微软推出的一种无服务器计算服务，用户使用它无需显式预配或管理基础资源就可以运行事件触发的代码。开发团队通过 Functions（一个事件驱动型无服务器计算平台，还可以解决复杂的业务流程问题）更加高效地进行开发，在本地构建和调试，而无需额外的设置，在云中大规模部署和操作，并使用触发器和绑定集成服务。

2）Azure Kubernetes Service

Azure Kubernetes Service (AKS)是微软推出的管理托管的 Kubernetes 环境的服务，通过AKS，用户在无需容器相关知识的背景下也可快速、轻松地部署和管理容器化的应用程序，此外该服务通过利用 Kubernetes 的优势进行自动预配、升级、监视和缩放，无须程序脱机即可消除了正在进行的操作和维护的负担。

(3) 持续集成&持续交付（CI/CD）

和AWS类似，Azure也提供了构建和发布服务工具，支持软件的持续集成&持续交付（CI/CD）任务流，用于构建和测试软件应用，进而将其部署到预期目标中，Azure DevOps对此提供了如下服务工具：

1）Azure Pipelines

Azure Pipelines是Azure DevOps提供的一项服务工具，能够自动构建和测试项目代码并提供给其他用户，适用于任何语言或项目类型，Azure Pipelines将CI&CD结合在一起，以不断和一致地测试和构建代码，并将其传送到任何目标，并可独立使用，其有两种方式：

2）Azure Test Plans

Azure Test Plans是Azure面向测试人员提供的服务模块，提供测试计划、测试套件及测试用例的管理功能，可执行手动/探索性测试和持续测试等，其中手动测试整体流程及方法和相关角色如下图所示。

此外Azure还针对测试执行推出了辅助插件——Test Explorer，通过该插件，用户可以之间安装在浏览器上进行线上测试，记录Bug。

3）Azure Artifacts

Azure Artifacts是Azure DevOps为开发团队提供的公共包管理服务平台，通过Azure Artifacts开发团队可以共享团队内部的私有包源，并将包源集成到用户自己CI/CD流水线中。

4）DevOps Starter

类似于AWS的CodeStar，DevOps Starter是Azure推出的一体化的CI/CD服务工具，提供一种简化的服务体验，用户使用该服务可以自动创建Azure资源，并自动配置 CI 生成和发布触发器，用于将代码更改部署到存储库，完成初始配置DevOps模式中的CI/CD流水线的工作，最后在仪表盘中提供整套方案的监控视图。

(4) 版本控制

同样，Azure DevOps也提供了版本控制的基本服务，推出了Azure Repo，即Azure Repository，对代码进行统一的托管服务，在 Azure DevOps 中可以有两种托管方式，一种是 git（分布式版本控制系统），另一种是 TFVC（集中版本控制系统）。

(5) 基础架构即代码

Azure在基础架构即代码方面，推出了Azure蓝图、AzureAutomation来以代码化的描述性方式定义符合要求的可重复可治理的环境资源，由于Azure良好的兼容性，Azure还支持第三方工具。

1）Azure 蓝图

开发团队通过Azure蓝图可以快速生成和构建新的资源环境，并确保新环境的合规性要求。由于Azure蓝图是由Azure分布于全球的Azure Cosmos DB提供支持，所以无论既定的Azure 蓝图应用于哪个Azure区域，都能够保障对象访问的低延迟、高可用以及对象之间的一致性。

2）Azure Automation

Azure还提供了基于云计算的自动化和配置服务Azure Automation，可在Azure和非Azure环境中提供一致的管理。它由流程自动化、更新管理和配置功能组成，旨在帮助用户减少错误，并减少基础设施部署所花费的时间。Azure Automation还提供对维护和合规性运行的自动控制。

3）开源工具

Azure还完全支持 Azure 资源的开源工具，如Ansible、HashiCorp和Terraform等，都可以用来创建、管理和更新基础设施资源。

Azure能够良好地支持多种用于配置管理的 DevOps工具，包括 Ansible、Chef、Puppet，也可以使用Azure 自动化来管理整个系统的资源配置，以强制达到所需的状态、推出配置更新以及自动解决意外更改和问题。

(6) 平台即服务

和AWS推出了专门的运行和管理软件应用的服务工具——AWS ElasticBeanstalk类似，Azure Service Fabric是微软推出的面向微服务架构的分布式系统平台化服务，通过该服务，开发人员可以轻松打包、部署和管理微服务应用及容器，而将精力集中在关键工作中，Azure Service Fabric只在帮助用户解决服务构建和运行方面的问题，同时提高基础设施资源的利用率，协助开发团队使用微服务来解决项目的业务问题，并且在微服务架构下，团队可以使用任何开发语言进行开发，此外用户可以利用其所提供的内置API更加方便地生成微服务。

(7) 监控&记录

Azure为用户提供了Azure Monitor服务工具来一站式监视基础结构运行状况，获取最新监控数据，通过第三方可视化工具Grafana、Kibana和自有的可视化仪表盘进行监控可视化呈现，从Azure云资源及本地环境中获取检测数据并加以分析处理，Azure Monitor可以最大程度的提升软件程序和基础设施的性能，同时在很短的时间内就能识别问题。

6．工具体系

Azure对DevOps的支持也比较完善，其独特之处就是提供了独立的敏捷开发管理工具Azure Boards，用户不需要采用第三方的任务管理，所以Azure从需求规划到最后的运营都提供了可用的工具，不足的是Azure 在“基础设施即代码”方面支持相对较弱，但是其强大的第三方兼容性很好地解决了这方面的问题，用户可以集成第三方工具完成基础设施的配置管理。Azure对DevOps流程的支持如下：

三、Github对DevOps支持分析

1．Github的DevOps解决方案

Github作为面向开源及私有软件项目的托管平台，针对DevOps只在2019年推出了自己的CI/CD服务——Github Action，其他工具均可采用第三方工具集成，此外Github市场中提供了非常丰富的第三方开发的插件也可以支持DevOps开发模式实践，在此就不作为对比的范围一一列举了。

2．工具分析

(1) 持续集成&持续交付（CI/CD）

推出自有GitHub Actions服务创建自定义持续集成 (CI) 和持续部署 (CD) 工作流程，能够与 GitHub Package Registry 无缝集成，对开源项目免费支持，并且能够支持任何OS、任意开发语言、与任意云集成。

(2) 版本控制

在版本控制方面，GitHub 使用git分布式版本控制系统，托管各种git库，并提供一个web界面。

四、AWS、Azure和Github的DevOps支持对比

综上所述，AWS、Azure和Github都能够支持DevOps的实践流程，只是程度各有不同其中AWS对DevOps支持最全面，用户能够在用AWS开发工具完成整个DevOps流程实践，但是对敏捷项目管理支持不够，Azure具有很强大的兼容性，能够兼容很多第三方工具，并且支持敏捷管理，Github对DevOps支持较晚，在原有代码仓库属性的基础上仅与2019年推出了Github Action服务自定义创建CI/CD，能够与自身的GitHub Package Registry 无缝集成，对开源项目免费支持，并在自有插件平台Github Marketplace中有着丰富的第三方开发的工具为CI/CD提供支持。总体来看，AWS、Azure和Github对DevOps的工具和服务的支持工具对比如下：