Everything as Code 并没有你想象中的那么美好

问题就是期望与现实之间的距离

我们团队正在推行 Everything as Code（X as Code），也就是尽量将软件工程中的逻辑放到代码中。比如基础设施、业务代码构建逻辑即CI pipeline、告警规则、业务环境配置、架构图等。没有看错，架构图我们都会被写成代码。

经过半年多实践，X as Code给我们带来了以下好处：

能做到自动化最大化；
可进行code review；
在发布前，就可以进行逻辑验证，比如安全校验；
配置之间可以实现相互引用，极大地扩展了配置管理的想象力；
轻松实现模块化；

当我们实现了X as Code，它是美好的。但是实现过程中，是有不小代价的。

以下是我们在实践X as Code过程中，遇到的问题。

问题1：代码仓库采用单仓带来的问题

软件工程的逻辑代码，包括了整个公司的不同平台，不同系统，不同环境，不同元数据等。如何管理这些代码呢？

我们选择了单仓（monorepo）的方式，也就是将所有的代码放在一个仓库中。

那么，该如何组织单仓库下的目录结构？这是我们需要思考的第一个问题（这个主题需要单独写一篇文章）。

除此之外，单仓会强迫开发人员认真地写git commit message，合理的安排commit记录。因为单仓中不只有一个平台的代码了。你需要认真commit，以方便后面搜索commit记录。

问题2：提MR时，该找谁review？

在使用GitLab进行代码托管的情况下，commiter提MR后，该找谁进行review呢？这需要我们设计一个机制。

理想状态下，在commiter提MR后，DevOps平台应该能根据MR的内容自动化找到相应的reviewer。这依赖于CODEROWNERS机制。可参考GitLab的 Code Owners 。

如果没有这样的DevOps平台，就需要commiter自行根据CODEROWNERS指定reviewer。

问题3：构建工具采用Bazel带来的问题

采用单仓后，构建工具就需要换成能很好支持单仓的构建工具。我们选择了Bazel。遇到的问题还不少：

Bazel对Windows支持不够友好，而我们绝大数人都是Windows系统。所以，这些人无法在本地构建代码。这时云端IDE的好处就体现出来了；
Bazel普及率太低了。需要你花时间对团队进行培训；
Bazel rule（理解为一种构建插件）还不够丰富，遇到找不到的rule，就需要自己实现了。比如对Kong的配置的校验，就需要自己实现；

问题4：采用主干开发带来的问题

所有的代码都放在一个仓库中时，分支管理不好就是灾难。越多人同时操作该仓库，问题越多。为此，我们采用基于主干开发的方式。

而这种方式，在行业里并不流行（在国内是这样的，不知道国外如何）。所以，你得培训。

说回来，基于主干开发的方式学习起来比Gitflow容易多了。

问题5：依赖关系管理要求更严格带来的问题

依赖管理更严格指的是：

每一项依赖都必须指定明确的固定的版本号，不应该像npm那样自动对版本号进行升级；
强制单一版本，即一个依赖项在整个工程中，它应该只有一个版本。不应该像Maven工程中有N个Fastjson版本；
需要控制依赖的可见性。在单仓中，测试环境的配置不应该引用生产环境的配置。这需要构建工具的支持。

依赖管理更严格本身是合理的。我们本应该这样。

问题是使用npm的程序员很难理解>=version有害的，绝大数程序员不知道“依赖的可见性控制”是什么鬼。

问题6：配置的定义与配置的使用分离带来的问题

在X as Code之后，配置之间可以很容易地相互引用。我们在设计配置时，会将配置的定义与使用分离。比如配置在代码仓库中定义成JSON的格式（配置定义的地方），但是，最终使用时，我们可以将其转成YAML的格式，然后将该YAML内容更新到ETCD等配置中心（应用程序真正使用配置的地方）中。

配置的定义与配置的使用分离本身是合理的。我们本应该这样。

问题是，习惯性使用Springboot的Profile管理配置的程序员，无法理解为什么要在另一个地方定义配置。

是因为他们在开发过程没有考虑到软件的规模化问题。

问题7：采用单一制品版本号带来的问题

在采用单仓管理X as Code时，整个仓库会打包成多个制品，而不是一个制品，比如测试环境的配置一个制品、生产环境的一个制品。而这些制品，我们都会赋予一个相同制品版本号。

采用单一制品版本号本身是合理的，我们本应该这样。

问题大家无法理解这种方式，为什么A系统的制品和B系统的是同一个版本号？

单一制品版本号降低了我们对制品管理及版本号管理的成本。

问题8：如何保证代码中的敏感信息的安全？

这个问题，我们目前还没有非常好的解决。

小结

全文写下来，其实就是我们在实践X as Code及单仓过程中遇到的问题。很多问题是团队认知上和编码习惯上的问题。毕竟，单仓的实践案例在整个行业中，还很少，大家很难一下改掉过去的习惯。

如果你要实践X as Code，请做好准备。

我们没有做好团队认知上和编码习惯方面的准备工作，导致推行起来很吃力。

最后，如果您希望加入“持续交付实践指南”的微信群进入交流，可以添加 zhaizhijun0 微信，他会拉你进群。

往期好文推荐：

文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/70948.html