现代软件开发过程中要实现高效的团队协作，需要使用代码分支管理工具实现代码的共享、追溯、回滚及维护等功能。目前流行的代码管理工具，包括CVS，SVN，Git，Mercurial等。 相比CVS和SVN的集中管理，Git具有非常明显的优势，**例如：去中心化的代码管理方式减少了开发者对中心服务器的依赖，
DevOps、SRE和平台工程的概念在不同时期出现，并由不同的个人和组织开发。 - DevOps作为一
当你打开这篇文章的时候，也许你也在为DevOps的落地而苦恼，也许你的组织正在尝试DevOps转型，作为一线的实践者，说说我对这个“落地难”的看法，欢迎交流不同看法～ DevOps是实践摸索出来的，别人的终究是别人的 如下图所示，你可能在不同企业研发效能的分享都看到过，各种关于DevOps的书上有会
在实践中，很多团队对于DevOps 流水线没有很透彻的理解，要不就创建一大堆流水线，要不就一个流水线通吃。实际上，流水线的设计和写代码一样，需要基于“业务场景”进行一定的设计编排，特别是很多通过“开源工具”搭建的流水线，更需要如此（商业的一体化平台大部分已经把设计思想融入自己产品里了）。 - **流
> 最近在学习实践精益Kanban方法，结合自己团队实践Srum的经历，整理些资料二者的差异。相较于Scrum, 我更推崇精益Kaban。 Agile是一套理论和原则，就像天边的北极星。Devops是一种软件开发和运维团队间自动化和集成过程的方法。当实现Agile和Devops方法时，Kanban和
## 关键词 - DevSecOps — 在不影响敏捷性的前提下，将安全充分融入到SDLC的所有环节中 - SDLC—软件交付生命周期 - SCA—软件组成分析-用于识别和检测软件中使用的开源/第三方组件的已知安全漏洞 - SAST—静态分析安全测试 - DAS—动态分析安全测试 - IAST—交互
上篇文章，有同学私信想了解有哪些DevSecOps工具，这里整理出来，供大家参考（PS: 非专业安全人士，仅从DevOps建设角度，给出自己见解） 软件中的漏洞和弱点很常见：84%的软件漏洞都是利用应用层的漏洞。软件相关问题的普遍性是使用应用安全测试（AST）工具的主要动机。通过使用AST工具，企业
介绍 Sonar是一个代码质量管理的开源平台，基于Java开发的,用于管理源代码的质量，通过插件形式，可以支持包括java、C#、JavaScript等二十余种编程语言的代码质量管理与检测。 它具有免费的社区版本和其他付费版本。 SonarQube之采购选型参考 利用SonarQube的主要好处是：
最近在经历的一些事情，让我突发灵感，觉得要写点关于DevOps体系建设过程中的“流程规范”，记录下来。 如何解读"流程规范" 谈到DevOps落地，无一例外都会提“流程规范“，我想没有人会反对，甚至会”不放在眼里“，因为概念本身没有什么晦涩难懂。可是一到落地，好像就是另外一番场景，“一地鸡毛”，“形
1024，祝每个程序员小哥哥小姐姐节日快乐。 因为在研发效能部门，我支持过几次 1024 程序员节的活动，所以经常有朋友问我1024 程序员节怎么做，本篇就是简单介绍下我的思路，希望对你有用。 1024程序员节的由来 俄罗斯把每年第256(=2^8）天，即平年9月13日或闰年9月12日定为国际程序员
今天一个小伙伴问我，如何「快速提升」一个团队的软件开发成熟度？我犯难了。我个人理解一个团队的软件开发成熟度涉及的东西很多，但最简单最直接的方法就是发钱涨工资，可是估计很多公司不愿意，那就只有扣了。 快速提升的目标 短期制度解决 如果想短期快速提升，那就直接梳理好最关键点，制定规章制度，然后通过奖惩制
之前的一篇文章《从特拉斯辞职风波到研发效能中的荒唐事》中关于企业内源的内容在研发效能群内引起了大家的热烈讨论。有的小伙伴不同意，有的小伙伴非常不同意，我觉得这都是非常正常的反馈，话不说不透，理不辩不明，我还是特别希望能和大家一起把这个问题弄明白。这篇文章就是那篇文章的后续，本文主要讨论开源社区、开源
框架类是否适合企业内源？ 框架类都由公司早期来的一些大佬们负责（相当于技术委员会），更新频率非常低。给框架类提MR的人，多数本身就在技术委员会。 如果公司的人员众多，类似BAT级别，几万人使用的框架，大家一起添砖加瓦也许是合适的，尤其适合那些公司本来已经开源到开源社区的框架。但做之前肯定有大量的学习
有人说研发效能是老板工程。不是的，研发效能不是老板工程，它不直接服务于老板(虽然老板可能看一些报表)，反而是服务于广大产研运（产品+研发+质量+运维）的同学，所以有的公司也把研发效能叫做基础中台，平台工程，开发者服务团队，或者叫开发者服务平台。做好研发效能，做好开发者中台，就容易把公司的各种中后台能
现在很多公司都在做或者计划做研发效能，也知道研发效能工作很重要，能提高产研运同学的协同效率，提高员工的工作效率和质量，提高业务交付效率和交付质量，但是价值有多大？效率又有多高呢？因为不容易说清楚，所以经常碰到一些质疑和灵魂拷问。 如何衡量研发效能的效果？ 如何衡量研发效能的作用？ 如何说清楚研发效能
国内公司普遍不注重基础设施建设，这也是可以理解的。吃饭都吃不饱，就别提什么荤素搭配，两菜一汤了。但也不能全说是这样，还是有很多公司投入大量的人力物力去做好公司的基建，比如很多阿里和美团的小伙伴对公司的基建还是很认可的。 为什么工程师都很在意公司的基建 有人说再好的磨盘也只是提升了驴拉磨的效率，便宜了
之所以写这篇是因为有朋友私下让我完善下基建建设的标准和四个阶梯划分，然后让我一定要把腾讯和百度加到基建建设的排名中(看热闹不嫌事大）。 基建infra建设四个考察维度 1)工具链完整性：该有的工具是否都有了 2)功能完备性和易用性：工具该具备的功能是否都有了，是否容易使用 3)支持和服务：是否有人持
我特别反感那些不顾公司现状一上来就想要做研发效能度量的人，尤其是想把研发效能度量当成锤子四处去敲打螺丝钉的人。 没几个人的小公司上来就做研发效能度量，就如同普通人一上来直接问媒婆怎么能娶到迪丽热巴。解决办法无非把大象装冰箱里的那三步。套用一下，公司想要做好研发效能度量也有标准的三步：长时间对研发效能
之前写过一篇文章《devops｜中小公司不要做研发效能度量》，主要是从基础设施方向考虑，因为很多条件都不具备，贸然高投入去做研发效能度量可能达不到我们的预期效果，给出的建议是先做好当下打好基础。今天想到一个好例子，可以类比下。 两个人小家庭 1）人少 2）收入清晰 3）支出清晰，买了什么东西，花了多
AGI 的出现，给了我们一个新视角去审视我们做过的系统，尤其是研发效能平台。研发效能平台作为一个工具平台，本质就是提高公司整体产研的效率。AGI 的快速进步大家已经有目共睹，本文就是在项目协同，代码管理、测试、AIOps等方面来探讨 AGI 可以给研发效能平台带来的巨大变化效率提升。拥抱 AGI，吸
