问题就是期望与现实之间的距离
我们团队正在推行 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，请做好准备。
我们没有做好团队认知上和编码习惯方面的准备工作，导致推行起来很吃力。
