有哪些好用的devops工具，适合中小企业开发？

Question

软件开发

企业开发

DevOps

ONES （研发管理工具）

PingCode（智能化研发管理工具）

有哪些好用的devops工具，适合中小企业开发？

如题

关注者

194

被浏览

130,985

34 个回答

专门做IT研运一体化解决方案的嘉为来啦。本回答由嘉为蓝鲸原创，商业用途请联系作者，非商业用途请注明出处，若觉得有帮助的话欢迎点赞收藏。

在回答题主关于devops工具有哪些之前，或许我们可以先来思考下，企业为什么提出需要员工熟悉devops工具？诚然，是因为企业先有了devops的业务场景，在实际产研过程中需要做到持续集成和持续部署，所以才会要求员工掌握对应场景所需要的工具。

PS. 关于devops概念的详细解释，可戳 ↓

一般来说，企业内的研发侧会更关注CI部分，而运维侧则更关心CD部分，然后组织间通过DevOps流程/工艺进行串联。所以严格意义上，并不存在只要使用了就等于实现了持续集成和持续部署场景的“CI/CD工具”，更多只是企业为了支撑CI/CD场景而使用的一些研发运维工具，转而被大众默认为是CI/CD工具。

但是国内不同企业间业务规模、运作模式、交付频率和技术水平上的差异可不是一星半点，这就导致了企业实际在CI/CD场景下所选择的研发运维工具也注定是千差万别的。而且企业使用场景越复杂，研运工具的能力要求和技术难度就越高；企业组织越膨胀，研运工具的使用数量和实践方法可能也会越多。接下来的内容是笔者参考和研究一些资料，以及结合企业经验的一些个人感受和理解，欢迎留言探讨：

一、没有最好的，只有最合适的

对于刚入门或者身处小型团队的同学来讲，如果要实现CI/CD场景，可能最经常接触到的就是像SonarQube、Jenkins、Nexus和Kubernetes等等的研发运维开源工具（关于开源工具的使用介绍，前面已经有很多的回答，这里也不再赘述啦）。

开源工具由于公开透明的特点，确实是吸引了不少IT同学，用得好的同学还能反哺优化工具本身，参与感十足。更何况相当数量的开源工具还是免费的，这对于普遍预算不足的小型产研团队来说，可真是天大的好事，而且对于规模小或者IT研发水平低的企业来说，确实也足够支撑CICD场景了。

但当一个企业逐步膨胀到了较大的规模，无论是人员数、业务量还是技术栈似乎都开始脱缰的时候，企业就必须考虑如何升级装备来引领和管理好IT组织这个庞然大物了。尤其是近年来不少传统企业也纷纷开始进行数字化转型，想要对自身IT组织进行DevOps转型。

在组织规模和作业模式都已经相对固化的大中型企业内部，他们更关注的DevOps改革价值点在于：如何能在不影响原有业务正常开展的情况下，尽可能地提升IT组织的管控能力和研运效能。而单纯的开源工具由于缺乏解决新人难入门、需求难统管、过程难管控、结果难度量等企业级管控问题上的“大局观”，在这时候往往就显得力不从心。

如何选择更适合的CICD工具，打造企业级的CICD工具集，也是很多大中型企业DevOps转型的万里长征第一步。

二、专业为大中型企业服务的研运一体化平台

咱们嘉为蓝鲸，是为政府、金融、能源、交通、制造和医疗等众多行业的大中型客户提供IT研发运营一体化平台的解决方案品牌。打造了涵盖企业IT研发、运维到运营全生命周期的产品体系，基于腾讯蓝鲸强大的PaaS能力，进行了产品重构和迁移，形成了数百款SaaS产品和软件，其中就包括了DevOps、ITOM、CMP、ESM和AIOps等细分领域。

一看到上面的产品体系图，可能很多同学就开始晕了，心想真的有必要做这么多研运工具吗？

部分同学因为入门时间比较短或者企业规模相对较小，所以还没遇到过非常复杂的CICD业务场景，自然难以想象要支撑起一家大中型企业的持续集成和持续部署场景，其实是需要非常繁多的工具支撑和非常细致的工程打造的。

而通过专业工艺为企业各类CI、CD和CO场景提供服务，正是嘉为蓝鲸“以科技之力助企业运营更智能”的企业使命。

三、大中型企业的CICD场景是怎么样的？

我们以一家大型集团S为例，看下他原来是怎么实现最基础的CI/CD场景的：

原来的集团S，总部成立了多个产品部负责各自数字业务产品的规划和设计，统一由总部研发处（自有团队+外包厂商）负责数字业务的研发和测试。

然后总部运维处加上环境配置脚本等文件打包成部署包，验证新版本可以在总部预生产环境成功发布以后，再按发布计划分发给多个分部的运维处，分别在各自预生产环境进行部署发布。均发布成功以后，才能同步部署到总部和各分部的正式生产环境，完成一次业务上线。

乍一看，CI/CD场景虽然流程麻烦但也还算简单易懂，应该开源工具也够用了吧？但实际长期运作下来以后，产品部、研发处和运维处都苦不堪言：

在CI场景中，由于需要满足多产品线的双周迭代需求和集团的统一管控要求，首先需要产品部可以对所有需求、代码和构建产物进行企业级管理以及跟踪每个需求的完成情况；其次需要保障研发处在研发过程中大规模、多并发业务的持续集成和持续部署能力；再然后还要保证产品线/厂商的研发过程都能遵循集团规范和经过足够质量验证。保证应用可以按时合规交付，才能满足集团S的CI场景基本需求。

在CD场景中，需要支持不同系统架构应用的快速发布（单体/竖井/SOA/微服务/分布式/ 云原生……）以及应用和部署包在不同环境的快速传输（跨网络和地域的环境、不同业务用途的环境）摆在运维处面前的难题是，既要解决手工发布的不标准和低效率，又要解决网络和物理隔离的传输问题，还要保障整个业务上线过程中应用版本不被恶意纂改。保证业务可以按时上线和平稳运作，才能满足集团S的CD场景基本需求。

当企业IT产品研发业务发展到较大的规模时，随之而来CI/CD场景要解决的问题也是呈指数级别增长。但总体来说，企业规模化以后，CI/CD场景的优化点都会更集中在管控层面，无论是需求、代码和版本的统管，自动化工程减少人工的误操作，质检环节和度量能力的增加，都是基于企业管理者角度出发的要求。

CI/CD场景不再是开发人员和运维人员自己想怎么做就怎么做了，部分局限性大的开源或商用研运工具就这样在企业发展的过程中逐步退出了“历史舞台”。那么重点来了，咱们嘉为蓝鲸又是如何帮助集团S优化CI/CD场景的呢？往下看：

四、如何通过工程能力，为大中型企业支撑CICD场景？

文章开头有提到研发侧更关注CI场景，运维侧更关注CD场景，那为了研发和运维同学都能更好地理解，我们不妨就将集团S的CI/CD优化解决方案分成两个大场景进行展示。

五、嘉为蓝鲸DevOps平台，赋能CI（持续集成）场景

根据集团S的实际业务情况，我们将提出需求一直到交付总部运维的过程纳管到CI场景，交由嘉为蓝鲸DevOps平台进行优化。这其中当然也包含了一部分持续部署的工作内容，但考虑到S集团研发处的开发厂商们只会部署到DEV、SIT和UAT等开发测试环境而不是真正的生产环境，所以这部分持续部署工作其实也属于集团S在CI场景下所需要的能力。

嘉为蓝鲸DevOps平台通过研运一体化平台，保证了应用可以按时合规交付，满足了集团S的CI场景需求。下面我们可以直接通过产品演示，看下嘉为蓝鲸DevOps平台是怎么做到的：

提供CTeam敏捷协同、CCode代码库和CPack制品库能力，帮助产品部对所有需求、代码和构建产物进行企业级管理以及跟踪每个需求的完成情况。

提供CPipe持续集成和研发商店插件拓展能力，保障研发处在研发过程中大规模、多并发业务的持续集成和持续部署。通过CPack制品库和CPipe持续集成的结合使用，也能实现制品的自动晋级，保障研发过程中版本不受恶意纂改。

提供CCheck代码检查、CGuard质量红线和CTest测试管理等质量工程能力保证产品线/厂商的研发过程都能遵循集团规范和经过足够质量验证。

提供CMeas度量分析能力，帮助企业轻松掌握产研进度与研发效能，为精益和持续改进提供依据。

当然，DevOps平台能优化的问题还是集中在集团S的DevOps工程能力升级上。而对于一家企业的DevOps能力体系建设来说，其实更关键的部分在于对“人”的升级，上至战略规划、架构调整和业务改革等大方向，下至流程改进、人才引入和能力培训等工作项。

关于集团S全面建设DevOps能力体系的详细介绍，或许我们日后有机会还可以再细聊。

六、CPack制品库+ADA应用发布自动化，提升CD（持续部署）场景

根据集团S的实际业务情况，本次CD场景的优化需求可以概括为：“打造唯一可信源，快速完成版本上线”。此时S集团的CD场景发生在预生产和正式生产环境，已经无限接近于发布上线的完成阶段了。

其中“唯一可信源”是指，由于开发环境和生产环境普遍存在防火墙隔离，而且运维总部和各运维分部之间也存在情况各异的网络/物理隔离，所以总部研发处和总部运维处之间需要一个“安全岛”进行版本的交接，以保障高频迭代下版本的正确性；同时这个“安全岛”还需要做到多节点分发，以满足总部和分部之间部署包的快速分发。而这个“安全岛”，就是CPack制品库。

但即使运维都拿到了正确的版本，这也只是运维处工作的开始。虽然DevOps平台也有自动化部署的能力，但是同学们，正式上线用的生产环境（包括预生产环境），都是不需要进行开发、编译构建和测试这些工作的呀。如果单纯为了实现自动化部署而要求每个生产环境都部署一套DevOps平台，这显然对于企业管理者来说，在资金成本和技术架构上都“不切实际”，也没有必要性。

当应用架构、发布环境、发布策略和发布频率都极度熵增以后，应用运维团队肩负着保障业务系统正常运转的重大责任：如何保证SLA？如何应对愈加复杂的应用架构？不同策略的灵活使用保证业务的需求？如何保证业务的稳定变更等。。这时候，为了满足运维侧对实现自动化发布和管控应用发布的需求，ADA应用发布自动化就此闪亮登场了。

同样，下面我们可以直接通过产品演示，看下嘉为蓝鲸CPack制品库和ADA应用发布自动化是怎么配合运维完成持续部署的：

通过制品自动晋级，连接集团S研发处和运维处的工作，保障高频迭代下版本的正确性。

通过制品库的多节点分发能力，保障集团S运维处总部和各分部之间、运维处不同环境之间的部署包快速分发，为运维工作提速。

应用发布自动化与运维CMDB深度联动，以应用为中心建设：着眼于应用而不是资源对象，以纵向的维度划分模块，使用服务树拓扑管理应用，拓扑的设计支持传统应用架构和互联网应用架构，支持多环境，多集群管理：思路是基于应用部署的视图拆分，基于“应用系统-环境-集群-模块”的模型对应用系统进行描述。
ADA可对接第三方工单系统，支持周期拉取发布工单或由工单系统推送，自动或者手动关联预先设置好的发布任务模板，自动执行发布动作后回写工单数据，流转到下一环节，实现工单驱动发布自动化，在企业IT双态运维的背景下，让运维的发布工作能敏捷稳定双重保证。

ADA以双编排为设计核心，将发布策略、执行依赖管理流程编排和执行脚本等原子化操作的执行编排分离，通过强大的可视化编排能力，轻松实现单体/SOA/微服务/分布式/容器化应用的自动发布，为持续部署工作提速和保持稳定。

通过ADA的管控能力，对应用发布进行精细化管理和全过程跟踪，轻松掌握应用发布全局。

至此，我们很高兴地看到集团S终于完成了本次CICD场景的优化。当然，对于集团S来说，为了支撑持续集成和持续部署，仅仅做到应用发布自动化是远远不够的，尤其对于运维处而言，日常还需要全方位地保障集团的各类IT资产，才能保障企业的一切IT活动。

为了满足像集团S这样大中型企业对运维稳定性的高标准，于是嘉为蓝鲸还提供了像监控、告警和日志管理等监控类运维产品，也有CMDB、数字化服务管理和运营可视化等管理类运维产品，以及数据中心运维和应用运维、多云管理等管控类运维产品……企业IT工作的持续优化之路永无止境！

七、通过嘉为蓝鲸，企业收获了什么？

以集团S为例，通过嘉为蓝鲸对CICD场景的持续优化，足够支撑完成小时级业务交付和分钟级应用发布的需求：

在CI场景下，实现多个试点项目、上百款应用的产研工作，投产频率提升300%，支持紧急需求当天交付，实现应用的持续集成和持续交付。

在CD场景下，管理上万制品，制品容量达1.0+ TB，支撑着集团S多集群多应用的同时调用；承接了十余套生产环境、上百款应用的发布任务，总任务数量达一万次以上，月均发布量达两千以上，完成应用的分钟级发布，实现应用的持续部署和持续发布。

以上，是笔者参考和研究一些资料后，以及结合企业经验的一些个人感受和理解，欢迎留言探讨。

后续笔者还会近些更多干货分享，欢迎关注。

码字不易，若觉得对你有所帮助，欢迎点赞收藏。

编辑于 2022-04-26 15:49

【33 个基本 DevOps 工具】

DevOps本质上是一次文化上的变革，但是为了成功落实这一变革，选用正确的工具是非常关键的。DevOps最显著的一点是它促进了软件开发团队与运维团队之间的合作。同样重要的是，DevOps注重于自动化软件开发的各个环节，包括构建、测试、处理突发事件以及发布过程。这种对自动化的重视，使得产品能够更快速地投入市场、产品质量更高、软件的失败或需要回滚的情况更少。

不过，DevOps的发展已经超越了简单的团队协作和自动化策略。现在，DevOps已经融入了人工智能、机器学习、物联网和云计算等技术。为了应对这些领域，已经开发了许多DevOps工具，涵盖了构建管理、版本控制、配置管理、项目管理和突发事件处理等方面。

DevOps的核心组成部分

DevOps的核心组成部分涵盖了一系列基本原则和实践，这些原则和实践使得组织能够简化软件开发和IT运维流程，促进团队间的合作，实现自动化和持续的改进文化。这些核心组成部分对于实现DevOps目标至关重要，目标包括加快软件交付速度、提升系统的可靠性、加强开发团队与运维团队之间的协作。

文化和合作：DevOps重视改变工作文化，推动开发团队、运维团队以及其他相关团队之间的合作和沟通。一个基于共享责任和信任的工作文化是成功的关键。

自动化：自动化在DevOps中占据核心地位，帮助减少手动工作，提升工作效率。这包括自动化的构建流程、持续集成/持续交付（ CI/CD）流程以及基础设施的配置。

持续集成（CI）：CI是指自动将代码更改多次合并到共享仓库的过程中，并运行自动化测试，以便尽早在开发过程中发现并解决问题。

持续交付（CD）：CD在CI的基础上进一步，自动化地将代码更改部署和交付到生产或预备环境，确保软件始终可部署。

微服务和容器化：DevOps倾向于使用微服务架构和容器化（比如Docker），来让应用程序更加模块化，从而更容易扩展和管理。

代码即基础设施（IaC）：IaC允许通过代码自动配置和管理基础设施资源，工具如Terraform和Ansible帮助保持环境的一致性。

监控和反馈：持续监控应用程序和基础设施是识别问题和收集反馈的关键。工具如Prometheus和Grafana提供了关于系统健康和性能的见解。

反馈循环：建立反馈循环对持续改进至关重要。团队收集来自终端用户、运维和开发的反馈，以便进行数据驱动的决策并优化流程。

安全（DevSecOps）：安全措施贯穿DevOps的每个阶段，确保在每个阶段都实施了安全措施。常见的实践包括自动化的安全测试和漏洞扫描。

版本控制：版本控制系统（如Git）用于跟踪代码和配置的变更，支持团队协作、代码审查，以及在必要时回滚变更。

敏捷方法：DevOps通常与敏捷方法论相结合，支持快速适应变化需求的迭代和增量开发。

知识共享和文档：通过文档和交叉培训鼓励知识共享，确保团队拥有充足信息并能够高效工作。

可扩展性和弹性：DevOps实践包括规划可扩展性和建立弹性系统，以应对意外故障和工作负载的增加。

DevOps工具集合

1. PingCode

开发占了整个地图中最大的一块区域，这个领域东西最多最杂，毕竟这是跟人打交道最多的地方。这里面最大的一块叫做 Project Management，包括了需求管理，Bug 管理，进度管理，度量等等。比如

PingCode 是一款针对软件IT项目全生命周期管理的系统，知名客户包括小红书、长城汽车、华夏基金等。它满足Project Management，包括了需求管理，Bug 管理，进度管理，度量等等。支持敏捷开发、看板、瀑布等不同项目管理方法。支持私有部署、定制开发、SAAS等版本。

2.Git（包括GitLab、GitHub、Bitbucket）

Git是软件开发和DevOps中不可或缺的工具，因为它在版本控制、团队之间的代码协作和项目管理效率上发挥了关键作用。随着技术快速进步，对于组织和简化代码管理的需求前所未有地增加。

Git让开发者能够在代码库中协同工作，轻松地创建和合并新功能或修复bug的分支。它的分布式特性还意味着开发者即使在离线时也能无缝工作，这在当前广泛采用的远程和分布式工作模式中格外重要。

此外，Git还方便追踪代码的修改历史，帮助开发者轻松识别何时以及为何进行了特定更改，这对于保持代码质量和安全至关重要。软件开发对于推动创新和进步非常关键，Git以其支持高效、协作和安全的编码方法而继续占据核心地位。

3.Maven

Maven作为一个关键的DevOps工具，因其在管理项目依赖、构建过程和项目生命周期管理方面的持续重要性而受到重视。作为一个强大的构建自动化和项目管理工具，Maven通过简化Java项目开发中的编译、测试、打包和分发流程，减少了开发的复杂性。它保证了构建的一致性和可复现性，让开发团队能够更加高效地合作，交付高质量的软件。

Maven在管理依赖和支持持续集成及持续部署方面发挥着至关重要的作用。它能够应对复杂的构建场景，并与现代DevOps实践无缝整合，成为确保软件项目可靠性、可维护性和可扩展性的不可或缺的工具。

4.Jenkins

Jenkins的重要性在于它作为一个强大的自动化服务器，能够支持持续集成和持续交付（CI/CD）管道。Jenkins通过自动化构建、测试和部署代码更改，简化了软件开发流程，确保软件能够快速且高质量地交付。随着现代应用程序变得越来越复杂，对高效的CI/CD流程的需求日益增长。

Jenkins的灵活性、可扩展性以及其庞大的插件库使其能够满足广泛的技术需求和工具，适应多种开发环境。随着组织越来越注重软件开发实践中的速度、可靠性和团队协作，Jenkins作为基石工具，支持团队实现流畅的自动化流程和高效的软件交付。

5.Chef

Chef是一个关键的自动化平台，特别在以代码管理基础设施方面发挥着重要作用。Chef让组织能够轻松实现基础设施的可扩展性、可靠性和快速部署。通过自动化服务器的配置、配置和维护，Chef提升了整个基础设施的运行效率和一致性，减少了人为错误，并保证基础设施处于期望的状态。

此外，Chef与各种云提供商、容器化技术和其他DevOps工具顺利集成，使其能够适应不断发展的技术景观。随着组织将敏捷性和可扩展性作为优先事项，Chef仍然是自动化复杂基础设施任务并使DevOps团队能够专注于创新和交付的重要工具。

6.Puppet

Puppet对于简化复杂的IT基础设施管理和编排极其重要，因为它允许管理员通过代码来定义基础设施。这意味着不同的服务器、云服务和容器之间的配置可以保持一致且可重复实施。

随着企业越来越依赖于多样、动态和混合类型的基础设施，Puppet通过简化配置过程、保持持续的合规性来减轻运营的复杂性，最小化出错的可能，并加速软件的交付过程。Puppet帮助组织高效地管理和扩展其基础设施，同时确保安全和遵守规范，成为一个不可或缺的工具。

7.Ansible

Ansible是一个非常强大且广泛使用的自动化和配置管理工具，对2024年尤其重要的几个原因包括其简单性和多功能性。Ansible使组织能够自动化执行重复性任务、配置基础设施以及管理不同环境中的配置，成为DevOps和IT团队非常珍贵的资源。

Ansible以其无需代理的架构、声明式语言和丰富的预构建模块库，易于初学者和经验丰富的专业人员使用。随着组织优先考虑效率、可扩展性以及快速部署应用和服务，Ansible维持其作为DevOps必备工具箱中的一部分，帮助团队简化工作流程、提升安全性，并在快速变化的技术环境中减少手动错误，增强灵活性。

8.Docker

Docker对现代软件开发和DevOps实践至关重要，因为它简化了在各种环境中管理应用程序的过程。通过封装应用程序及其依赖于容器中，Docker确保了从开发到生产的部署过程一致且可重复。

这一技术不仅提升了应用程序的可移植性和可扩展性，还加速了开发周期，并减少了因环境差异导致的问题。在软件快速发展的环境中，Docker通过其容器化方法提供了高效、隔离且高度灵活的应用部署方式，成为DevOps和持续交付流程中的基础组件。

9.Kubernetes

Kubernetes（通常简称为K8s）在现代软件开发和运维中扮演中心角色，其重要性体现在其编排、管理和自动化大规模容器化应用的能力上。随着越来越多的组织采用微服务架构和容器化技术部署应用，Kubernetes提供了必要的基础设施支持，以高效地部署、扩展和维护这些容器。它的弹性、自我修复能力以及对混合云和多云环境的支持，对于确保应用部署的敏捷性、可靠性和成本效益至关重要。

作为云原生生态系统的核心，Kubernetes使组织能够加快软件交付速度，优化资源利用，并有效应对数字环境的变化需求。

10.Slack

Slack是一个对全球企业和组织至关重要的工具。它使得团队之间能够无缝沟通和合作，无论是面对面还是远程协作。通过实时消息、共享文件和集成功能，Slack简化了日常工作流程，提升了效率，并帮助不同地区和时区的团队保持紧密联系。

随着工作方式的变化，越来越多的企业采用了混合和远程工作模式，Slack成了快速做决策、协调项目和分享知识的核心平台。随着其不断扩展的集成和功能生态系统，Slack保持在现代工作场所沟通的前沿，帮助企业保持灵活、高效和具有竞争力。

11.DevOps 中的 AWS 云计算和存储

AWS（亚马逊网络服务）的云计算和存储对DevOps至关重要，它们提供了可扩展、灵活且成本效益的基础设施，完全满足现代软件开发和部署的需求。AWS提供了包括计算资源、数据库、容器编排和无服务器计算在内的多种服务。采用DevOps是为了加快软件的交付速度。

AWS为应用程序的快速部署和扩展提供了坚实的基础，支持持续集成和持续交付（CI/CD）流程，并通过工具如AWS CloudFormation自动化基础设施的配置。

此外，AWS的存储解决方案优化了数据管理、备份和恢复流程，确保了DevOps工作的韧性和可靠性。随着云技术的不断进步，AWS一直处于领先地位，让DevOps团队能够专注于创新和提高效率。

12.DevOps 中的 Azure 云计算和存储

Azure的云计算和存储在2024年及以后的DevOps实践中将起到关键作用。Azure提供了一个全面的云生态系统，使组织能够扩大基础设施规模、高效部署应用程序并存储数据。Azure支持持续集成和持续部署（CI/CD）、自动化、监控和安全等关键服务。其云计算功能使资源能够按需提供，保证开发和测试环境随时可用。

Azure的存储解决方案如Azure Blob存储、Azure文件和Azure SQL数据库，提供了安全的数据存储和检索功能，支持DevOps的数据驱动需求。同时，Azure通过与DevOps工具如Azure DevOps服务的集成，简化了软件开发生命周期，加强了团队协作和自动化流程。

13.DevOps 中的 GCP 云计算和存储

Google Cloud Platform（GCP）提供了强大的云计算和存储服务，为现代的DevOps实践带来了可以扩展、可靠且始终可用的基础架构。通过一系列全面的服务，如Google计算引擎、Google Kubernetes引擎、云存储和BigQuery，GCP让DevOps团队能够轻松地构建、部署和管理应用程序。GCP特别强调自动化、将基础设施视为代码以及容器管理，这些都与DevOps的原则完美契合。

此外，GCP提供的先进技术，比如人工智能和机器学习，为DevOps专家提供了强大的监控、分析和自动化工具，使其成为那些希望优化软件开发和交付流程的组织的理想选择。

14.监控、警报和事件响应工具：SignalFx

在DevOps和软件开发中，如SignalFx这样的监控、警报和事件响应工具极其重要。随着软件系统变得越来越复杂和分布式，实时了解性能状况并快速响应问题成为必需。SignalFx提供了高级的监控和可观察性解决方案，使组织能够主动发现异常、追踪微服务问题并设置智能警报。

在应用程序规模不断扩大和云原生架构变成常态的今天，用户对于系统的可靠性期望也随之上升，SignalFx的功能变得尤为关键。它使DevOps团队能够确保系统高可用、优化资源使用并提供流畅的用户体验，通过提前识别并解决可能影响终端用户的性能问题。SignalFx是维持现代软件运维重要性的关键工具之一。

15.Appdynamics

AppDynamics作为领先的应用性能管理和监控平台，对于确保现代数字业务运行在最佳性能状态至关重要。随着企业越来越依赖于复杂的、分布式的软件系统，主动进行监控、排查问题和对这些应用程序进行优化变得格外重要。AppDynamics提供应用性能的实时视图，让企业能够快速定位到性能瓶颈、延迟问题和故障。

随着应用程序变得日益复杂，AppDynamics能够帮助企业提供卓越的用户体验，保持应用程序的稳定性，并快速解决性能问题，从而确保企业在数字化竞争中的成功和竞争力。

16.Raygun

Raygun是软件开发和DevOps领域极其重要的工具，它保障了应用程序的可靠性和性能。作为一个应用程序监控和错误跟踪平台，Raygun赋予了开发团队发现、诊断和解决实时问题的能力。

随着软件系统变得越来越复杂，对流畅的用户体验的需求日益增加，Raygun能提供关于应用程序错误和性能问题的实用信息。它让组织可以主动地解决问题，减少系统停机时间，提升用户满意度，进而提高软件的质量和优化客户体验。

在各行各业中，软件都是核心。Raygun在确保应用程序健康和快速解决问题方面发挥着关键作用，成为DevOps专家和软件开发人员必不可少的工具。

17.Splunk Cloud

Splunk Cloud帮助组织从当下不断增长的数据量中提取关键见解。在企业越来越多依赖于基于数据的决策的今天，Splunk Cloud凭借其强大和可扩展的能力脱颖而出，能够监控、搜索、分析和可视化由机器生成的数据。它的价值在于能实时展示复杂系统、应用和基础设施的健康状况和性能，从而快速检测和响应事件。

面对网络安全威胁的不断演变，Splunk Cloud的高级安全分析和威胁检测功能成为保护免受网络攻击和确保数据完整性的关键。在把数据视为战略资产的世界里，Splunk Cloud在使用数据力量实现操作卓越和保障安全方面发挥着不可忽视的作用。

18.Selenium

Selenium因其在确保Web应用程序质量方面的持续重要性而仍然是软件测试和自动化的关键工具。随着技术进步，Web应用程序变得更加复杂，需要在多种浏览器和平台上进行全面测试。

Selenium以其出色的自动化功能和广泛的浏览器兼容性，使得开发人员和质量保证（QA）团队可以高效地自动化重复的测试任务，执行跨浏览器测试，确保Web应用在各种环境下都能顺畅运行。

其开源属性、活跃的社区支持以及与其他DevOps工具的整合，使Selenium成为那些追求持续交付和快速部署高质量软件的组织的理想选择，这是现代软件开发实践的核心。

19.Gremlin

Gremlin是混沌工程的关键工具，混沌工程越来越成为确保现代软件系统韧性和可靠性的重要手段。技术的发展和复杂分布式系统的普及使得意外故障和中断的可能性增加了。

Gremlin让组织能够通过模拟如网络断开、服务中断和资源限制等控制的失败情况，主动找出其基础架构和应用程序的弱点。

通过有意引入混乱并监控系统如何应对，团队可以在问题导致昂贵的停机或安全风险之前发现弱点。Gremlin帮助组织构建更加强大和容错的系统，这些系统能够应对现实世界的挑战，并向用户提供持续不断的服务。

20.ServiceNow

ServiceNow对于那些希望简化IT服务管理和其他业务流程的组织至关重要。它通过提供一个统一的云平台来自动化和优化包括IT服务管理（ITSM）、IT运营管理（ITOM）、人力资源（HR）、客户服务等在内的各种业务流程，显得尤为重要。

随着服务数字化加速、远程工作增多和技术基础设施复杂度上升，ServiceNow提供了一种管理工作流程、解决问题和高效提供服务的全面方法。它的智能自动化、数据分析和基于人工智能的洞见赋予了组织提高生产力、灵活性和客户满意度的能力，同时还能减少运营成本。

ServiceNow在整合和协调多样化系统和流程方面发挥着不可替代的作用，对推动数字化转型和确保业务在不断变化的商业环境中顺畅运行至关重要。

21.状态服务更新：状态页面

“状态服务更新：状态页面”对任何规模的组织或企业都非常关键。在今天这个在线服务和应用至关重要的时代，确保它们始终可用和可靠是必不可少的。这个状态页面能够实时向用户和相关方提供关于服务、应用以及基础架构状况的信息。通过及时告知任何服务中断、计划的维护或事件的解决情况，状态页面在提升透明度、建立信任和增加客户满意度方面起着至关重要的作用。

服务中断可能会导致重大的财务损失和声誉损害，因此，拥有一个实用的状态页面不仅是方便的，更是一种必需。它让组织可以展示他们在处理服务问题时的透明度和响应速度，最终有助于建立更加牢固的客户关系和信任。

22.ELK（Elasticsearch、Logstash和Kibana）

ELK，代表Elasticsearch、Logstash和Kibana，对于那些需要有效进行日志管理、监控和数据可视化的组织来说，继续是不可或缺的工具组合。Elasticsearch是一个可高度扩展的快速搜索引擎，能够支持实时的数据索引和搜索。

Logstash帮助从多种来源收集、处理和转换日志数据，使其可以被Elasticsearch使用。而Kibana则提供了一个友好的界面，用于数据的可视化和分析，包括可定制的仪表板和强大的数据探索功能。

到2024年，ELK的重要性在于它能够为组织提供其系统、应用和基础架构的全面见解。最终，它有助于快速解决问题、主动监控和进行基于数据的决策，在技术不断发展和快速变化的环境中尤为重要。

23.GitLab CI/CD

GitLab CI/CD之所以重要，是因为它能够在一个集成的环境中自动化整个软件交付流程，从代码变更直到部署。GitLab CI/CD确保软件更新可以快速且可靠地交付。通过自动构建和测试代码变更，它实现了持续集成（CI），让团队能够在开发过程的早期阶段发现问题。

持续部署（CD）进一步自动化了发布和部署过程，减少了人为错误的可能，使得组织能够迅速而自信地向用户交付新功能和更新。随着企业寻求加速其数字化转型，快速适应市场变化，并通过高效的自动化软件交付实践保持竞争力，GitLab CI/CD的重要性愈发凸显。

24.脚本编写

编写脚本对于自动化和简化软件开发、系统管理以及DevOps实践的多个环节非常关键。使用Python、Bash和PowerShell等脚本语言，技术人员可以编写代码来执行重复性任务、处理数据和高效地管理复杂流程。编写脚本的过程有助于快速制作原型、管理配置以及创建自动化部署流程。

这提升了工作效率，确保了从软件测试和部署到基础设施配置和监控等任务的一致性，并降低了人为出错的可能性。随着越来越多的组织开始采用DevOps和云原生技术，编写脚本在技术领域变得更加重要，保持了其竞争力和适应性。

25.Terraform

Terraform在现代基础设施的配置和管理中发挥着至关重要的作用。它使组织能够通过代码定义和部署基础设施，自动创建和配置云资源、容器和其他基础设施组件。随着云计算、微服务和容器化技术在2024年变得日益普及，Terraform提供了跟上现代应用需求所需的灵活性和扩展性。

Terraform之所以重要，是因为它给基础设施操作带来了一致性、版本控制和自动化，这减少了人为错误，简化了DevOps流程，并促进了在复杂且以云为中心的环境中应用的快速和可靠部署。随着组织采纳云原生技术，Terraform对于确保高效且一致的基础设施管理变得极其重要。

26.Phantom

Phantom提升了安全自动化和事件响应的能力。在今天这个网络安全威胁不断演变的环境下，组织需要能够迅速有效地响应持续出现的网络安全事件。Phantom提供了一个平台，用于自动化安全任务流程，从发现和调查潜在威胁到组织响应和降低风险的步骤。

Phantom的价值在于它能显著减少响应事件所需的时间，提高处理事件的一致性，并减轻人工在重复性任务上的负担。随着网络威胁的复杂性日益增加，Phantom赋予了安全团队更主动地防御攻击和保护关键资产的能力。

27.Nagios

Nagios是一个开源监控和警报系统，对于保持IT基础设施和应用程序的可靠性和性能非常关键。随着组织对复杂系统和服务的依赖越来越大，Nagios通过其实时监控和警报功能，帮助IT团队在用户受到影响或系统中断之前发现并处理问题。

Nagios的多功能性、可扩展性以及对本地和云环境的支持，使其成为一个宝贵的工具，确保关键系统的可用性、稳定性和安全性，完全满足现代IT运营和DevOps实践的需求。

28.Vagrant

Vagrant在软件开发和DevOps领域继续扮演着至关重要的角色。它是一个用于简化创建和管理一致开发环境的工具。Vagrant的价值在于为开发者和DevOps团队提供了一个统一和隔离的环境，用于软件的开发、测试和部署。

面对不断变化的软件栈、依赖关系和基础设施配置的复杂性，Vagrant在确保这些环境容易共享、扩展和维护方面显得尤为重要。它让开发人员能够在不同操作系统间顺畅工作，并提供了标准化的环境设置，从而最小化了兼容性问题。

29.Gradle

Gradle在软件开发和DevOps领域继续扮演着一个关键角色。作为一个先进的构建自动化系统，Gradle在高效管理依赖关系、构建项目以及协调复杂的工作流程方面起着核心作用。它之所以重要，是因为它既多功能又可扩展，适合处理各种规模和类型的项目。

Gradle能够轻松应对多语言和多项目的构建任务，并通过插件支持进行定制，这使得它在现代软件开发过程中成为不可或缺的工具。随着越来越多的组织采用微服务架构和云原生技术，Gradle在管理不同环境下应用程序的构建、测试和部署的复杂性方面发挥着关键作用。

30.eG Enterprise

eG Enterprise非常重要，因为它提供了全面的应用程序和基础设施性能监控及诊断功能。在技术生态系统变得更加复杂，融合云计算、微服务和分布式架构的背景下，eG Enterprise成为保证这些系统可靠性和最优性能的关键解决方案。

它拥有实时监控、自动根因分析和预测分析的先进能力，使组织能够主动发现并解决问题，减少停机时间，提高最终用户体验，并优化资源使用。在数字服务对业务成功至关重要的今天，eG Enterprise帮助企业保持高性能标准、可用性和用户满意度。

31.Prometheus

Prometheus在DevOps和系统可观察性方面发挥着至关重要的作用。随着复杂软件系统的增长以及对监控和警报系统的需求不断提升，Prometheus变得更加重要了。它擅长收集、存储和分析来自应用程序基础设施（包括容器、微服务和云环境）的指标。

它的开源本质和活跃社区支持加速了其普及。随着组织越来越多地采用云原生技术、微服务架构和动态伸缩，Prometheus提供了保持应用性能、进行故障排除和确保软件系统在DevOps快节奏世界中可靠运行所需的关键可见性。

32.Sentry

Sentry在当代软件开发和DevOps实践中起着至关重要的作用。随着软件应用变得更加复杂和庞大，快速识别和修复错误及问题变得极为重要。 Sentry的关键之处在于它能够提供实时的错误追踪和监控，让开发团队能够主动地发现和诊断问题，不管这些问题是在生产阶段还是开发过程中出现的。

它通过减少停机时间、提升用户体验以及保持软件系统的整体健康和可靠性，发挥了重要作用。

33.Jira

Jira之所以重要，是因为它可以简化和集中处理软件开发生命周期的各个环节，为问题跟踪、项目规划和团队合作提供了一个一体化的平台。它帮助团队管理任务、设置工作优先级，并在开发的整个过程中保持透明度。

通过包括可定制的工作流程、报告功能和集成选项在内的广泛特性，Jira让团队能够适应需求变化，支持敏捷开发方法，并有效交付高品质的软件。Jira继续作为支持团队按时完成项目和提升合作效率的必备工具，成为组织的核心工具。

结论

对于那些追求更快速、更可靠、质量更高的软件交付的组织来说，采纳DevOps不再是一个选项，而是必须的。本文所讨论的基础DevOps工具构成了这一变革性方法的基石。从使用Git进行版本控制到利用Jenkins实现持续集成，从通过Docker进行容器化到采用Kubernetes进行编排，这些工具赋予了DevOps团队自动化操作、加强协作和推动创新的能力。

常见问题解答

Jenkins是DevOps工具吗？

是的，Jenkins是一个被广泛使用的DevOps工具。作为一个开源的自动化服务器，它在DevOps流程中非常关键，主要是通过支持持续集成/持续交付（CI/CD）过程。Jenkins能自动进行构建、测试和部署代码更改，从而帮助软件开发和运维团队更加高效地协同工作。

DevOps工具能和现有系统集成吗？

是的，DevOps工具设计之初就考虑到了与现有系统和技术的高度集成性。它们通常提供了API、插件和扩展功能，以便能够与各种工具和系统无缝集成，这让组织在采纳DevOps实践的同时，可以继续利用现有的基础设施。这种集成方式有助于缩小开发与运营之间的差距，并提升整个工作流的效率。

在实施DevOps工具的过程中会遇到哪些常见问题？

引入DevOps工具时，可能会遇到包括文化上的抵触、缺少有技能的员工、处理复杂的旧系统以及确保安全性和合规性等挑战。选择适合特定需求的正确工具也可能是个挑战。为了克服这些障碍，有效的培训、沟通和一个明确的DevOps战略是至关重要的。

编辑于 2024-04-07 17:41

搭个gitlab基本所有功能都有了

发布于 2020-09-01 13:42

对于软件研发团队而言，服务的稳定性是非常重要，它与生产经营、用户留存都密切相关。而 CODING 作为面向软件研发团队的研发协作管理平台，与客户的业务生产更是密不可分。如何为客户提供高可用、不间断的服务体验，如何多层面、多渠道来保障 CODING 本身的服务稳定性，成为了 CODING 发展道路上不懈的追求。

背靠腾讯云，充分利用云上能力

CODING 作为一站式云端开发平台，从诞生之初就生长在云端，充分利用腾讯云的能力为客户提供弹性可靠的服务。比如，CODING 持续集成的编译池基于 CVM 进行架构，保障用户极速构建无需等待；制品库充分利用对象存储 COS 及 CDN 极速能力，为广大客户提供了全球一致的拉取及响应。CODING 通过对云能力的充分利用，保障客户软件开发过程的可靠。

严谨的发布流程，践行最佳实践

CODING 团队平均每周进行上百次更新发布，以快速响应客户需求。在频繁变更的场景下，为了避免变更引起的业务故障，CODING 团队从变更流程上进行了诸多保障措施。

CODING 提供 Testing 和 Staging 两个测试环境，Testing 环境由开发团队自行维护，Staging 环境由公司统一维护，与线上环境最为接近。开发完成本地测试后，会进行 Testing 和 Staging 两轮验证，充分利用 CODING 持续集成提供的自动化测试能力，确保变更不会影响线上 P0 及 P1 级别的功能及流程。

验收通过后，该变更将灰度发布到生产环境，在灰度企业进行测试验收，验收通过后才会发布到线上环境。除生产环境之外，CODING 还进行了备用环境的部署，如果发生发布事故，可迅速切换至备用环境，保障服务可用，在生产环境变更验收通过后，才会更新备用环境。

持续性架构升级，关键服务保障

除了通过云的能力和流程规范确保 CODING 整体的可靠性之外，根据不同产品线的不同场景，也在架构设计上进行了高可用保障。

代码仓库

代码是软件研发企业的核心资产，客户的代码存储安全是 CODING 工作的重点。CODING 代码仓库通过在存储机器上为储存库创建多个副本，实现了存储冗余。同时在存储库副本之间建立了实时高效的同步机制，保证了存储库副本之间的一致性。在存储库感知机制上，CODING 代码仓库构建了一套存储库故障感知机制，一旦故障发生，则能够迅速进行故障转移从而能继续为存储库提供服务。

持续集成

稳定的构建环境是保障用户持续集成可靠的重要一环。而实现稳定高效构建，不仅需要考虑构建资源的有效利用和状态管理，还要保障其它依赖服务的稳定性。比如 CVM 在某个地域无法创建构建机器时，会导致使用该地资源节点的用户无法顺利构建，为了防范这个问题， CODING 持续集成采用灵活的容灾策略，对构建节点池进行地域切换，对故障进行转移，确保构建的稳定性，实现服务的高可用。

持续部署

相较于传统的内网场景，SaaS 场景对持续部署提出了更高的要求。比如 SaaS 场景下，对大量集群资源进行动态更新，在集群资源数据庞大的基础上确保服务性能。

面对这样的挑战，在服务的交互上，CODING 持续部署重点保障发布服务的稳定性、可靠性，采用断路器，请求重试算法，服务优雅关闭等技术，确保在高并发场景中服务更新用户无感知，提高服务的容错能力。在服务的扩展上，CODING 持续部署支持 HA 高可用拆分，同一服务可根据业务需求以及访问量，按功能拆分部署提供服务。另外，CODING 持续部署编排引擎支持分布式任务调度处理，解决了 SaaS 场景下高并发发布部署的性能瓶颈，为客户提供了快速安全可靠的部署方式。

监控预警完备，先一步发现问题

有防就有治，在运维上，CODING 建立了一套完善的故障预警与治理机制。为及时应对故障，CODING 基于 Prometheus 构建了服务监控预警系统，用户可依据不同的业务场景，通过运维方自定义监控数据的可视化和报警规则。一旦发现服务异常产生告警，告警信息可根据报警规则，第一时间通过企业微信精确地推送至相关的组或个人，及时发现生产问题。

为提升整体系统稳定性以及各类异常故障的容错能力，CODING 还制定了故障演习标准定期演习，对于影响全站访问的核心业务须保证每月进行至少一次故障演习，其它业务最长演习间隔不得超过两个月，出现演习结果不符合预期时，应尽快输出改进计划并进行改进，随后进行新的演习以确认改进措施落地情况。在容错机制上 CODING 也进行了明确要求，如系统内部单点故障，下游故障系统都需具备自动发现和屏蔽错误的能力；不能存在超时或者无限重试导致系统雪崩的情况；在服务异常时，业务需要有自动降级的方案。

在实现服务稳定性的道路上，CODING 进行了全方位的探索。无论是云能力的构建、产品的打磨、运维机制的制定都充分体现了 CODING 对于提升服务稳定性，切实提升用户体验的思考与能力。未来， CODING 将不断寻求技术上的升级，场景上的突破，致力将全栈、极致的开发体验带给每一位开发者。

编辑于 2021-05-07 16:19

谢邀……

M$ 内部项目都是 VSTS 上的，从几个文件的小工程到 Windows 都用的这个。

编辑于 2018-03-03 02:22

DevOps是Development和Operations的组合，是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合。DevOps考虑的不仅仅是软件部署，它是一套针对这几个部门间沟通与协作问题的流程和方法。

工欲善其事，必先利其器。DevOps工具可以帮助促进团队中的DevOps文化形成，在DevOps实践过程中，大多数团队开始会依赖于多种工具，构建自定义工具链，以满足应用程序生命周期中每个阶段的需求。如果人们选择了适当的工具，就可以实现和简化DevOps做法，当然在整个实践过程中，也会有一些团队觉得现有的工具不好用，开始自研工具。而对于中小企业来讲，还是推荐使用现成的工具，毕竟自研还是需要投入大量的人力的。下面介绍一些适合中小企业使用的DevOps工具。

GitLab

GitLab 是由 GitLab Inc.开发，一款基于 Git 的完全集成的软件开发平台（fully integrated software development platform）。一开始使用GitLab，认为它可能就是一个基于Git的代码托管平台，而实际上，该平台上还包括了wiki在线编辑，issue跟踪，CI/CD等功能。一般的中小企业都会选择搭建一个GitLab私有服务器来管理代码资产，同时也仅仅只是用来做代码托管。但是，GitLab可是自称为完整的DevOps平台，在用了GitLab的CI/CD功能之后，觉得它的CI/CD功能也是非常强大的。针对中小企业用户，GitLab CI/CD或许完全可以满足开发人员日常环境部署，升级的自动化需求。通过编写.gitlab-ci.yaml，定义流水线的阶段（Stage），以及每个阶段要完成的任务（Job），用户可以使用shell脚本来执行任务。并且通过权限控制，很好的管理用户的隐私数据（比如用户密码，认证密钥等），用户虽然看不到这些隐私数据，但是可以在.gitlab-ci.yaml中引用这些数据，来完成具体任务（比如镜像上传到线上仓库，更新k8s资源等）。只不过，配置流水线完全是通过配置文件的方式进行的，可以对普通的开发人员，或者喜欢UI界面的来说，并不是一件友好的事情，尽管GitLab已经提供了强大的文档支持。从整体角度讲，构建在代码托管平台之上的CI/CD，需求与问题跟踪功能能够让开发人员一站式地完成任务获取，代码提交，自动化验证等。

Jenkins

Jenkins是一款由Java编写的开源的持续集成工具，主要用于持续、自动的构建/测试软件项目， Jenkins用Java语言编写，可在Tomcat等流行的servlet容器中运行，也可独立运行。通常与版本管理工具(SVN, Git)、构建工具(Maven、Ant、Gradle)结合使用。部署一个Jenkins是非常容易做到的，在各大操作系统上都是开箱即用的。当然，也可以使用Docker来部署它，那完全就是一句命令行的事情，在部署好Jenkins之后，用户可以通过浏览器搭建并且配置Jenkins服务器。如果你是第一次使用它，可以选择安装最常用的插件。当然也可以创建自定义配置。Jenkins之所以流行的主要原因是其巨大的插件生态系统。目前，它提供 1000多个插件，因此它可以和几乎所有DevOps工具集成。使用Jenkins，用户可以尽快迭代并部署新代码。它还帮助用户查看流水线里每一步是否成功。

Jenkins可以说在DevOps工具中可以说是备受青睐，笔者认为这可能还是和它强大的插件生态系统有一定关系，通过配置插件，可以快速地实现与其他服务，工具的对接（比如k8s等）。

Kubernetes & Docker

Docker是云原生下最重要的DevOps工具之一。Docker在IT界掀起了容器化的潮流。它将应用程序隔离成单独的容器，因此应用变得更加便携也更为安全。用户可以使用Docker容器代替虚拟机（VirtualBox）。Docker最吸引开发人员的地方是，开发人员无需担心依赖管理。可以将所有依赖打包进应用程序的容器，并将所有的东西当做独立的单元交付。然后，用户可以很轻松地在任意机器或者平台上运行这个应用程序。Docker也在云计算中占据不可或缺的席位。最近几年，所有主流的云供应商，比如AWS，Google Cloud，都已经支持Docker。因此，如果你计划云迁移，那么Docker可以帮助简化这一进程。当然Docker本身并不是容器，它是创建容器的工具，是应用容器引擎。也就是“搭建、发送、运行”三板斧。但是如果想要将Docker应用于具体的业务实现，是存在困难的——编排、管理和调度等各个方面，都不容易。于是，人们迫切需要一套管理系统，对Docker及容器进行更高级更灵活的管理。

就在这个时候，Kubernetes出现了。近3年，基本上每个开发人员都在谈论 Kubernetes。它是容器编排平台，将容器化推进到下一个层面。它可以使用Docker或者其他替代产品。Kubernetes仍然很新，2015年才推出第一个版本。它由一些Google的工程师创建，他们想找到管理大规模容器的方案。使用Kubernetes，用户可以将容器组织成逻辑单元。如果你只有几个容器，那么可能并不需要容器编排平台。但是，当系统达到一定级别的复杂度，需要扩展资源的时候，这就是合理的下一步。Kubernetes让用户可以自动化管理上百个容器的过程。使用Kubernetes，无需将容器化的应用程序绑定到某个单独的机器里。相反，你可以将它部署到一个机器集群里，Kubernetes会自动化分发并在整个集群里调度容器。一个Kubernetes集群包含一个master和几个worker节点。master节点实现预定义的规则，并且将容器部署到worker节点上。Kubernetes负责所有一切。比如，它注意到某个worker节点下线了，就会将其上的容器重新分发到别的节点上。

由于Kubernetes的热潮，也涌现了许多基于Kubernetes的CI/CD工具，比如Tekton， Argo等。Tekton通过简单的几个CRD资源，构建出了一个功能强大且灵活的 Kubernetes 原生框架，基于这套框架，我们几乎可以定义出任意需求的流水线。Argo 项目是一组 Kubernetes 原生工具，用于运行和管理 Kubernetes 上的作业和应用程序。目前由 Argo Workflows，Argo Events，Argo CD 和 Argo Rollouts 四个子项目组成。

SonarQube

SonarQube 是一个用于代码质量管理的开放平台。通过插件机制，Sonar 可以集成不同的测试工具，代码分析工具，以及持续集成工具。与持续集成工具（例如 Jenkins 等）不同，Sonar 并不是简单地把不同的代码检查工具结果（例如 FindBugs，PMD 等）直接显示在 Web 页面上，而是通过不同的插件对这些结果进行再加工处理，通过量化的方式度量代码质量的变化，从而可以方便地对不同规模和种类的工程进行代码质量管理。随着 IT 行业中软件产品的推陈出新，客户对于软件产品的要求也越来越高，因此如何高质量的管理软件代码，及时地对代码质量进行分析并给出合理的解决方案就成为了当下必须要解决的一个问题。与当今众多的代码质量管理工具相比，SonarQube 更具有特色和竞争力，其优势主要体现为：它是一个开源的代码质量管理系统，支持 25+ 种语言，可以通过使用插件机制与 eclipse 和 JIRA 等其他外部工具集成，从而实现了对代码的质量的全面自动化分析和管理。

常用的DevOps工具除了代码管理，容器与容器编排，持续集成持续部署，质量管理之外，还有日志管理，性能监控，项目管理等。中小企业随着业务的逐渐稳定，可能会开始考虑打造自己的工具链，帮助提高产品研发，交付的效率。面对这么多的工具，要想把他们串联成一套成熟可用的完整工具链，并非一朝一夕能够完成的。

利益相关：网易轻舟云原生DevOps平台，根据自身在网易集团内部多年的DevOps实践，打造了一套适用于中小企业的DevOps平台。网易轻舟云原生DevOps平台包括了代码托管，基于Jenkins打造的更加简单好用的流水线，容器云平台以及容器部署，日志管理，性能监控等，覆盖了应用全生命周期。

发布于 2020-07-02 18:50

怎样实施 DevOps?面临什么问题？如何解决？

什么是DevOps?

首先DevOps 不是一个产品，其次软件工程方法论也不准确。

在 DevOps 模式下，产品，设计，开发，测试和运维团队更紧密地结合在一起，贯穿应用程序的整个生命周期。通过自动化工具替代手工操作，实现快速，高效，安全的测试，构建，部署项目。

可用的软件胜过完备的文档
团队合作胜过需求文档
响应变化胜过遵循流程与计划

为什么会诞生DevOps?

传统软件企业，以软件开发为主，开发部是最大的部门，根据项目分组，下设许多项目组，需求，开发，测试等等组别。运维显得不那么重要。这个模式已经不适合互联网企业。互联网企业通常是设置开发部，测试部，运维部，产品部，运营部，客服等等部门，但这样的组织架构带来了新的问题。

产品部关注用户体验，不考虑性能与开发合理性。开发部门的驱动力通常是“频繁交付新特性”，完成产品部提出的需求，测试部关注的是开发部是否按照需求完成所有的功能，运维部更关注7*24小时无故障运行。从产品->开发->测试->运维过程看似完美，但他们目标不匹配，就在这些部门之间造成了鸿沟，从而减慢了交付业务的速度。

随着管理学的不断完善，例如工商管理，被分成很多纵深领域，行政管理，人事管理，财务管理，营销管理，项目管理……等等。

而软件管理又被细分为：时间管理，范围管理，需求管理，质量管理，风险管理，成本管理......

由于组织架构的需要，又把人分成很多岗位，每个岗位上紧紧需要一种知识体系。企业按照自身的需要招聘某个领域的人才。

同时我们学校也按照知识体系划分院系，本科教育程专科趋势，不重视通识教育，最终学生紧紧掌握了微观的知识。

如果说哲学是科学的科学，那么 DevOps 就是管理的管理。所以我认为 DevOps 是多维度宏观管理学。

DevOps 虽好，为什么难以普及呢？

实施DevOps 第一个遇到的问题就是人才，DevOps 需要经验丰富的跨界人才。第二个问题就是没有案例可循，无法借鉴和参考。

实施DevOps需要具备管理，开发，测试，运维等等背景的人才。每个领域至少也需要三年的积累，至少需要 3+3+3+3 = 12 年工作经验，多少公司员工都比较年轻，普遍在 3~5年。一般员工工作10年以上，遍开始转向管理岗位，或者寻找其他出路。即使转管理岗的员工紧紧负责开发管理或者测试管理…… 不太可能10年的开发，转运维部重头开始。

我上面说过我们教育模式有问题，本科教育应该培养 “T” 型人才，专科教育培养 “I” 型人才，本科教育呈专科化。学校只教会学生一项技能（如Java 开发）,而没有教会学生如何学习。

在中国企业的年龄歧视 “T” 型人才流失严重。“I”人才只能掌握一项技能解决一个领域的问题，无法完成DevOps 的实施。

DevOps 不是产品，是一种管理思想，每个企业根据自身特点，制定自己的DevOps规范，所以第二个难点就是，没有案例可循，无法参考。

软件工程的历史与进化

传统软件工程学出现的年代互联网还不普及，主要是单机运行的软件，或者C/S结构的软件，其特点是开发周期长，迭代慢，每半年或者一年交付一次。流程主张：

需求->设计->开发->测试->交付

进入互联网时代，已B/S为主的软件，交付周期缩短到一个月，在传统软件工程做了改进，放弃了瀑布开发模式，提出了快速迭代，螺旋上升，管理上也逐步完善。出现了软件项目管理，CMM5软件开发成熟度模型。

互联网快速发展，使传统软件企业面临挑战，理论上互联网应用程序没有稳定版，新的特性源源不断加入，如果出现稳定版就意味着企业停滞。

互联网企业面临的问题是

需求频繁变更，一天一个想法，需求尚未成熟就开始投入开发软件生命周期短，以各种活动为例，很多功能是一次性的，软件生命周期可能是几周，几个月。
频繁交付新特性，不能像传统软件一样几个月甚至几年升级一次，我们需要应对互联网快速变化，可能需要每周升级一次，甚至每天升级数次。
随时可能回撤，随时做好回撤准备，要支持版本的任意切换
多项目并行开发，并行开发还会产生耦合依赖，升级顺序限制，集成测试更复杂。

随着Web 2.0 和云计算思想的提出，软件也在发生变化，软件运行不在限于一台物理机，而是多台服务器的集群中，传统的模块或原件，被独立部署在世界各地。

软件的开发面临前所未有的挑战：

异构平台，软件不限于那种操作系统，例如Unix,Linux,As/400,windows,Mac
语言混合开发，不在紧紧使用一种语言开发软件。每一种语言都有他所在领域的优势。
分布式，软件再也不是只运行在一个CPU下，软件被分成很多模块被分布式部署到多台服务上。

这时便出现了极限编程，敏捷开发….等等，同时诞生了新的岗位“产品”，新的思想不断提出，但是仍然无法解决面临的问题。

产品部：需如雪片飞来，需求堆积如山
开发部：版本延期，质量问题频发，疲于奔命修复 BUG，刚修复了一个，又出现新的 Bug
测试部：手工测试，升级后问题爆发，测试环境通过，到生产环境就出问题
运维部：环境不统一，每次部署都是一场灾难，配置易出错，回撤时间长，
团队现状：加班严重，效率地下，每天奔波救火

测试环境无法重现，开发人员直接在线上修改代码，跳过测试直接将代码交给运维升级

运维事故严重影响运营和广告投放

人员流动导致代码丢失

问题的原因在于，他们紧紧从各自部门的角度解决问题，同时 KPI 考核也不合理：

产品从产品的角度解决产品遇到的问题。
开发从开发的角度解决开发遇到的问题。
测试从测试的角度解决测试遇到的问题。
运维从运维的角度解决运维遇到的问题。

实际上现在的软件已经不是当年交付后一个网管就能搞定剩下的工作。同时软件开发交付周期缩的更短，一周甚至每天升级数次，遇到突发事件要做好随时准备升级。

总结这个时期实际上是：软件项目管理加 ITSM (IT Service Management) IT服务管理

所以聚焦微观管理解决宏观管理问题的做法是错误的，于是诞生了 DevOps。 DevOps 是多维度宏观管理学，是管理的管理。

为什么很多企业为什么实施 DevOps 以失败告终？

很多企业实施DevOps 紧紧是软件堆砌，根本没有深入理解 DevOps，吧devops 相关的软件全部安装上，然后做系统集成。

这时各部门一片抱怨声：

管理层说：项目管理工具不好用。
产品说：我不用那个Wiki写需求
设计说：版本控制对于PSD这种大文件兼容不好
开发说：我们不用 Docker，而我们也不用 maven
测试说：怎么随意部署环境，我们还没有测试完，就清空数据了。
运维说：我不敢用你的自动发布

可能用户需要打开浏览器数个窗口，频繁切换才能完成具体工作。

时不时就能听到有人在公司的QQ群、微信群、钉钉上有人喊，XXXX 环境又挂了。

改变现有的工作方式是非常痛苦的，任何不合理的流程和工作方式已经使用了多年，习惯已经根深蒂固。

实施devops 需要各部门收集意见，对各个部门培训，等各部门理解了 DevOps 原理和流程后，才能实施。

持续集成不是DevOps

Jenkins 不是 DevOps

持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。

持续集成只是 DevOps 中的一个小小的环节，并不是最主要的核心工作。

持续集成可以解决什么问题

能验证代码是否可以正常编译
验证组建或模块是否能够集成
验证自动化测试用例是否正常运行
测试环境的部署

持续集成不能解决什么问题

生产环境的发布
部署失败后回撤
不能构建环境，虽然支持 Docker

持续集成智能单向操作,例如

代码->构建->测试->部署 等等

持续集成中我们遇到很多问题

例如就是通过 git hook 触发 Jenkins 实现持续集成，自动构建项目。问题来了，任何提交都会触发一次 pipeline 脚本，当项目频繁提交时，第一个构建过程还未运行完毕，第二个进程便启动。导致构建排队，阻塞，同时 pipeline 可能会争夺资源（多个进程读写同一个文件），产生冲突，轻则稍等片刻，重则测试环境崩溃。

另外通过CI 持续集成部署代码也不靠谱，会出现和上面相同问题，例如第一个进程用 scp 复制 jar 包到远程主机，还未传输完成，第二个进程便做同样的操作。

还有第一个进程重启 tomcat ，tomcat 还未停止退出，第二个请求便发出。最终导致 tomcat 崩溃。

以上的特性，你敢在生产环境上使用吗？一旦发布失败，或者需要回撤，持续集成并没有很好的解决方案。

我认为，持续集成尚不完善，测试环境玩玩可以，生产环境还是不要了。

持续交付不是 DevOps

持续集成、持续交付、持续部署是一系列的软件工程实践方法，使用自动化手段达到完成软件。

持续交付(Continuous Delivery)和持续部署(Continuous Deployment)的区别

持续集成(Continuous Integration) 通过将每一次改动都提交到一个模拟产品环境中，使用严格的自动化测试，确保业务应用和服务能符合预期，最终产生构建产物。
持续交付(Continuous Delivery) 通过持续集成产生构建物，确保让软件产品能够快速、安全的部署到产品环境中。持续交付并不是指软件每一个改动都要尽快的部署到产品环境中。它指的是任何的修改都已证明构建物可以在任何时候实施部署。
持续部署(Continuous deployment) 是持续交付的更高阶段即生产阶段，就是将最终的产品发布到线上生产环境，给用户使用。所以当业务开发完成时，经过持续集成，持续交付后，你有信心只需要按一次按钮就能将应用快速并安全的部署到产品环境中。

请不要再混淆持续交付与持续部署了。

自动化部署

我习惯将持续部署(Continuous deployment)称为自动化部署

本章节重点谈自动化部署，每个人对自动化部署都有自己的理解，每个企业对自动化部署的需求也不同。

目前很多云平台开始推出一些列 DevOps 工具，体验了一下，仍然处在初级阶段，也不十分成熟。严格的说他们实现的 CD (持续交付)。

前面讲过持续集成不是 DevOps，这里我要说持续部署也不是 DevOps。自动化部署是从CI/CD中分离出来的，将部署单独提炼出来。

自动化部署远比 CD(Continuous Delivery) 持续交付要复杂，涉及包括

网络层：网络设备管理，负载均衡切换，路由表管理
系统层：基础设施，操作系统，软件运行环境，
软件层：软件部署
缓存层：缓存的刷新
搜索层：重建全文索引
数据层：数据库结构管理，数据库数据管理
日志层：谁，什么时间，做了什么操作，结果怎样
除此之外，管理上还需要提案和审批流程等等

所以 CD （持续交付）解决不了企业的生产环境自动化部署需求，CD紧紧是CI （持续集成）运行完成后，将构建物部署到指定的运行环境中。通常CD并不提供回撤功能，所以极少由企业使用 CD 部署生产环境。

Git -> 编译 -> 测试 -> 打包 -> 构建物 -> 部署 -> 运行

CI/CD 的流水线作业只能部署单一项目，对于大型网站就无能为例

例如很多大型网站

构建过程非常复杂，不仅仅是一个项目打包，而是需要多个模块，处理复杂的配置过程。
一次部署多台服务器，每个服务器可能有多个实例，实例间相互依赖关系
需要遵守严格的部署和启动顺序
记录部署日志，文件的新增，覆盖，删除
部署时间点
升级不仅仅是代码，还有数据库，缓存……
需要改变负载均衡设备节点，设置防火墙策略
需要有完备的回撤方案
除此之外好虚考虑增量部署和差异部署，例如部署100mb 以上的大文件，甚至GB尺寸的文件

很多 DevOps 方案注重 Docker，K8s解决方案。但实际情况 Docker 并不适用于所有场景，更多是物理服务器，虚拟机，云主机，刀片服务器…

使用 Docker 的前提是，Docker必须部署在宿主主机上，在云主机中部署 Docker 意义不大。

很多企业大量使用云主机，对 Docker 并无强烈的需求。

运维需要怎样的自动化部署工具

项目管理：升级提案，工作流转，工作审批
备份管理：任何生产环境部署前都需要备份，必须实现增量备份和差异备份。
环境管理：环境部署，基础设施管理
阶段管理：开发，测试，生产
仓库管理：分支切换，分支保护（例如只允许合并不允许提交）
配置管理：每个阶段拥有自己的配置
文件过滤：排除过滤，包含获取，替换过滤（替换指定文件中的内容，用户不同阶段的差异区分）
覆盖删除：覆盖指定文件，删除指定文件
内容优化：Grup, Webpack 优化，压缩js, css,html5, 图片雪碧图…..
自动构建：编译，测试，测试报告，打包
部署管理：节点管理，增量部署，差异部署，md5sum 校验检查
部署脚本：部署前脚本（停止），部署后脚本（启动）或者环境初始化，解决部署依赖
时间线：谁，什么时间，做了部署，可以指定时间点随时回撤到指定版本。
部署日志：谁，什么时间，做了什么操作，产生什么结果
部署报告：生产 Issue或Ticker 报告

持续集成与持续交付和持续部署的关系：

持续集成(CI) -> 构建物 --> 持续交付(CD) --> 交付验收环境 （Alpha）--> 验收成功
             \                                                    |                     
              \................................................../
                                         |
                                         V
                                      持续部署 ----> 生产环境 (Beta/Preview/Release) ----> 生产环境验收

收集各部门问题

实施DevOps前需要收集各部门问题

问题如下

产品线都多少条？
同时进行并行开发的多少条？
怎么进行项目管理？
产品团队的情况：怎样管理需求文档，多个产品人员怎样协作
设计团队的情况：都使用什么设计软件，一般文件尺寸多大
开发团队的情况：使用什么语言，什么框架，开发人员数量，采用哪种版本控制，急需解决的问题？
测试团队的情况：测试工具，测试的方法，测试用例怎样管理，人员数量，急需解决的问题？
运维团队的清况：服务器数量，云的使用情况，docker使用情况，运维工具，运维人员，急需解决的问题？
目前最迫切解决的问题是什么？
你的企业目前还面临哪些问题（非技术）？

有了这些数据，在DevOps工具选型是，你才能判断是否符合你的需求。例如很多商用工具的 License 是按照用户数收费的。有些则按照部署节点收费。

自运维的需求

例如下面是来自运维的需求
运维团队需要什么呢

合同管理
成本管理
续费管理
问题管理
突发事件管理
环境配置
设备管理
配置管理
自动化部署
监控和报警
备份和恢复

上面大部需求以用Issue/Ticket 凑合，但是有几个功能例如，环境配置，自动化部署，监控/报警，备份/恢复，这些就凑合不了，实打实的硬性需求。如果不能实现这些功能，就不能称为 DevOps。
我们就先从监控说起把，你很发现很多 DevOps 的文章中，不会涉及到监控，但是这是运维的重中之重。

收缩技术栈

技术部门常常会陷入技术思维，恨不得将所有主流技术都使用上，却忽略了他们兼容性，以及对该技术的掌握程度。

当团队没有100%掌握某项技术是，风险是巨大的，我们常常会看到网上有这种文章《XXX踩过的坑》，无疑是拿生产环境练手，为自己的职业生涯打怪升级。

大炮打蚊子，很多需求根本无需使用复杂的技术，最终变成庞然大物。

尽量使用一种技术解决所有问题，而不是使用所有技术解决一种问题。这样技术团队学习起来不会太吃力，且团队人力资源可以共享，测试难度和运维难度都会降低。

模块化思维

技术思维另一个误区就是，拆整为零，模块化。例如,用户中心，商品中心，订单中心，物流中心 ……

用户中心 —---—- 商品中心，
     |  \       /   |
     |    \   /     |
     |      X       |
     |    /  \      |
     |  /      \    |
  订单中心 ——---- 物流中心

看这个架构多么清晰

用户中心：负责用户注册，登录，找回密码
商品中心：商品分类，商品搜索，商品列表，商品展示
订单中心：订单报价，订单合并……
物流中心：对接物流平台……

技术人员的成就感飘飘然，然票票。运维根据需求将上面四个中心使用四台高配置服务器部署起来。
市场部需求

用户登录
浏览商品
下订单
走物流
用户积分+100

平时没有什么问题，订单量一大所有问题都暴漏出来，积分添加失败，库存数据出错，物流下单失败……
这种模式的问题有很多，例如

运维复杂，部署复杂，配置管理复杂
排查问题难度搞
分离后，通过网络连接，网络存在延迟和超时等等其他不可控因素
分布式事务处理，复杂且难以保证
分布式锁，并发的杀手

任何一个系统都不能简单的进行拆分，抓中拆分同样是我们教育的问题，导致思维方式产生问题。
15年前我就意识到这种问题所在，15年后去一下电商公司面试，发现他们仍然在采用这种模式。

被遗忘的数据库

在持续集成和持续部署中数据库常常被忽略。

实施 DevOps 对于 DBA 都不那些诉求呢？

这里我列举一些DBA的诉求

数据库备份与恢复，备份文件的安全
数据库结构版本控制
数据库快照
注入扫描
撰改报警
SQL 审计
数据库监控
脏数据处理

上面每一项都需要单独拿出来分析，例如监控。

数据库监控有可以细分为

IP 地址，包括端口，服务
同步状态
连接数
缓存，命中率
SQL语句调用统计

等等

总之 DBA 需要知道，谁，什么时候，登陆了数据库服务器，做了什么操作。随时可以备份数据，恢复数据。

另外还有数据文件一致性的需求

什么是数据文件一致性？举一个例子，用户头像是一张图片，存储在用户数据表中如下

ID | USERNAME | ICON
------------------------------
  1 | neo      | /images/neo/Avatar.jpg

可能存在数据存在，图片找不到；或者有图片，没有数据的情况。这里只是一个例子，实际场景更复杂，例如银行票据，合同等等。

建立中心仓库

DevOps 需要一个核心仓库，用来管理构开发包，容器，以及建物等等。

仓库可以分为三种类型，分别是

和基础设施库
容器仓库
软件依赖仓库

基础设施库包括: Yum,Apt,Snap

容器仓库包括 Docker, Helm

软件依赖仓库包括

Maven
Gradle
npm
PyPI
Ruby Gems
PHP composer
CPAN

为什么需要建立这些仓库呢？

首先构建物是公司的私有资产，不可能放在开放的仓库内。其次，使用外部仓库严重影响构建速度，例如下来速度慢和一些不可控的因素，挂起，闪断等等。

通常我们将私有自建的仓库和DevOps系统放在一起，以加速构建速度。

缓存

缓存可以帮助构建程序显著提高执行速度，DevOps 涉及到的缓存包含

源代码缓存
软件开发包缓存
构建物缓存

另外，软件开发包缓存和构建物缓存的版本通常是递增的，所有无需考虑缓存过期的问题，但是需要考虑下载过程中出现的损害。

常见的损坏包括

源代码版本控制文件损坏，导致代码无法更新
软件开发包依赖文件损坏，导致无法编译
构建物损坏，导致无法部署，启动

安全

DevOps 需要考虑几点安全问题

隔离安全
环境变量安全
日志安全

对于单一用户，这些问题没有那么严重，但是对于多用户系统或基于 SaaS 的 DevOps 的平台来说这就是大问题。否则会出现 A 用户可以访问 B 用户资源的问题。甚至做出一些恶意操作，下载源码，植入木马等等

发布于 2021-01-13 14:01

先来一张“工具周期表”来看一看吧～

发布于 2017-10-28 22:21

分享一下我们在实践中经常使用到的软件：

1.GitLab

GitLab 是一款基于 Git 的完全集成的软件开发平台，而且包括了wiki在线编辑，issue跟踪，CI/CD等功能。

一般中小企业会使用GltLab搭建私有代码仓,可以直接使用GitLab CI 运行 GitLab Runner 执行 Pipeline

这种方式的好处就是：

容易配置，入门门槛低，集成在GitLab中文档齐全，源代码安全，管道自动化，提供简易的可视化页面。

详细文档可见： https://docs.gitlab.cn/jh/ci/quick_start/

2.Jenkins

Jenkins是一种用Java编写的开源自动化服务，它可以充当持续集成(CI)工具，使开发人员可以更轻松地将新组件集成到软件中以实现无缝集成。Jenkins使用插件进行集成来实现这一目标。

Jenkins侦听新的拉取请求，将新的工作分支合并到主代码中，运行自动化测试套件，生成新的测试数据，并报告失败的情况，以及将最新的代码更改部署到质量保证(QA)环境以进行人工测试。

Jenkins管道用于实现持续集成过程的自动化表达。用户可以在管道中定义构建文件，将它们加载到SCM并配置作业变量。

Jenkins已经存在了很长时间，并且由于其成熟的生态系统、插件支持、文档和社区，实际上已经成为一个标准。Jenkins在过去几年中提供了几次更新。它已成为许多公司的首选之一，因为它为管道和Docker集成提供了简单的用户体验(UX)/语法。

但是Jenkins也有一些缺点：

脚本不容易编写和编辑，需要有经验的运维人员

需要人工配置构建，硬编码配置文件和宽松的访问控制

详细文档可见: https://www.jenkins.io/

3.Zadig

Zadig 是 KodeRover 公司基于 Kubernetes 自主设计、研发的开源分布式持续交付 (Continuous Delivery) 产品，具备灵活易用的高并发工作流、面向开发者的云原生环境、高效协同的测试管理、强大免运维的模板库、客观精确的效能洞察以及云原生 IDE 插件等重要特性，为工程师提供统一的协作平面。Zadig 内置了 K8s YAML、Helm Chart、主机等复杂场景最佳实践，适用大规模微服务、高频高质量交付等场景。

Zadig 可以通过简单的配置自动生成高并发工作流，多个微服务可并行构建，并行部署等。Zadig的构建分为两部分，一部分是基于Zadig自己的构建，另一部分是基于Jenkins构建。两种构建方式可满足大部分中小企业需求。

但是Zadig是默认基于云原生环境，部署时需要运维人员对Kubernetes 有一定了解，同时Zadig对服务器资源也有一定要求。

详细文档可见： https://docs.koderover.com/zadig

发布于 2023-03-24 11:18

一套灵活高效的PaaS云研发面板或许是答案——帮助企业快速高效落地DevOps。

DEEPEXI® RDP（R&D Panel）研发面板作为 deepexi.com 线上订阅模式的技术PaaS基座，为企业提供灵活高效的数字化系统建设全生命周期研发管理。

研发面板囊括行业主流的 DevSecOps 落地实践，面向开发者友好的工具包，打破传统工程化项目交付和新型敏捷迭代管理的边界，结合 OKR 实现需求可追溯、结果可度量的数字化管理。

快速咨询

登陆下方链接申请售前咨询，联系人姓名中加上推荐码 deepexi@zhihu 将有专人联系开通。

deepexi.com 研发面板四大态

管理态

管理态（D-Baton）定位为敏捷协作平台，基于 Scrum+Kanban 敏捷开发方法，建立需求池-迭代计划-任务体系，将抽象发散的客户诉求逐步细化为可落地开发的任务，提升研发效率。

▼使用对象及场景

▼产品特性

支撑敏捷研发

为需求管理、迭代规划、进度跟踪等经典 Scrum 环节提供工具支撑。

优秀的用户体验

自研日程式任务看板，支持分组、拖动等，兼备“TODO”功能，更清晰，更符合项目成员使用习惯。

效能度量统计

提供研发数据统计与可视化报表，可衡量并持续提升研发效能。

一站式研发协同

与开发、测试、运维等阶段深度集成，提供一站式的研发协同体验。

▼功能清单

开发态

开发态定位为低代码开发平台，包含前端可视化开发（D-Designer）和后端即服务（D-Insant）。通过可视化、拖拽式、配置式等操作进行开发动作，快速开发出前端应用和后端服务，并提供前端应用代码下载，在线后端API服务，减少了开发过程中冗杂的、重复性的编码工作。

前端可视化开发：通过丰富的模块物料进行在线页面可视化设计，无需编写代码，即可快速制作应用；通过服务资源池，前端应用可统一调用各后端服务的API接口资源；自研UI Flow设计面板，支持深度的界面交互逻辑设计。

后端即服务：数据库原子服务，提供基于数据库快速生成的单表基础原子接口能力，不需要额外编写代码；编排服务，提供在线可视化接口编排设计，利用已有接口进行低代码新接口编排定义；FaaS服务，提供函数运行环境，编写函数即生成在线服务。

▼使用对象及场景

▼产品特性
应用开发

支持拖拽式组件拼装，可快速组装页面内容
支持组件样式设置，满足不同的视觉设计
支持自定义动态数据流，实现页面动态数据及页面数据请求。

服务开发

支持快速自动生成数据库原子服务接口，并提供在线原子API服务
支持编排新的服务接口，并提供在线原子API服务
支持引入自定义服务，通过配置路由，实现网关转发。

▼功能清单

质检态

质检态定位为一站式测试及交付平台，包含持续集成CI/持续交付CD（D-Bridge）、制品仓库（D-House）和测试平台（D-Tester）。

▼D-Bridge：持续集成CI/持续交付 CD
提供基于"流水线"的定制化 CI/CD 能力，定位于企业级应用流水线和持续交付解决方案。

支持对单元测试、代码质量扫描、构建、镜像推送、部署、接口测试、人工审核、自定义脚本等任务的自由编排，并支持自动触发和定时触发，具备简单易用、可视化、高可扩展、高可用性等特征，提供云原生、完整及成熟的接入服务解决方案。

▼D-Bridge 使用对象及场景

▼D-Bridge 产品特性

可视化管理

D-Bridge 提供可视化管理能力，能够方便的对应用的流水线和持续交付管理。

高可用

D-Bridge 支持高扩展性，利用 Kubernetes 能力实现高可用版的 Jenkins。

节约资源

D-Bridge 的 Jenkins 支持动态创建 Pod 执行 Pipeline ，执行完即销毁。

快速集成能力

D-Bridge 支持通过可视化管理能力快速集成功能，能够做到让企业基于自身场景快速进行功能整合。

快速部署

D-Bridge 提供快速部署方案，方便使用者快速地部署一套全新的ALL-IN-ONE的最小 D-Bridge 系统，从而能够快速体验 D-Bridge 的能力。

隔离

采用微服务架构将系统分解为独立运行单元给系统带来更好的隔离性，独立的微服务在发生异常时更容易定位和隔离问题，隔离性也是服务扩展性的基础。

▼D-Bridge 功能清单

▼D-House：制品仓库
通过安全可靠的软件仓库，实现软件包版本管理，提升发布质量和效率，实现产品的持续发布。

▼D-Tester：自动化测试平台
覆盖测试管理、接口测试、性能测试，融入DevOps敏捷测试理念，帮助用户高效管理测试活动，保障产品高质量交付。基于 JMeter，稳定可靠，采用 Runner 架构，易伸缩，可应对高负载场景（如性能测试、压力测试）。

▼D-Tester 使用对象及场景

▼D-Tester 产品特性

界面UI

界面简洁，操作简单，交互方便，可随便拖拽并进行排序。

功能模块

固定测试套件可用接口库统一管理，形成基础套件库，可以在这个基础的套件库不断的扩展，减少重复造轮子。

业务场景

支持复制业务场景，可将前一个接口的出参提取出来作为后续接口入参。

运行方式

可单独执行接口，单独执行用例，或者任务，可以灵活选择配置和环境。

分布执行

单个用例和批量执行结果会直接在前端展示。

环境管理

可添加运行环境，运行用例时可以一键切换环境。

报告查看

所有异步执行的用例均可在线查看报告，测试报告可从多维度查看。

定时任务

可设置定时任务，遵循crontab表达式，可在线开启、关闭。

架构设计

接口执行是单独微服务（TestRunner微服务），当压力大时，可单独对执行的微服务进行动态扩展，支持Restful Api调用，方便对业务管理功能二次扩展或者接入第三方的用例管理系统。

产品设计

可单独形成产品，也可以与DevOps结合，形成DevOps闭环。

持续集成

与DevOps的流水线结合，定义好触发时机，做好持续集成。

运行态

运行态（D-Runtime）定位为云原生运行环境，提供高可靠高性能的企业级容器应用管理服务，支持Kubernetes社区原生应用和工具，简化云上自动化容器运行环境搭建，一站式部署和运维容器应用，支持弹性伸缩，并提供完善的监控告警服务，帮助及时发现问题，快速定位并解决问题。

另外也提供主机托管与集群托管等完备功能，能够满足企业互联网架构的日常运维场景；基于 Ansible & Kubernetes & Helm 等主流开源应用打造，稳定可靠、弹性、安全；支持细粒度的资源管理、分配，方便运维人员对资源进行精细控制。

▼使用对象及场景

▼产品特性

可视化操作，简单易用

传统情况下，用户管理自己的容器通常涉及安装、操作、扩展自己的集群管理软件，这些系统的可用性和管理较为复杂。而使用本产品您只需要导入集群并创建部署即可，所有集群管理工作将由 D-Runtime 完成。

支持多云环境，适配多家云厂商

可添加不同云厂商的主机，将应用部署到不同云厂商，按需使用。同时，您可以将自己私有云或者在云厂商上的 kubernetes 集群，加入到 D-Runtime 平台云容器服务，进行统一管理。

多租户支持，安全隔离环境

为了高效利用资源，在资源池化的基础上，实现多租户支持，按需分配，同时进行视图隔离、操作隔离，网络隔离，保证客户的应用安全。

与流水线整合使用，简化部署

研发面板能够根据用户角色进行细粒度的菜单显示、接口访问权限等控制。与流水线产品整合，实现持续集成，为节省企业资源，支持临时创建环境，并可设置策略销毁。

整合服务器，降低运营成本

通过虚拟机来整合多个应用，容器隔离应用的能力使得容器可以整合多个服务器以降低成本。

▼功能清单

deepexi.com 平台订阅服务模式支撑

滴普基于 deepexi.com 系列产品功能，分配经验丰富的业务架构师，可针对客户需求提供完整的解决方案，提供线上 + 线下完整培训及专业运营咨询，及时解决产品使用过程中的问题，为客户提供灵活高效的数字化系统建设全生命周期研发管理。

咨询服务

快速咨询

登陆下方链接申请售前咨询，联系人姓名中加上推荐码 deepexi@zhihu 将有专人联系开通。

发布于 2020-07-28 17:54

如果团队人数少，技术栈或者技术债务不是很多，历史包袱不重，领导急于看到成果，可以使用devops私有产品。前提还是看他们产品是否满足你们目前场景。

自建工具链，分成简单工具搭建和更上一层的二次开发做平台，看你们需要哪种。前者相对容易点，后者前期需要投入成本，还是看你们目标是什么，解决什么问题。从你介绍的团队规模，简单工具搭建就可以，可以满足。

如果是国企不差钱，选私有化产品也是可以的，私有化方面可以用腾讯系蓝鲸，这方面经验更丰富，阿里云效技术上没话说

发布于 2022-12-04 22:02

应该问：那种工具组合，适合中小企业开发？

从CI/CD的整个流水线看，你必须要有一个自己的工具链，而上图所有的工具都是开源的。你需要从精简的模型开始，逐步搭建适合自己的工具链。

对于中小企业来说，我的建议是：GitLab+构建和测试工具（忽略介绍，根据你自己的开发语言自己选，用最主流）+部署平台K8S+监控ELK/prometheus/Grafana

工具链的搭建和与项目的集成是一种工程能力，相对来说比较考验Dev，前期考虑找有经验的人带路，中小企业的规模，DevOps的所有相关实践都是非常可实现和可操作的。

编辑于 2018-02-24 00:48

自 2008 年在多伦多敏捷会议上,Petrick Debois 提出“DevOps”一词以来。经过十三年的发展,DevOps 已经被视为企业发展的关键,绝大多数的组织都正在引入 DevOps 以应对更复杂的开发需求和环境。但如何才能成功实践 DevOps 至今依旧是待解问题。

Puppet 发布的2021年度DevOps 状况调查报告指出,83% 的 IT 决策者表明他们的组织正在实施 DevOps 实践;与此同时,绝大多数组织仍然停留在 DevOps 演变的中期阶段。企业在落地 DevOps 实践时,仍面临许多挑战,因此,业界也在多年的实践之中,总结出一些关键要素,来帮助推动 DevOps 实践。

DevOps 关键要素

目前 DevOps 实践中的一些关键要素注重文化层面,由DevOps 标准核心编写专家总结出 4 个关键要素。
一个关键因素是 IT 部门和业务部门的目标要对齐。
IT 部门和业务部门常常有矛盾。如业务部门对 IT 部门的不满来自四个方面,一是 IT 人员与业务部门沟通补偿,缺乏系统性的运营管理思维,导致业务部门认为双方愿景无法匹配;二是 IT 部门聚焦过程而非结果;三是 IT 部门总是在解决自己的问题,忽略了产出,同时会不断有新的问题出现;四是对于业务部门来说,整个 IT 内部像是一个黑盒子,因为管理部门通常会说 IT 部门是无法控制的黑盒,专注于技术,缺乏沟通,同时 IT 人员及各种服务设备越来越贵,功能不透明等等都让业务部门认为难以沟通。
反过来,为什么 IT 部门做了很多事情但是业务部门不买账?IT 部门对业务部门也有许多不满,他们会认为业务部门的许多需求不够清醒,从开发初期到上线需求一直在改;另外业务只提出高优先级,常常没有低优先级,难以分出哪个需求是最高优先;不知道业务指标和收益,不清楚开发出来的功能有多大效果。
因此,目标对齐非常重要,IT 部门和业务部门之间要做好充分的联合,聚焦客户价值,关注客户的实际需求、满意度等等。

第二个关键要素是人员和文化。
传统的开发模式下一般是项目制,同时把各个项目分割成不同的开发阶段,包括需求、定义、设计、编码、单测等等,同时使用里程碑方式,严格定义开发阶段的输出,达不到相应输出则不能展开下一阶段工作。这种工作模式将开发阶段定义成黑盒,希望每个人阶段的技术人员只关注自己阶段的工作,好处是可以让不同角色的人员专注本质工作,提高阶段效率;坏处是出现问题可能会互相推诿,并且由于每个开发阶段的信息相对封闭,会造成大面积的理解偏差。
Puppet 发布的 2021 年度 DevOps 状况调查报告同时还指出,绝大多数组织仍然停留在 DevOps 演变的中期阶段,其中文化问题是 DevOps 取得成功的最大障碍。
调查结果显示,只有 18% 的受访者拥有高效的 DevOps 团队,4% 处于低功能状态,大多数(78%)处于中间状态。虽然处于中间状态的组织表示,他们正在建立 DevOps 文化。但 Puppet field CTO Nigel Kersten 认为,“仍然存在组织对变革的抵制,这是一个真正的问题。而且人们真的没有看到他们实际上试图通过 DevOps 实现的实际价值。”中层最常见的文化阻碍因素包括有:不鼓励风险的文化 (21%)、不明确的责任 (20%)、不优先考虑快速流程优化 (18%) 和不充分的反馈循环 (17%)。
因此做好 DevOps 的文化工作,让团队熟悉 DevOps 的流程及相关操作规范至关重要。

第三个要素是流程。
对于一个项目来说,在立项之初,大家对项目的关注度和期望很高,因此刚开始时有较高的能见度,但在执行过程中,能见度会越来越低。所以在敏捷开发中会采用迭代开发方式,项目全程可见度高,并且不断与客户探讨相关需求,根据反馈做改进,这样达到的最终结果是业务价值持续稳步上升,同时风险也被很好地控制。

第四个要素是平台。
在挑选平台时,往往要注意的点通常包括自动化、可视化、自主服务。自动化需要做到标准化;同时通过平台达到自动服务也非常关键;还有可视化,包括端到端流水线的可视化,度量可视化,业务数据、研发效能、质量、速度、满意度等等皆可通过可视化方式改进。
关于自动化,有三个关键前提。第一是标准化,需要有相应流程和规范的梳理,只有形成流程和规范的标准,后续的相关维护与功能拓展才能使用版本化的管理方式。第二方面,对于平台化建设的自助服务,其中最关键的是打造一个尽可能傻瓜式的自助服务平台。第三方面涉及平台度量的可视化,包括合规的展示,安全和开源合规也尤为重要,此外关于可靠性的展示也非常重要。
关于第四要素平台的一些特质,飞算云智总裁陈定玮在近期的访谈中也提到,飞算 SoFlu 全自动软件工程平台上通过制定系列标准,来规范软件工程全流程开发管理。飞算 SoFlu 全自动软件工程平台团队将前沿大厂使用的开发规范结合实际遇到的问题处理方式后,从效率、安全等多方面考虑,制定了自己的代码规范。比如,限定每行代码的写法、有些地方不允许 SQL 拼接、Join 不允许超过三次等。除了规范,所有的代码还必须接受严格检测,确定没问题后才会被提交到代码仓库。同理,所有组件也必须经过代码质量管理工具扫描无误后才让用户使用。现在,飞算 SoFlu 全自动软件工程平台的质量管理平台上已经有一千多条标准,而新的规则也在不断被加入其中。

企业的 DevOps 实践

在这些关键要素的基础之上,企业想要完整落地 DevOps 实践,首先需要确立从项目到产品的研发模式。第二借助 DevOps 平台,通过那些服务属性的功能,支持产品开发与业务上线,同时建立相应的防御和审批措施。第三在部署方面,新的部署方式可能逐渐会有运维人员支持做上线,演变成平台全流程支持,随着平台建设越来越完善,能够提供足够多的监控和审计功能,当项目制演变成产品制之后,产品开发团队就完全可以做到自助式流程变更甚至代码提交等等。第四,要非常注重用户体验,包括在做 DevOps 自动化部署平台时,也要关注运维相关体验,从开发到测试以及最后维护环节所有使用人员的体验。

对于企业引入 DevOps 流程,在平台之上实现敏捷开发,陈定玮也提出了自己的看法,在他看来,平台如果不能真正帮助企业降本增效,反而是害了企业。因此,他也一直强调自己是交钥匙工程,“未来企业不需要继续依托我们进行维护和迭代,并且在部署层面可以节省企业很多资源。平台分布式、可弹性扩缩容的设计理念相当于帮企业做了中长期的规划,只需要适时增加硬件资源即可帮助业务快速上升,无需对结构进行大的调整。”

未来,随着 DevOps 平台的不断发展与完善,企业在落地 DevOps 实践时,将有更多可依靠的标准,趁手的工具,以及专业的指导,来达成愈发成熟的实践。

编辑于 2021-12-10 18:30