CICD调研过程中的一些重要信息的记录

末蓝、 2023-06-19 09:50 26阅读 0赞

这段时间，一直在进行CICD过程的研究设计和实施。现在写一些关键的、与团队成员不断反复讨论的点。

# 我们开发过程，保护主分支有一个分支叫B标分支。 #

1. 为什么要有B标分支。以前在DT的仪表团队，我任了一年多的版本经理。仔细学习和理解了升级过程的一些细节问题。为了防止出现以往我们大团出现无数个分支的困境，最后我精简为两个分支，一个是主分支，一个是B标分支。B标分支是我学习公司其它项目的做法。

当时，虽然任了一两年的升级经理，但没有真正整理和理解一个B标分支，这次开发CICD过程，重新理解了一遍。

（1）保护主分支。主分支有时也叫商用分支，B标分支，有时也叫团队开发分支，有的公司叫pre\_release分支。但实际上，我还是觉得B标最精准。它不是开发分支，也不是pre\_release，实际是一个pre\_test分支，甚至叫pre\_test也不精确。它的存在，主要是为升级服务的。

从事软件开发的这20年来，我感觉软件业需要学习一些传统行业积累下来的经验教训。

许多公司，有研发部，有测试部，但实际上，最最难的正在在这两个部门之间的那些活在夹缝中的人。而且，他们非常 之重要。

比如，我时任版本经理时，可以说时常非常紧张。

例如，每周都要发布一个版本到测试，我首先将这两周分为激进周和保守周。激进周尽量提目前技术经理要求满足的特性(C&R)，但保守周则不允许提新特性，只能提bug的resolve.

每周五，我会发出预升级通告，给所有的子项目经理，给出下周是激进周，还是保守周的说明，然后给出升级请回接收的最后时限，一般是下周一的11点左右。还有其它所有质量部给出的所有的升级环节的时间点（质量部定流程，我这里定时间）。

要求，周一前，信息中心的生产数据管理部门，会给出PDM product标和软件B标和正式标。

然后，周一下周一点到2点间，升级会，最后确定升级清单，然后交给测试部测试经理执行。这个过程，是我重要的关注点，我会一项项审核所有的升级请求。因为一般在周一的上午9点左右，我们会与技术经理和商务人员，有时项目经理也会参与，讨论目前用户的意见和关心的新需求，我会详细记下来。然后会发一封给所有子项目经理，本周升级的特性目标，作为正式升级通告。所以，下午这场会，我会详细审核每个升级项。与大方向不符合的，将会被无情地打回去。但那些版本计划中，本该升的，相关的子项目经理一定要有明确解释，如果认为理由不充分，有问题，也要升，升了以后提bug，但是也要升级！因为这是研发升级，每三个月才有一个商用版本release. 升级经理，永远要注意向计划负责，向需求负责，不是向稳定无限的地负责，稳定不是升级经理关注的，而且保守升级这一周，已给了研发方喘息之机。

最晚一般在周三前，所有开发者将私人分支、开发分支信息，提交到B标分支，周四下午5点前，由信息中心数据部门锁标，启动自动编译和打包过程，周五早晨测试部从数据中心（持续集成部门）得到最终大包。开始准入测试。周五下班前，给出准出结果，完成升级过程，进入测试部的范畴。与升级经理脱离。

可见过程的艰辛。以至于后来没人愿意干这事了。技术经理后来成了官僚，升级经理不存在了。这是后话。也是令人痛心。

我以自己任项目经理时，我是请大家转班，一人轮值一个月来完成升级过程，因为实在是太复杂和累人了。但公司层面，一路糊涂到底。最后连质量部也没了。流程都没人定，没有质量部来执法，大家炒成一锅粥。不过现在都与我无关了。

今天我想到哪说到哪。再回头说B标，为什么要有B标分支。和现在的CICD有什么关系。

===============================================

从上面这段文字来看，B标有如下功能和特点：

1. 永不后退。这是一个很重要的特性。这也是我任升级经理时的重要要求。子项目团队的开发分支，个人分支， 甚至是主分支，都有可能回退，但B标绝不能回退。

B标为什么不能回退？难不成升级过程中，不能回退吗？的确是这样。一个大的系统，强调的是完整 ，有子系统回退，其它人会被波及，结果是每次都升不了级。有人会说，难道我们要发布有缺陷的产品吗？的确这就是生物的生存法则。我们只是选了缺陷相对少的那个而己。这是设计问题，如何让产品容错，防止错误累积，如何在线升级，等等，这是另外一个学科，对于升级来说，绝不能后通。错误要在错误的基础上修正，每次升级，最多一般我只允许一次被生产部门打回来。再出问题，我会禁止相对的组参与升级，否则时间点一定会被推迟。

2. 允许脏信息。B标就是一个干脏活累活的分支。所有的代码归并的问题，将集中在 B标上被发现。冲突由后发起的人解决，直到代码可以归并。一次升级，可以有N个merge 节点。这里不需要完美。我们要力求完美 的是主分支（商用分支）。B标可以挪，但只能向前挪。后退也要用前进来实现。

3. 这个地方很难理解，很多人会以为B标分支会带来各团队代码不同步的问题，这里是不存在的，工具将会保证。也是B标分支的关键作用。假如两人修改了同一个接品文件，后merge的一方，将在归并时被deny，不得不回去改。

4. B标分支只有一个，这个是前面的描述包含的。我发现，许多人，有一种拉分支的天然欲望，在升级过程中，作为升级经理，你必须要非常非常的tough，绝不能在这方面通融。根据质量部的流程，B标是由信息中心给出的，不是由研发部定的，理论上，也不允许研发方在这方面动手脚本。

5. B标的锁定者，是信息中心根据版本经理的计划执行的。研发人员是无权干涉的。所以，技术经理可以是个官僚，但升级经理，必要是非常 tough，到点就锁，绝不拖延。锁了就不要开。

6. 锁标后，由信息中心的数据生产部门，自动进行编译和打包。并且与研发经理自己提交的B标研发方编译结果进行二进制比对。这项是极为重要的。我不象其它人夸夸其谈，你要是开发公司，就会明白，在没有法制的情况下，公司内部大家是如何进行扯皮的。比如，研发方可以说我代码是好的，是你信息中心给我们编坏了。

所以要二进制比对。当然，有的文件，二进制不能完全一致，这理论是不合法的,gcc可没这毛病,毛病出在人身上。但有时也没有办法。

许多公司不注重打包这件事，这件事实际更重要。你把宝马装上奔驰的轮子，两个研发团队都可以说不是自己的事。许多公司的客服，总是自己拆拆装装，然后提交给客户，最后研发一推二一五，这其实只要与OM部门协调好，不合规定的包，就不要加载即可，但前提是定是大包，一般一块板卡，最多只能有一个包。而且最络要打到更大的包里。

有人问，为啥多道手序，要信息中心这些文职人员给编出来呢？没错，美国为什么是文官体系？这些道理，我们就不说深了。最重要一点是，研发和测试可能合起伙来忽悠公司，例如每次升级的东西是根本不能跑的。为什么要这样呢？自己思考吧。

7. 然后是准入测试。这个过程之后，升级经理就解放了。

可以看到，升级的过程的艰辛和危险。实际上也很漫长。但许多公司完全忽略这些人的存在，更是不明白，如何由质量部来司法。升级经理在这里是执法者，司法是质量部，立法是所有人参与的，主要是技术委员会。

先说这些吧。有空我再写CICD的事。CICD是研发者自己的事，理论上也用不着B标，但对于平台开发者来说，还是可以将二者结合起来的。

# 标准的CICD的含义和被触发执行的时间点 #

gitlab-ci 标准的CICD见gitlab网站的Introduction:

[https://docs.gitlab.com/ee/ci/introduction/][https_docs.gitlab.com_ee_ci_introduction]

可以有如下总结：

（1）与传统的持续集成不同，CICD的服务对象是developer，更直白说是请开发者自己挖坑自己跳。这是西方管理学将第三方管理进一步推进到由平台监督的自我管理的方向。

（2）CICD的发生时间点，在两种地方：开发者向自己的远端开发者分支push或merge时。这里push表示开发者没有进一步展开第四个所谓的针对某个特定的feature（或bug,C&R）分支，直接在自己的开发者分支上，merge则是从开发者自己的feature分支，merge到远端开发者分支上。相关的图大家自己找吧，二者没有本质分别，不同是3个分支，还是4个分支数。

（但注意，这只是管方说法，这两种方式，最后我们都抛弃了，我们最后用的类似merge request时，进行CICD）

这个触发过程，是理解和实施时的核心要点。一般来说，作为GK的你，不要给程序员过多的选择。如果项目不是那种特别活跃的，三个分支的方案已足够。

触发，进一步从主动宾角度来分解，主语是开发者自己，这点很重要，这是根本需求，所以设计和实施时要注意这一个基本点;物因和本因，要搞清楚。物因就是触发前是什么样，本因是触发后是什么样。但一定要理解，从物因到本因的过程，才是CICD。而且还不是全部。

具体来说，假如开发者从自己的本地开发者分支，push到自己的远端开发者分支，这里，平台自动触发CICD过程。这个过程相对简单容易理解。平台是坐庄者，它知道发生了什么，要做什么，这个自不必说，开发者向远端push到自己的远端开发者分支上，这也没什么可说。

但这样，并没有什么输出。这里说的输出，是可以做为平台的输入的输出。因为CICD表面服务对象好象是开发者，真正服务的对象是平台。它在CICD成功后，将要自动发起merge过程。

但明眼人一看，问题就来了。

merge就要提merge request，因为developer没有权利向officel分支push或merge。如前所述，平台在收到CICD过程后，就要自动发起merge request，这个不是说不能做到，但几乎一定需要大量的二次开发，因为提交的信息往往很多。然后TA进行codereview，然后GK，然后check in.

这样对于我们这种程序员被抓了壮丁来实施CICD的兼职者来说，显然是无法接受的。

这样也就是说，管方的流程，在这一点上，我们不应当采用。成本过高。

所以，我们回到B标分支的原始思路。

# B标分支（以后称为CICD分支）方案 #

事实如上，gitlab公司的想法是，你们这些人，只需要出钱就好了，其它的我们包圆。所以google一下，许多人劝大家用自己的方案，不要用gitlab的方案，要free你从gitlab的方案中。这很容易理解，我也是给老板打开，我们老板也是为还没付钱的甲方打工，谁能一开始就拿钱出来呢？

所以，官方的方案，我们不能用。因为从mergerequest开始，都要钱了。。。怎么说到钱了呢。。。

所以，我们回到一个新的旧方案，就一个永不回退的脏分支，来保护offical分支。

我们叫它CICD分支。如果前面你理解了B分支，它就是B分支。

我们采用了B分支，有一个最最重要的好处：开发者向B分支push（或merge）时，我们发起CICD，那么merge过程是先发生，然后CICD的。

看起来是不是流程倒了？不是应该先CICD再merge到offical分支上吗？

这其实是合理的。

**因为gitlab-ci 的mergerequest 过程，实际上，也是偷偷合到一个中间分支，然后才开始编译的。**

这是本文很要的一个理解。

稍思考下就明白了：CICD要检查一种合理的代码，这个代码应当是主分支的代码，但要经过CICD确认才能合到主分支。是不是死循环了？所以实际上merge的过程（CICD有两个触发点，一个是研发人员自己查自己，我们不再提这种对于我们系统无意义的方式，以后只提与offical分支相关的CICD），是一定要有的，而且也的确是合到某个master分支的临出拉出的隐藏分支去之后发起的CICD。也就是实际就是merge了两次，一次为CICD，一次在CICD成功之后（失败当然不能merge了），这也是B标分支的另一个含义。

再回头看我们的改进方案，这样就合理了。

我们把潜藏的B分支，拿了出来，不再是不可见的了。

有人又会说，出了B分支，是不是应当每次编译前，从offical分支fetch到B分支呢？

这里需要详细分析情况。

理论上不需要。

为什么呢？因为一旦B分支存在，而所有的升级流程都是经过B分支编译成功，且自动测试通过（定点回归和准入），那么也就是说offical分支的所有内容，都是从B分支合过来的，也就是说，B分支才是永远最新的分支，所以，信息流是单向的。

但为什么说理论上呢？

如果你实际上，有两个B分支，那么情况就不同了。

也许读到这，可能会疑惑，为什么可能会存在两个B分支呢？这完全与系统思想不符合？因为系统第一定义是完整、完备。两个分支，这一定是出了问题吧？

这也不对。

我们的世界是10维（有人说是11维），这里面，一个含义是各维度是相互独立的。

似如，在编译linux时，linux的代码，必须只能在一个维度，这容易理解，因为我们发布给用户的linux必须是完整的事务（linux是宏内核的，理论上不允许一部分是二进制文件，另一部分是代码的方式编译，如果微内核要复杂得多）;但是gcc则是另一个维度。它理论上有自己的升级链;再例如yocto则是另一个维度，所以，对于多维度复杂项目 ，B标分支有多个，每个B标分支，代理一个**行政上完全独立**的开发团队。

这们这里，比这还要复杂。

因为我们要绕过gitlab-cicd，所以，我们需要一种方案，在我们原有的库里，如bitbucket里的代码，能在gitlab-ci 中CICD。但是用过gitlab 的人知道，gitlab-ci 过程依赖（确切说是binding）在.gitlab-ci.yml文件之上，但用户可不希望他的代码里有这个文件。

所以，必须有两个B标。

但是，实际上我们执行时，因为gitlab这边，不需要offical分支，所以gitlab这边，只有一个用于cicd的B标分支，.gitlab-ci.yml自己在一个独立分支上，每次CICD前，我们需要将之fetch到B标（CICD）分支上。

最后再push.

# **蛇足** #

**B标的缺点：**

B标分支的好处明显，它像一个卫士保护着官方分支。脏活累活它干，它永不后退。

但是如果开发者人数多，对同一个文件的修改，可能发生冲突。这是git本身的缺陷所致。倒如，前段时间我在开发中，数次被打回来，就是因为我改的文件，别人也改了，例如yocto的白名单的文件，许多同事都要改。一般GK会将这些相关的修改都给一个人，但当时任务多，两人同时处理，就一再被打回来。当然，有一些也是我忘记fetch所致。

还有更严重的是，两个代码虽然可以归并，但编来的二进制文件因为相互影响而不能通过测试。

这些都里需要考虑的。但不能因为这些小毛病，改变基本法则。

最重要的是：B标分支不能回退，开发人员，也要清楚这一点，并且服从。

不能回退的原因是，CICD过程需要时间，在这个过程中，其它开发都可以也会将自己的修改提交CICD分支，如果前面的人失败，revert，后来的人，即使没有错，也会跟着回退。读过我之前提到的系统思想，大家会明白，自然界没有这样的系统。系统是残酷的，没有后悔药，后退也是前进中的后退。速度是最重要的。系统的服务对象不是开发者，是外界，是用户，是竞争对手，是尽可能占据生物链的外部资源。

所以，这里虽然是多说的，但还是很必要。许多人不了解B标的概念，正是因为事事想着要后退。

这是我任版本经理（兼升级经理）时，最常向各团队解释的话。另一个我天天强调的就是绝不允许拉第二个B分支——那是我的权力。

<完>

[https_docs.gitlab.com_ee_ci_introduction]: https://docs.gitlab.com/ee/ci/introduction/