共计 3764 个字符，预计需要花费 10 分钟才能阅读完成。
专栏策动|雅纯
意愿编辑|张晟
软件交付是以代码为核心的交付过程，其中代码的作用有几点：第一，最终的制品要交付成什么样，须要通过代码形容分明；第二，代码定义了零碎和软件是怎么工作的；第三，代码定义了零碎的运行环境是怎么的。所有这些都是围绕代码。
那咱们的代码治理和软件配置管理应该怎么做呢？
咱们先看一个例子。下图是某个团队的代码组织构造，这样的代码组织构造会有什么问题呢？
问题 1：代码组的命名形式凌乱
咱们发现在最上层的目录中叫 risk-managenment，这是一个零碎，这个零碎是风险管理。然而子目录写的是叫“qinglong”，那“qinglong”是利用还是团队，我不晓得。而后上面还有一个玄武，上面还有一个 aTeam，中英文混淆，这样的命名形式是很凌乱的。
问题 2：用代码块存储内部二进制文件
在 android-sdks 外面会寄存很多 sdk 文件，这些文件是很大的，这个代码库存储很多内部二进制文件，咱们晓得在代码库间接存这样的大文件，对整个代码库的资源耗费是十分大的。
问题 3：同一归属的代码保留在不同的代码组
在 aTeam 目录下有一个 data-model，然而其余相干的文件都在玄武下，就是 data-console、data-task、data-ui，咱们不晓得它具体是什么，然而咱们晓得这几个大概率是同一个利用或者是同一个产品，所以它在两个不同的层级也是不合理的。
问题 4：公共库保留在子代码组里
再下一个是 common-lib，通过名字来了解就是公共库，然而这个公共感觉只给玄武这个子代码组应用。
问题 5：利用的文档（或测试）与利用离开寄存
最初还有一个 docs 目录下有 risk-docs 和 data-docs，一个是针对危险管制的零碎，一个是针对数据地零碎。那这个外面文档也是一个代码库，文档代码库和测试代码库，它和利用是离开寄存的，这也是不合理的。
好的代码库组织模式是怎么的？
问题：假如所有的代码都保留在一个代码库，且所有人均可拜访，代码库应该怎么组织？
咱们认为代码库是能够分组的，代码组（+ 子代码组）+ 代码库 = 大库。
基于这个逻辑，咱们再看看方才那个例子里正当的代码组的构造应该是怎么的。
如上图所示，整个代码库是一个零碎，这个零碎有两个利用，一个是 risk，一个是 data。每个利用上面是有很多的服务和文档。它们有一个公共的 Model，叫 common-lib，这是被所有的利用所依赖的。所以咱们把属于同一个利用的 Git 仓库放在一起，让 common 放到该有的中央去。不是依照团队，而是依照利用组划分，这样划分，构造就更加清晰了。这里咱们略微总结了一些实际的倡议。
- 代码库的内容：
- 软件的源代码（ProductionCode）；
- 将文档（和测试）的 git 库放到其相干利用组下；
- 不要将制品（如零碎二进制包）保留在代码库中，如果的确须要，以 LFS 或相似形式寄存；
（小编举荐：云效代码治理 Codeup 为企业提供收费不限容量的 LFS 存储）
- 代码库的组织构造：
- 依照零碎、利用和模块的档次来组织代码库；
- 同一个零碎 / 利用层级的所有内容位于同一个代码组下；
- 代码库的可见性：
- 通用代码库放在其通用级别都能够拜访的地位；
- 除外围算法等多数代码库外，倡议对代码库的拜访在同一零碎 / 利用下对所有相干人员公开；
代码组织完了当前，开发者就能够围绕代码库来进行合作。整个代码库的合作过程就是：所有皆 Commit。无论是 rebase 还是 merge，都是 Commit。
那对于 Commit，咱们有什么要留神的呢？
什么是好的 Commit
咱们总结了 3 点倡议给到大家：
1.Samll
Git 库要尽可能地小。尤其是目前的基础设施现状下，尽管你的一个仓库里能够放多个利用，然而保护起来的老本会很大的。还有治理方面，不要在 Git 上存储构建产物和其余二进制文件。把构建产物放在构建仓库上，尽管给他人不便了，却很难晓得这个构建产物是当初的代码产生进去的还是之前产生进去的，这是很难去追溯的。对于二进制文件，如果确有必要（例如游戏的素材），倡议应用 LFS 的形式来保留。
2.Linear
防止无意义的 merge，尽量用 rebase 操作。其次是防止有效 commit，有很多代码库 commit 记录很长，然而外面 80% 都是有效的，例如都是 fix1、fix2 这样的 commit，都却不晓得它具体做了些什么，这种显然是不合理的，对于这种简短的 commit 列表，有时候能够在 merge 的时候 squash 一下。
3.Atomic
原子性，指操作的原子化。原子性有什么益处呢？一个 Commit 解决一个特定的问题，比如说我就是修复一个 UTcase，或者是加一个 UT 或者是加一个性能，或者是加一个 API，这些明确的问题对应到一个 commit，很容易追溯。解决的问题不能很大，不能写了 2000 行代码解决了一个 feature，一起提交，这是十分危险的。作为开发者，做的好的应该是疾速有阶段性的成绩，并且继续地有反馈，继续地贴近指标。反之，开发者的体验不好，相干协作者的体验也不好，因为他人不晓得你做了多少了，很有可能跟你产生 mergeconflict。
上面列举一些 Commit 的反模式：
1. 有效的 commit
如 Mergebranch’develop’of https://codeup.aliyun.com/abc… 第一个问题，在简直所有公司外面都是轻易拉开一个代码，本地和近程都有这种状况，原本一个 rebase 搞定的事件，这样做会导致很多有效的 commit，甚至对 commit 追溯能力会产生很大地影响。
2. 巨型 commit
一个 commit 外面蕴含了大量的代码变动，且属于多个实现目标，就像 codereview，有些人提的 mergerequest，一下子过去 3000 多行代码，作为 reviewer，你齐全不晓得他做了什么，这是十分危险的。
3. 半成品的 commit
如蕴含有根本语法问题或实现谬误的代码的 commit 半成品的 commit。例如，到饭点了，不论了，先提交一把。这样的代码连编译都过不了，这个显然是不好的，没有任何意义。
4. 分支间的相互 merge
最初一个是分支间的相互 merge。从 develop 合到 master，又从 master 合到 develop，相互合来合去，一旦这种合并多了当前，commit 就会很难追溯，因为不晓得源头在哪。咱们倡议代码库应该有一个惟一的骨干，单向往骨干 merge，尽量避免反向 merge 的状况。
（小编举荐：云效代码治理 Codeup 的骨干开发模式，就提倡轻量的 commit 评审 和骨干研发，帮忙企业防止分支间的简单合并～）
软件配置管理
问题：软件配置常常被批改，被公布，它属于代码吗？
软件配置其实是另外一种模式的代码 。有可能大家在理论工作中配置不是存在 Git 仓库外面的，可能是在一个配置核心或者其余相似零碎外面，但无论在哪里，实质上，咱们能够把配置等同于某种类型的代码。
下图是大家常见的动态配置和动静配置，或者说启动相干的配置和运行相干的配置。
启动相干配置
- 启动相干配置是构建到镜像中或者作为启动参数传进去的。
- 启动之后不再批改了，不须要去动静监听它的变动。
- 对这类配置的批改，个别须要从新创立或者重启容器。
以此类推，哪些配置是启动相干的呢？比方 DB 连贯串、容器 CPU 规格、启动模式等（比方有的压测利用启动的时候辨别 master 模式和 worker 模式）。其它像 DNS 服务地址等，诸如此类的咱们都认为是启动相干的配置。
运行相干配置
- 通常是通过监听某个服务或文件来获取和更新的。比如说我要看一下我的白名单是什么，我去读一下白名单。
- 配置的更新是不须要批改容器和 Pod。
- 运行中的容器须要继续监听配置的变动，当有变动后主动失效、无需重启。
咱们举一下场景实例阐明一下：
- 大促期间调整日志级别，只记录 ERROR 级别的日志。
- 服务的黑白名单，为了限度某些 IP 的拜访，将其列入黑名单。
- 个性开关，通过开关关上或敞开某个 feature。
- 监控采样频率，由每分钟采样一次调整为每 5 分钟采样一次。
这些配置不须要也不应该每次批改都重新部署利用，他们都属于运行相干的配置。
咱们再来看一个 demo 示例外面哪些是启动相干的，哪些是运行相干的。咱们列举一下：
这是启动的时候就会须要的一个参数。
咱们将 secret 文件注入到 Deployment 中，利用主动从文件感知 secret 的值，无需重启，因而它是运行时的配置。越内层的配置，批改老本越高。
从另外的角度看一下配置，它有不同的档次，代码、镜像、Pod 和零碎。代码中的配置位于最内层，批改老本是最高的。因而，如果是编码级别的批改，要通过所有的阶段能力上线。如果运行阶段的话，我是不须要动后面的局部。
最初，留一个问题给大家：运行环境相干的配置是属于哪一种？欢送大家在评论区留言互动。
软件交付的终态是提供稳固可预期的零碎，要做到这点，须要确保：1. 运行环境的一致性；2. 软件制品的一致性。所以下篇，咱们将开始分享如何保障运行环境的一致性，以及环境中大家常见的痛点和应答计划。敬请期待！
浏览上篇：构建制品不统一，后续工作都是徒劳
点击下方链接收费应用云效代码治理 Codeup
https://www.aliyun.com/product/yunxiao/codeup?channel=yy_rccb_36