DevOps平台工具的4个阶段

笔者做DevOps平台也有不短的时间，之前看到一张很有意思的图（见下图），当时没有细想，后来回头看这张图，还是很有意思的。 工具，特别是平台化的工具落地，一定不是一蹴而就，需要逐步推进落地。 01 如上图，在没有统一的DevOps工具平台之前，每个研发环节都有自己独立成熟的管理工具，因为在瀑布式的研发模式中，每个环节是相对独立，术业专攻。 工具太多，切换麻烦；阶段割裂，限制流动；数据不通，无法度量； 这是DevOps工具 v1.0要解决的基本问题，不论是采用自研方式还是采购第三方平台。 笔者在自己的团队虽然积累了一些经验，但是更多的，是需要SM或者PO共同去探索实践方式，让DevOps平台更好地去承载这些实践，摸索出符合自身团队场景的最佳实践出来。 DevOps平台应该成为蕴含持续集成理念，倡导卓越工程实践的平台。 往期推荐： 测试职业规划的思考 荒废2023，从纠结开始 关于写作这件事 2022年的我 在职场上拥有选择的权力

DevOps平台工具的4个阶段

笔者做DevOps平台也有不短的时间，之前看到一张很有意思的图（见下图），当时没有细想，后来回头看这张图，还是很有意思的。 工具，特别是平台化的工具落地，一定不是一蹴而就，需要逐步推进落地。 01 如上图，在没有统一的DevOps工具平台之前，每个研发环节都有自己独立成熟的管理工具，因为在瀑布式的研发模式中，每个环节是相对独立，术业专攻。 工具太多，切换麻烦；阶段割裂，限制流动；数据不通，无法度量； 这是DevOps工具 v1.0要解决的基本问题，不论是采用自研方式还是采购第三方平台。 笔者在自己的团队虽然积累了一些经验，但是更多的，是需要SM或者PO共同去探索实践方式，让DevOps平台更好地去承载这些实践，摸索出符合自身团队场景的最佳实践出来。 DevOps平台应该成为蕴含持续集成理念，倡导卓越工程实践的平台。

DevOps平台工具的4个阶段

笔者做DevOps平台也有不短的时间，之前看到一张很有意思的图（见下图），当时没有细想，后来回头看这张图，还是很有意思的。 工具，特别是平台化的工具落地，一定不是一蹴而就，需要逐步推进落地。 01 如上图，在没有统一的DevOps工具平台之前，每个研发环节都有自己独立成熟的管理工具，因为在瀑布式的研发模式中，每个环节是相对独立，术业专攻。 工具太多，切换麻烦；阶段割裂，限制流动；数据不通，无法度量； 这是DevOps工具 v1.0要解决的基本问题，不论是采用自研方式还是采购第三方平台。 笔者在自己的团队虽然积累了一些经验，但是更多的，是需要SM或者PO共同去探索实践方式，让DevOps平台更好地去承载这些实践，摸索出符合自身团队场景的最佳实践出来。 DevOps平台应该成为蕴含持续集成理念，倡导卓越工程实践的平台。

DevOps平台

3.1 DevOps平台.md DevOps定义（来自维基百科）： DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops） hudson.plugins.git.UserRemoteConfig> <url>http://xxxxx.git</url> <credentialsId>002367566a4eb4bb016a4eb723550054 以下图为例，整个流程的底层为：paas平台-jenkins-kakfa-管理平台（选择cicd的下一步）-kafka-cicd组件调用管理平台触发构建-jenkins-kafka-管理平台（选择cicd 的下一步）-kafka-cicd组件调用管理平台触发部署。 有兴趣可以参考下：Knative 初体验：CICD 极速入门 四、产品化后的DevOps平台 在调研DockOne以及各个产商的DevOps产品时，发现，真的只有阿里云的云效才是真正比较完美的DevOps

DevOps 平台

DevOps 平台建设关键点还是在人，千金易得，一将难求。抛弃吹嘘，不要浮躁、踏实下来真正深入业务，支撑业务。 它都没上过陆地，这辈子都没见过猪，它哪知道猪是什么样.有明确的目标什么是 DevOps 平台，有哪些关键功能哪些可外采，哪些采用开源，哪些自建有哪些模块，哪里去找人，谁比较精通，谁来负责，大概里程碑有哪几个 如果自己现在还没想好，那就招聘牛逼的人来做，找到能做好研发效能的人长时间的投入任何一个 devops 平台没有长时间的投入都很难做出来。 阅读我的更多文章研发效能负责人/研发效能1号位｜DevOps负责人找到能做好研发效能的人

前端构建 DevOps - 搭建 DevOps 基础平台（中）

前言 搭建基础平台搭建上篇的时候的时候，已经介绍过了项目流程设计、数据库搭建、jwt 登录等模块。 此篇我们介绍分支管理设计及其他的基础模块。 后端模块 DevOps - Gitlab Api使用（已完成，点击跳转） DevOps - 搭建 DevOps 基础平台（已完成 50%）基础平台搭建上，点击跳转 DevOps - Gitlab CI 流水线构建 DevOps - Jenkins 流水线构建 DevOps - Docker 使用 DevOps - 发布任务流程设计 DevOps - 代码审查卡点 DevOps - Node 服务质量监控 后期可能会根据 DevOps 项目的实际开发进度对上述系列进行调整 Git 分支管理流程 Git Flow 流程 ? 流程都要结合真实项目需求来设计，上述只是一种解决方案，有更通用的方案设计请加我微信 Cookieboty 探讨 DevOps 开发中篇 添加全局报错回调 没有绝对安全的程序，所有程序在运行中因各种情况会出现

前端构建 DevOps - 搭建 DevOps 基础平台（上）

此系列即是持续交付项目的教程亦可作为 node 开发的教程来使用，从开发-测试-构建-部署的一整套 DevOps 项目 一共包含如下 2 个系列，分为前后端两个模块 后端模块 DevOps - Gitlab Api使用（已完成，点击跳转） DevOps - 搭建 DevOps 基础平台（已完成 30%） DevOps - Gitlab CI 流水线构建 DevOps - Jenkins 流水线构建 DevOps - Docker 使用 DevOps - 发布任务流程设计 DevOps - 代码审查卡点 DevOps - Node 服务质量监控 前端模块 DevOps - H5 基础脚手架 DevOps - React 如上图所示，将上一篇的发布流程更进一步的细化可以分为下面 4 类： 单项目发布流程（一个需求只需要一个工程完成） 生产环境出问题，快速回滚功能 集成项目发布流程（一个需求可能会有多个工程参与开发、发布） Bug 修复发布流程（无需求，需要快速修复线上已知但不紧急 bug 的发布流程） 任务流的设计其实非常复杂，为了加快交付第一版，先将任务流固定为以上 4 类，减少开发量，后期会添加或者修改某个流程 数据库设计

#DevOps 的前世今生# 4. DevOps 的文化

用工具堆砌的DevOps 幻觉 在第一届 DevOpsDays结束后，DevOps 运动则如星火燎原之势在全球发展开来。随着 DevOps 思想的不断传播，相对的质疑和批评也从未停止过。 以至于到今天对于 DevOps 的定义还是众说纷纭，争论不休。 当人们还在争论 DevOps的时候，一批基于敏捷的工程实践和自动化工具带着 DevOps 的标签走入了人们的视野。 这就是DevOps ？ 这不是DevOps ! DevOps文化的特征 那么，DevOps的文化看起来应该是什么样的呢？

DevOps平台之看板设计

本文从需求分析角度入手，分析DevOps产品对看板的需求，并结合普元DevOps产品看板部分的实际开发经验和用户反馈向大家介绍DevOps看板的设计实践之路。 结合对价值流的概念以及三步工作法原则的分析，看板需要具备以下功能： （1）清晰描述最小工作项单元及工作项间的关系 （2）提供便捷的小组成员互相沟通方式 （3）快速直接的反馈某工作项的各种情况 （4）一目了然的任务完分配集成情况 （4）时间信息（创建时间、预估时间、耗费时间、到期时间） 提供明确的时间信息，有利于项目管理者控制项目开发进度 （5）关联的工作项（子任务、Bug） 将有关的工作项关联到一起，完整描述产品中某一项功能 （4）时间甬道 ? 以上就是普元DevOps产品看板模块的设计和实践历程，在价值流可视化和项目成员沟通等方面我们仍在持续改进，希望能打造出更便捷、更清晰的看板，完善DevOps平台看板模块。

DevOps平台架构演进

附最新架构图https://www.processon.com/view/5cbd897de4b0bab90962c435 导读 系统架构是一个系统的灵魂，然而一个好的架构（或者更确切的说，一个合适的系统架构 研发协同平台提供从“需求->开发->构建->代码质量->测试→发布”的全链路的一站式服务，基于敏捷研发、持续集成、持续交付、DevOps等研发理念，主要是为开发团队赋能，提升交付效率和质量。 除了原有的架构重构外，在产品层面, 整个交付链条延伸到了C/D环节，这里和其他DevOps平台一个很不一样的点就是，在研发协同平台上交付的产品是ERP产品，ERP产品是运行在大量客户的不同环境下的，它不是交付一个 服务集成，与测试平台集成 平台要与其他产品打通 - 与运维产品打通，获取客户运维数据，做到DevOps闭环，通过反馈和运维数据反向推动产品持续迭代改进 平台要对外开放，面向生态合作伙伴提供服务能力，对外开放 附最新架构图 DevOps平台技术架构 (3).png

DevOps工具介绍连载（4）——SALTSTACK

3|0saltstack的运行方式 Local 本地运行，交付管理 Master/Minion <<< 常用方式 Salt SSH 不需要客户端 4|0salt部署基本架构 在安装salt https://mmbiz.qpic.cn/mmbiz_png/5OND0ssZ3iaO0mbWfibM2NQ39IicqnT1JQGia8carNRfa0ZBx025yJHYobyKjFlFAa8Ag4CjFJQW45Oq2ogKaxLrjA https://mmbiz.qpic.cn/mmbiz_png/5OND0ssZ3iaO0mbWfibM2NQ39IicqnT1JQGia8carNRfa0ZBx025yJHYobyKjFlFAa8Ag4CjFJQW45Oq2ogKaxLrjA salt-key Accepted Keys: salt1-minion.example.com salt2-minion.example.com salt3-minion.example.com salt4- master 192.168.11.72 ~]$salt -G 'osrelease:7*' test.ping slave: True #找出ip地址 salt '*' grains.item fqdn_ip4

DevOps 运维平台审计开发

DevOps之运维平台构建

写在前面的话 如今很多人认为devops将彻底取代传统运维，我不这么认为，在我看来devops只是很大程度上的代替了传统运维的手工操作，运维人员只需写好自动化运维脚本，利用自动化工具（zabbix，elk 因此Devops能否顺利落地，运维平台的建设将会很重要。本文主要简单介绍下我司的三大运维平台。 运维职责 ? ? 运维平台 当前我司运维平台主要有3个： 持续集成和交付 ①基于Jenkins持续构建 ②支持容器化打包和部署 ③发布平台，支持灰度发布，异常快速回滚 监控告警平台 ①完善的监控体系：覆盖机器、网络、服务和客户设备维度 平台演示 ? 后续会基于Jenkins开发一个Devops集成平台，将这些系统进行整合，以便更好地支持前端业务交付。

DevOps平台之开源技术图谱

目录： 1.DevOps平台第三方服务集成概览 2.DevOps平台第三方服务集成思路 3.DevOps平台第三方服务集成示例 1.DevOps平台第三方服务集成概览 说明：DevOps平台所有集成的第三方服务信息都保存在平台管理的服务集成页面 4、质量分析服务器 DevOps平台采用的质量分析服务器为SonarQube，SonarQube 是一个用于代码质量管理的开源平台，用于管理源代码的质量。 5、项目管理服务器 DevOps平台的项目管理我们采用的是Jira和Zentao这两个专业化的工具，依靠这两个工具支持起了DevOps平台的项目管理、概览和任务三大模块，用户可以很便捷的在DevOps平台查看编辑项目的基本信息 1 ）研究GitlabAPI接口 GitlabAPI接口我们可以直接从官网的相关文档查阅，按照官方的说明，自GitLab 9.0起，API V4是首选使用的版本。 4.总结 在集成一个第三方工具时，关注点无非就是如何调用API接口以及将得到的返回结果如何展示，除非API接口调用行不通，才会考虑做一个数据库的集成，在做数据库集成的时候还要小心再小心，如果存在关联表情况

平台工程如何改进 DevOps 协作

平台工程如何改进 DevOps 协作 本文翻译自 How Platform Engineering Can Improve DevOps Collaboration ，更多链接请点击阅读原文。 我们都在谈论平台工程这一事实是否意味着 DevOps 从未真正修复过开发人员和运营团队之间的关系？如果是这样，平台工程如何提供帮助？ 那么为什么平台工程还没有成为现状呢？我们都在谈论平台工程这一事实是否意味着 DevOps 从未真正修复过开发人员和运营团队之间的关系？如果是这样，平台工程如何帮助修复这种关系并使其更有成效？ DevOps 的局限性 DevOps 不仅仅是一种交付软件的新方式。它还带来了一种全新的方式来思考您作为团队中个人的角色以及您如何与周围的人互动。 如果有什么东西可以完成 DevOps 在将近 20 年前首次提出时应该完成的工作，那么这种向产品思维的转变可能就是它。

DevOps工具链胜过现成平台

寻找企业级 DevOps 平台的浪潮正在形成，但有迹象表明，这些平台在性能上无法胜过将最佳单项工具组合起来的 DevOps 工具链。 平台工程可能会进一步扩大平台和工具链之间的差距，为开发人员提供定制的、针对组织的预组装工具链。 DevOps 平台 DevOps 平台的概念比 DevOps 早了几年。 这可以满足企业对 DevOps 平台的定义。你的部署流水线将包括一个命令序列，使用命令行界面和 API 调用来执行每个步骤。这样一个平台的价值很低。 平台工程可以提供帮助 平台工程与 DevOps 运动深度相关。 根据我们对 DevOps 工具链的评估，你可以看到为什么平台工程存在于 48% 的高绩效 DevOps 组织中，根据 Puppet 的“平台工程状态报告”。

平台工程是 DevOps 的未来

---- Gartner 预测到 2026 年时，将有 80% 的软件工程组织会建立平台团队 DevOps 与平台工程 DevOps 是一种文化和理念。 平台工程，是我们实现“谁构建、谁运行”的唯一方式。这是 DevOps 的核心初衷，也是后来企业级规模和云原生时代的实现基础。 DevOps 最初的想法非常简单，基本目标就是消除开发人员和运营人员间的障碍，促进双方协作。达成目标的方法基本就是做左移，实现“谁构建、谁运行”。 DevOps 的基本诉求“谁构建、谁运行”可以实现。但 PaaS 只能提供一条路径，只能通过简单设置支持相对不那么复杂的用例。 ， 服务于企业平台层中内部开发者平台的核心引擎，是平台工程、团队和组织中的解决方案之一。

平台工程如何应对DevOps挑战

一览 DevOps 的核心挑战，以及平台工程是否可能取而代之。 许多人认为平台工程是 DevOps 的自然演进，它解决了 DevOps 的核心挑战，并使组织能够更有效地扩展。随着重点转向创建自助服务平台和赋能开发人员，DevOps 的传统角色正在被重新定义。 平台工程应运而生。 什么是平台工程？ 平台工程是 DevOps 的一种现代方法，更确切地说，是 DevOps 的一个逻辑扩展，旨在与现有的 DevOps 原则一起工作，同时减轻相关的认知负担。 平台工程师通过构建内部开发人员平台（IDP）来简化标准 DevOps 活动，该平台提供单一的应用程序开发和部署工具包。 作为 DevOps 的战略扩展，平台工程解决了传统手动方法的缺点、不足和限制。 平台工程将在软件开发和交付中发挥重要作用。 平台使 DevOps 能够大规模扩展 随着 DevOps 的兴起极大地改变了软件开发，使其变得更加敏捷和协作，但组织通常需要帮助才能独立处理复杂性。

加速企业敏捷的DevOps平台

针对技术、流程我们通过平台进行了最佳实践的固化，形成了支持DevOps的平台。 在平台建设时，一个非常重要的思路是建设“以应用为中心的DevOps平台”。 大家如果关注业界DevOps平台的话，会发现市面上的DevOps平台更多的是偏向“以资源为中心的”，提供更多是创建容器、VM的能力。 DevOps平台通常具备的几个核心特性： 1、完整的DevOps平台至少提供统一的工作台，支持部门的协同工作； 2、打通工具链，做到自动化和自助化； 3、实现研发过程的度量，建立组织基线数据； 4、无缝支持多种环境公有云 大家可能非常关心，如何在各自的企业中如何落地DevOps平台呢？ 从持续发布开始，后续可以建设量身定制的DevOps平台。

2025最佳DevOps平台选型参考

作为中国本土领先的一站式DevOps平台，Gitee凭借其独特的本土化优势、灵活的部署方案和持续迭代的产品能力，正在成为越来越多企业构建高效研发体系的首选工具。 据统计，目前Gitee开源托管项目已超过800万个，成为中国最大的开源代码托管平台之一。针对中大型企业的复杂需求，Gitee企业版提供了完整的DevOps解决方案。 全链路DevOps能力与生态整合作为一站式平台，Gitee的功能覆盖从需求管理到最终交付的完整软件开发生命周期。 随着中国数字经济迈向高质量发展阶段，Gitee这类本土化DevOps平台的价值将进一步凸显。其不仅解决了企业在工具链选择上的"卡脖子"风险，更通过深度适配本地开发环境和文化，助力企业释放研发效能潜力。 未来，随着人工智能技术在开发流程中的渗透，Gitee有望通过智能化代码辅助、自动化测试生成等创新功能，持续引领中国DevOps行业的进化方向。