10 | 配置管理：最容易被忽视的DevOps工程实践基础
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
配置管理是DevOps工程实践的基础，本文从宏观视角解释了配置管理的重要性和核心理念。其中，版本变更标准化、将一切纳入版本控制、全流程可追溯和单一可信数据源被强调为配置管理的四大理念。这些理念不仅是自动化的前提，也是软件开发过程中协同效率提升的源头。文章强调了配置管理对于软件开发过程的至关重要性，并提出了建立主线、统一管理需求等建议，以实现全流程可追溯。总的来说，本文深入浅出地解释了配置管理的重要性和实践方法，为读者提供了全局概念，帮助他们掌握配置管理的要点。
《DevOps 实战笔记》，新⼈⾸单¥59
全部留言(19)
- 最新
- 精选
holen老师讲的都是概念，能不能结合老师公司的实践讲一下贵公司是怎么做的吗？ 虽然 每个企业面临的实际问题都不相同，方案也不一样， 但是 我们可以从案例中 得到一些思路或者启发， 而不是这样听一些概念，然后还是不知道从何入手！作者回复: 嗯，可以简单给你介绍下我们的一些过程吧，其实最早也是没有专职的配置管理职能的，软件的发布和集成都是研发团队自行管理。推动这个事情的契机是公司决定加快版本发布节奏，从三周一个版本推进到两周一个版本，看起来缩短了一周时间，但就像之前演示的部署引力图一样，方方面面的影响都在阻碍这个目标。 所以，我们决定引入配置管理智能，初期就做两件事，一个是重新定义分支策略，从长分支改为了短分支加特性分支的模式，第二个是管理集成权限，从任何时间都有人能集成，到按照版本周期管控。在这个过程中，梳理了代码仓库的目录结构，存储方式，并基于流程建立了在线提测平台实现研发过程的线上化。 接下来配置管理结合平台和流程先前先后开始延展，向前管理需求代码关联，事中将构建测试等过程工具以及环境配置纳入统一管控，向后定义了版本发布和上线规则。在团队走上正轨有序开发之后，逐步加强平台和自动化能力的建设，比如代码提交失控，那么就做集成线上化，测试验收通过之后自动合并代码，比如环境差异大，就通过容器化和服务端配置管理工具，实现统一的初始化。构建速度慢，就通过网络改造和增量编译提升构建速度。从而最终使得版本发布这件事情变成一键式的操作。 我想说的是，实践有很多，但是哪些可以用于解决实际问题，还要把握原则，如果你不知道该从何入手，不妨看看现在的软件交付流程，是否是由配置管理来驱动的，是否还有一些数据是失控和混乱的状态，是否版本的信息还无法完整回溯。对于配置管理来说，标准化，自动化，服务化是一条通用的路径，以上供你参考。
2019-11-0617
Robert小七老师是否有落地的方案呢？这篇专栏都是讲的概念，在devops研发运营一体化中都有相应的介绍！但是对于如何落地，我觉得这个才是重点作者回复: 你好，每个企业面临的实际问题都不相同，很难给出一个通用的落地方案，但从配置管理的角度来说，最重要的就是识别和管理配置项，也就是将一切纳入版本控制，并且是要遵循规则纳入管理的，我的建议是你把软件交付过程中涉及的这些配置项通盘梳理一下，看看是否都满足这个要求。纳入管理之后，就要建立流程方面的上下游关联和联动，比如开始可以从需求和代码的关联做起，再逐步扩展到其他配置项内容。当然，也欢迎你提出你的实际问题来，这样可能会更加聚焦一些，谢谢。
2019-11-0235
陈斯佳老师，问一个和文章无关的问题。就是我自己打算每年考一个证，通过考证来督促自己学习。您觉得想要作为一个合格devopa工程师，哪一本证最值得考呢？AWS的SysOps Admin Associate含金量如何呢？谢谢作者回复: 你好，坦率的说，我个人对于考证不是特别热衷，当然不是质疑认证本身的价值哈，对于咱们这行来说，单纯的输入式学习，效果不见得好，我觉得还得要看跟你当前工作或者未来发展方向相关的认证，就像你说的以考试来督促学习，但是也更建议通过输出来督促学习。就好比我在写这个专栏的过程中，有很多东西也不完全清楚，没有深究，但是为了体系化输出，就必须有针对性的补充相关的知识图谱哈。可以给自己定一个小目标，在团队内分享一个系列课程，说不定在交流中，会有新的收获哈。
2019-11-054
albertz提交记录那部分让我想到这一点：Code Review的起始点应该是commit message，从这里可以看出一个开发人员对自己的工作成果是否有信心和责任心，以及表达能力。也是一种综合素质的体现。我们就是做软件配置管理的，没天看到的无数提交记录，真的是千奇百怪，良莠不齐，有的干脆是不知所云，或者就是写一串无意义的字符。现在我们通过工具强制填写JIRA号和任务信息，算是略有改善。所以我想说，对自己的代码负责，想让人刮目相看，从写好commit message做起。作者回复: 没错，每个人写下的每一行代码和提交注释都是自身credit的体现，良好的习惯也要通过流程来培养，为了加速这个习惯的养成，适当的规则建立也是很有必要的。
2019-11-024
天天向上为啥叫配置管理 这个名字很容易让人想偏 版本管理 变更管理 追溯管理 感觉都比配置管理好理解作者回复: 的确像你说的，给一个人解释清楚配置管理是什么并不是一件简单的事情，就跟用一句话说明白DevOps是干啥的一样。不过，我倒觉得版本，变更，追溯都是配置管理的领域范畴，也是配置管理的目标，如果说做到全流程可追溯，大家可能理解起来会更直观一些，anyway，我觉得核心还是要把这些思想落在日常流程定义，工具平台开发里面才能发挥真正作用哈。
2019-11-071
Goal和前面同学一样的问题，老师讲的都是普适性的道理，但是否在实际操作中，接触devops比较少的话，听的感觉很爽，实际操作仍然感到不知从何入手呢？ 极客时间，有不少专栏都是讲类似"devops"思维的课程的，内容都很精辟。希望可以搞一个入门级的"devops实践"，不需要结合学员们各种各样的场景。只是假设一个场景，走一遍流程，这样是否可以给读者一个更全面的认识呢作者回复: 你好，感谢你的留言，的确以DevOps的广度而言，其实每一讲的内容都可以独立展开为一篇专栏。为了帮助大家更好理解和上手，我也在准备一个完整的端到端流水线的实例，通过一次代码提交到上线的完整过程，来理解贯穿前面所讲过的这些实践理念，大约会在专栏靠后的部分上线哈。
2019-11-051- 工画师这次课程真的可以收藏了。我们公司现在就在做DevOps，通过访谈梳理出来的痛点，核心问题都集中在这次课程中提到的问题了，这四点是一切的源头。此外，我们还有一个问题是配置管理是从局部向上设计的，有些过度，把自己提升到管理和审批的角色，制定了复杂的流程、规范和交付物……所以我觉得这次课程再谈一下配置管理“度”和边界问题就完美了。配置管理会涉及变更管理和缺陷管理等，但相关联是否到了项目管理的控制程度，这个问题不能模糊，否则会阻碍自动化流程的效率。
作者回复: 你好，我的理解配置管理和项目管理是不同的思路，配置管理虽然也会涉及到流程的梳理和定义，但这些都是为了更好的配合配置管理的理念而存在的手段，而项目管理是为了在资源、时间、范围的约束下达成目标，一个偏落地执行，一个偏优化改进，虽然实际工作中，这两拨人经常会打交道，但我看到的是冲突大于合作。。。
2019-11-041 
阿硕石老师，您好，请教下什么样的角色适合担当起配置管理呢？考核是统一管理还是各自独立呢？作者回复: 你好，在以往公司内部都有专职的配置管理员，不过近些年来这个岗位本身有些模糊，在互联网公司随着流程和工具平台的成熟度提升，慢慢都会转到工程效率，版本团队来兼任，这个还是要看你们公司的业务形态，一般组织级会统一建设配置管理能力和规则。
2019-11-031
风雨无阻有个实践问题一直困扰，请问jenkinsfile，dockerfile这些也跟源码放在一个仓库吗？作者回复: 不一定，但是必须要纳入版本控制哈，比如我们这边对于流水线的配置是在一个独立的仓库中保存的，因为用户平常不需要关心这里的实现细节，更多的是在平台上操作，但是版本的概念还是无处不在的。
2020-02-20
zy86其实软件的版本管理好做。但是现在我感觉我们公司最难做的是数据库表结构变化的管理。我们是java开发。当然我们可以使用flyway这样的组件来做。但是又对这种自动的数据库脚本执行插件感到害怕。怕上线以后如果谁写了删库代码。那就尴尬了作者回复: 嗯，工具还好，类似Inception之类的工具都比较成熟，关于数据库变更脚本，还是要有Review过程以及自动风险分析的，如果有危险操作不会通过自动化检查。
2019-12-03
