【方法论】 代码管理的发展、工作流与新使命上篇原创

大家好，我是陈军统，来自陈讯云coding团队的解决方案架构师。今天我给大家分享的内容是代码管理的发展、工作流与新使命，以及基于coding产品的实践落地。

今天的课程呢，会分为五大部分，我们会从承载代码管理功能的软件发展与代表性的SBN介绍起，在讲解基于软件上提高写作效率的流程D工作有workfload。在今天的原生时代下，代码管理又被赋予了新的使命，Everything is code we get out，我们也会对这部分进行理念讲解以及使用coding产品做时间落地。最后一部分是对于企业在代码质量与安全方面的需求，讲解coding代码扫描解决方案。代码管理首先要有软件支持，相信大家对和SVN这两款工具都不陌生，他们都属于云代码版本控制系统的实现version control system，简称VCS。那么在讲解这两款工具之前，我们先来看看VCS的发展史。

世界上第一款真正意义上的代码版本控制系统诞生于1972年，名为source code control system，简称SCS，来自贝尔实验室用C语言开发的。这款工具呢已经具备了现代VC所提供的基本功能，例如创建、编辑和跟踪文件变更的功能。缺点在于它无法支持多人同时编辑同一个文件。到了1982年，有人开发出了一款新的系统，名为vision control system，简称RCS。这款系统仍然不支持多人同时编辑同一个文件。但是它创造性的采用了一种名为reverse DES的方式来记录文件的变更。在这种模式下，系统不再存储所有版本的文件，而是以某个最新的版本作为其他版本的机械，并以此来记录文件的变更。相比于之前的版本管理系统RCS会更快也更高效。

到了1986年，诞生了concuent version system，简称CBS。这款版本控制系统终于支持多人同时编辑同一个文件，并且他还跟现代版本管理系统一样，采用了客户端服务器的CS架构。时间来到2000年，一家美国软件公司创建了SBN项目，它设计的目标就是取代CBS。为了保证用户可以比较容易的从CBS切换到SBNSBN保留了CBS的大部分功能，并针对CBS的bug和一些缺失的功能进行了修复和补充。那当然，和CBS一样，SBN也是一款集中式的版本管理系统，随着时代发展，以地为代表的分布式逐渐成为主流。

回顾代码版本管理系统的发展史，我们可以将其演变为三个时代。第一代的主要特点，提供本地代码版本控制。我们前面提到的SCCS和RCS都属于第一代，这一代的代码版本控制系统主要实现了基本的代码版本管理功能，如图所示，左边是检出的文件，右边是版本数据库，单向进行，缺点是无法让多人同时对一个版本库进行修改。为了让人们可以在不同的系统上协同工作，第二代的代码版本控制系统应运而生了。第二代系统的主要特点是提供中心服务器端的代码版本控制，特点是可以让多人同时对同一个代码版本库进行同步和修改。我们前面提到的CVS和SVN都属于这一代，虽然相对于第一代有了较大的改进，第二代系统仍然存在不少的缺点。例如在无法连接服务器的情况下，无法查看日志以及提交或者提交代码版本，一旦服务或者网络出现问题，人们就无法正常工作。此外，由于只有一个中心端服务器，一旦发生灾难性问题，那么所有日志都会丢失，所以需要经常做备份，而备份往往需要较大的成本。

还有就是因为每次的日志查询、不同版本之间的代码比较和代码提交等操作都需要和服务器通信，如果软件代码量过于庞大，就容易使得服务器端不堪重负，从而导致各种操作都会出现缓慢卡顿的情况。第三代的代码版本控制系统结合了第一代和第二代的优点，并实现了分布式，代表就是D。第三代的特点在于客户端并不只提取最新版本的文件快照，而是把代码仓库完整的镜像下来，包括完整的历史记录。

这样一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库进行恢复，因为用户每一次的克隆操作实际上都是一次对代码仓库的完整备份。也正因为这样，在没有和服务器连接的情况下，开发人员仍然可以查看代码、提交代码、创建分支的。除此之外，第三代的原代码版本控制系统还支持branch，用户可以方便灵活的实现各种分支管理。了解完VCS的发展史后，我们现在就来讲讲地图这款工具背后的故事吧。先来看名言猜人名，这个人说，A computer is like air conditioning it becomes useless when you open window。听到这里，想必很多人都已经猜到这位大神是谁了。没错，他就是大名鼎鼎的Linux操作系统之父Linux to ROS，除了Linux操作系统之外，他还创造了。然而在后来的访弹路中，Linux却表示他一直很不喜欢做源代码管理，他觉得这是电脑领域中最无趣的事情了。那么，到底是什么让Linux改变了主意，并创造了当今最流行的GI呢？让我们一起来回顾一下这段有趣的历史吧。

时间回到1991年，Linux在这一年创造了开源的Linux操作系统。自那以后，来自世界各地的志愿者纷纷加入到Linux操作系统的开发中来，他们把源代码文件通过邮件的方式发送给Linux，然后由他通过手工操作的方式来合并代码。到了零二年，Linux已经发展了十多年，代码量越来越大，Linux忙的焦头烂耳，社区内的其他兄弟们也是怨声载道。显然之前的这种协作方式已经很难再维持下去了，他们急需一款高效的代码版本控制系统来帮助他们更好的进行协作。此时把目光投向了keepper，这是一款由bit公司开发的软件。虽然bit keepper是一款商业软件，但是开发者们可以在开源项目中免费使用它来进行代码的版本控制，前提是用户不能对其进行逆向工程，也不能使用它来进行其他任何bcs的开发。

就这样，在bit keepper这款工具的帮助下，Linus和社区内的其他兄弟们的协作效率得以大大提高，Linus内核的稳定性也随之直线上升。然而好景不长，在零五年的时候，有人通过逆向工程破解了per的通讯协议，并开发了一款自己的工具。这一举动彻底侵怒了move公司，他们决定撤销对开源项目，开放了bit keepper的免费使用权。顿时，Linux内核的开发工作面临着巨大的挑战，为此，Linu亲自出面花了几周的时间尝试去调解对面双方之间的矛盾，但是最终还是无股于世。无奈之下，Linus花了十天的时间自行创造了地，他给这款工具的描述是the stupid content tracker。

他不光嘲讽Windows操作系统，就连自己开发的工具也不放过，不得不说他个性十足。Get一经面试就获得了大量软件开发者的青睐，尤其是在2008年，Giha网站上线了，他为开源项目免费提供GI存储，无数开源项目开始迁移至guar，包括j query PHP Ruby等等，这也大大促进了GI的用户增长。根据stepo发布的开发者调查问卷显示，在一五年的时候，大约有69%的受访者表示自己在用GI了，这个比例在一八年增至88%，到了二一年增至93%。

值得一提的是，在诞生后的第11个年头，也就是一六年的时候，当初那个收费的软件keepper也正式宣布以阿八钱2.0许可证开源了。接下来我们来看一下gift和SBN这两款工具的对比吧。如图所示，SBN只有一个中央仓库，用来保存所有文件的修订版本，而协同工具的人们都通过客户端连到这个中央仓库，取出最新的文件或者提交更新。一旦网络中断或者搭载这个中央仓库的服务器出现故障，用户的各项工作都将无法继续进行。而GI属于分布式系统，每个开发者的本地就是一套完整版的版本库，记录着版本库的所有信息。因此，即便网络中断或者搭载GI远程仓库的服务器出现故障，用户也可以在本地仓库上继续工作。而且用户还可以根据自己的需求在本地创建任意分支，可以在本地查看日志的总体效率较高。

最后我们总结一下get和SBN各自的优缺点吧。SBN的优点之一就是它支持精细化的权限管理，我们可以按组、按人或者针对某个目录进行权限控制。同时SN对二进制文件的存储更友好，处理到文件时相对而言更加容易。除此之外，允许用户给同一个文件添加任意多的自定义属性。而且SN的操作方式更符合常规思维，用法相对简单，对于用户而言更加容易上手。当然，SBN也有它的缺点，比如用户必须连接上中心仓库才能正常工作，再比如，由于所有文件的修订版本都保存在中央仓库，搭载这个中央仓库的服务器压力较大，数据库所占空间容易暴增。也正是因为这样，SDN不适合用于大型开源软件的开发工作。

接下来我们来看一下get的优点。get的一大优点就是架构成熟，速度较快。测试表明，当我们克隆一个拥有将近1万个提交记录五个分支，每个分支大约有1500个文件的仓库到本地时，SBN用时将近一个小时和只需要一分钟。Get的另外一个优点就是它提供了良好的分支机制，我们可以在自己创建的分支上进行开发工作，而不影响其他人，大大提高的写作效率。此外，由于本地就是一套完整版本库，用户在网络不可用的情况下，依然可以使用本地仓库进行离线工作。相对而言，这更适合分布式开发，而且公共服务器的压力不会太大。当然，这也是有缺点的，比如他的操作方式不太符合常规思维，学习周期相对较长。代码管理在有了实体的软件支持后，想要再提高团队的协作效率，就要从虚拟的工作流程上下手了。前面提到G的分支机制承载此重任，那么它具体是怎么做到的呢？在这里我给大家讲解四种主流的工作流模型。

第一个分支模型叫做Trump base development，简称TPD，翻译过来就是主干开发。主干开发模型最大的特点在于它只有一条长期分支，也就是我们所说的主干分支，分支名一般叫做master或者是main。在开发的过程中，所有的开发者都会将代码直接提交到主干分支上，而且这种提交的频率会很高，做到持续提成。在这种模式下，只有当我们要发布某个版本时，才会创建一个临时的发布分支，一旦发布完成，这个临时的发布分支就会被删除。这种模式啊，有几个好处，第一个好处是通过进行这种小而频繁的代码提交操作，可以大大降低代码合并的复杂度，缩短代码合并所需要的时间。

第二个好处是，由于所有的开发者都是直接将代码提交到主干分支，我们可以近乎实时的查看每个同事的工作内容以及进展情况，这样子就有利于及时发现可能存在的问题和风险，让沟通更及时、很高效，大大缩短反馈周期，从而加快软件交付的速度。作为一个极度轻量级的分支模型，主干开发模式虽然有不少的好处，但是并不是所有的团队都适合采用这种模型，因为它的官方全称其实是叫做Trump base development for small teams。顾名思义，这种模式是和人数较少的团队，因为当参与开发的人数变多时，发生代码冲突的几率就会大大增加。此外，TPD对团队成员的工程能力要求较高，毕竟我们谁都不愿意看到经验较少的同事将一些没有经过测试的代码或者一些不符合规范的低质量代码直接提交到主干分支上。因此，在人数比较少并且整个团队的工程能力都比较强的时候，才推荐采用PPD。

大家如果对主干开发这种分支模型感兴趣的话，可以通过我们在左下方提供的链接进行延伸阅读。接下来我们来看看另外一款分支模型。2012年，一位软件工程师发表了一篇博客，名为呃，Successful GI brushing model。在这篇博客中，Vinson向大家介绍了一个他在多个项目中使用过并且都取得成功的分支模型。没错，这个模型正是后来为大家所熟知的gift flow。与主干开发模型不同的是，Get flow有两条长期分支，分别是master分支和develop分支。master分支用于存放对外发布的版本，任何时候在这个分支拿到的代码版本都是稳定的发布版，并分支用于日常开发工作，存放的都是最新的、正在开发中的代码。除了master和develop分支以外，Gift flow还有三种不同的临时分支，分别是feature relief和hot fix分支。其中feature分支是从develop分支上拉取出来的，主要用来开发新功能。当我们需要定。

行开发多个新功能时，可以通过创建多个不同的feature分支的方式来避免不同开发人员之间的代码冲突。功能开发完成之后，Feature分支就会被合并到develop分支，而release分支则是从develop分支上拉取出来的，主要用来进行发布工作。当我们需要发布某个版本时，就可创建一个release分支，使得发布工作和其他功能开发工作可以并行进行而互不影响。

发布完成以后，Release分支会合并到develop分支和master分支，Top分支则是从master分支上拉取出来的，主要用于修复线上的紧急问题。问题修复完成以后，Perfect分支会被合并到master和develop GI pro的优点在于每种分支都有其明确的用途，并且每个分支的名称都能很好的反映其真实的用途。除此以外，不同分支之间可以实现互相隔离，不同的功能模块之间可以独立开发和测试，互不影响。虽然gift pro的优点不少，但是其缺点也很明显。最大缺点在于分支太多了，整个流程过于复杂。一个功能从开发到最终发布要经历好几个分支，其中分支的流转和合并规则则非常麻烦。此外，很多网站项目都在推行持续发布代码，一旦有变动就会发布一次。在这种场景下，Master分支和develop分支的区别不大，没有必要维护两个长期分支。

就连当初提出get flow的link也意识到了这个问题，并于2020年在原来的那篇博客开头处添加了一条补充说明。他表示，对于那些需要进行快速迭代和持续交付的团队，不建议使用GI flow，而是应该采用一些相对简单的work flow，比如gih flow。如果你的软件需要维护多个版本时，GI flow会是一个不错的选择。至于怎么使用get flow去维护多个版本，丁森并没有仔细说明。我们在网上找到了另外一篇博客，是关于如何使用gift flow去管理多个版本的，感兴趣的同学可以通过我们提供的链接去进行延伸阅读。接下来就让我们一起来了解一下giitar flow吧。在2011年，一位giar员工发表一篇名为giitar flow的博客。在这篇博客中，Scott先是肯定了Di flow的优点以及他对整个行业所产生的积极影响，然后便指了Di flow的一些不足之处。他表示，Get flow最大的问题在于整个流程过于复杂，以至于冰森他们还专门写了一个脚本工具啊，也就是电插件来帮助使用者来执行Di flow的相关操作。

但是事实上，很多开发团队并不需要这么复杂的分支模型。SC说，叶卡公司每天都在往生产环境发布新版本，而且往往是在一天之内发布多次。对于像他们这种需要频繁发布的团队而言，整个流程越简单越好。为此，他们创建了一个新的分支模型，也就是我们所说的gih。关员件他score给出了以下六点描述。

第一点，Master分支上的代码都是稳定的，随时可以进行部署。第二点，当我们需要开发新功能时，我们需要从master分支中拉取一个新的功能分支，新分支的名称必须能够反映其用途。第三点，我们需要将变更信息提交到创建的功能分支，并频繁的推送到远端服务器的同名分支上。第四点，当我们需要反馈意见时，或者当功能分支是时候要合并到master分支时，我们需要上线to request。第五点，当指定人员已经评审完功能分支上的代码，并且没有发现问题时，我们才可以将功能分支合并到master分支。第六点，当我们已经完成了代码合并并推送到了远端服务器的master分支后，应该立刻启动部署流程。从SC给出的描述可以看到，相对于GI而言，Get flow属于轻量级的分支模型，因为只有主分支是长期存在的，整个流程更加简洁和直观。然而，凡是都有两面性，由于缺少develop分支，Master分支就变成技事，集成的地方就是发布的地方，一旦集成出现问题，后续的发布和合并工作都会受到影响。

对于那些需要进行持续发布的品而言，Guar flow是一种不错的选择，但是在另外一些使用场景下，它的缺点就会暴露出来。举个例子，假设我们正在使用get flow来开发一款苹果商店的APP，当前已经完成了这款APP某个新功能的所有开发工作，并且已经将代码提交到了master分支。由于苹果商店规定所有APP都需要审核通过以后才能正式上架，因此并不能马上发布master分支上的代码。此时，如果有其他新的功能分支被合并到了master分支，那么此时master分支上的代码就和我们提交审核时所提交的版本不一致了。由此可见，在某些情况下，只有master的一个主分支是不够用的。接下来我们再来看看另外一个分支模型GI flow GI flow是GI公司在2014年提出的一种分支模型，它吸取了GI flow和giar flow两者的优点，具有适应不同环境的弹性，又保留了只有单一主干分支的简单和便利性。

从左边这张图可以看出，GI flow和GI flow区别在于GI flow为开发、集成和发布过程中用到的不同的环境都分配了相对应的分支。其中master分支用于存集成环境中的代码，Pre production分支用于存储预发布环境的代码，而production分支则用于存储已经部署到生产环境的代码。当开发人员需要开发新分支时，就会从master分支拉取一个新的功能分支。当开发人员完成开发并通过测试以后，就会创建一个合并请求，将功能分支的代码合并到master分支，然后触发动部署，将master分支的代码部署到集成环境。

当测试人员在集成环境下完成所有的测试，并且所有测试都通过以后，Master分支上的代码就会被合并到re production分支，然后触发自动部署，将pre production分支的代码部署到预发布环境。当测试人员在预发布环境上完成了所有的测试工作，并且验收通过后，Production分支上的代码就会被合并到production分支，然后再触发自动部署，将production分支上的代码部署到生产环境。现在让我们借助前面已经提到过的一个例子来说明一下giar flow和GI flow的区别。假设这次我们改为使用GI来开发APP，由于每个环境都有其对应的分支，我们可以将那些已经提交给苹果应用商店进行审核，但是还不能发布到生产环境的代码合并到production分支，而其他功能分支的代码也可以继续合并到master分支，这样就可以保证所有开发人员的工作都能有序进行，步不阻塞。除此之外，与GI flow不同的是，在执行的流程上，GI flow会严格遵循astream first上有优先的原则。举个例子，当生产环境出现了一个紧急问题时，我们需要从master分支拉取出一个功能分支，并在这个分支上修复该紧急问题。当这个功能分支上的代码通过测试以后，我们会将这个功能分支依次。

合并到master分支上，分支最后才是合并到production分支。之所以强调我们要遵循这么一个合并顺序，是因为我们的开发人员很多时候只记得将这个功能分支合并到production分支，而忘了将其合并到master上。如果真的出现这个情况的话，那么后续其他从master拉取出来的功能分支都会再次出现这个紧急问题。而pro所提出的upsream first原则就可以有效的避免这种情况。与giha pro相比，GI pro通过为不同的环境添加不同的分支的确解决了一部分问题，但是也增加了整个流程的复杂性。

还有一点需要注意的是，其实我们这里所提到的分支模型只是GI pro2种形态中的其中一种，这种形态我们称之为支持多环境的pro。对于那些需要进行持续发布的项目，我们推荐使用这种分支模型。GALA pro的另一种形态是对于每一个稳定的版本，都会从master分支中拉取出一个新的release分支。这种形态的GALA pro比较适合用于那些需要将软件交付给外部客户的项目或者是一些开源项目。由于时间关系，这里我们就不详细讲解这种形态的GA flow了。

右下角的链接是发布在GA官网上的一篇关于GI pro的详细说明文档，感兴趣的同学可以点击这个链接进行衍生阅读。以上就是常见的四种give work flow的精华总结了。由此可见，我们很难断言哪种work flow是最好的，因为每种work flow都有其优点和缺点，而且使用的场景也不太一样，我们需要根据自己的实际情况选择最适合自己的deep work flow。在今天的原生时代，诞生了everythings code和GIDOS的新理念，以前所讲的代码管理里的代码两个字又被赋予了新的使命，接下来就让我来带大家继续了解吧。everything next code翻译过来就是一切接待码，意思是将一切东西都转换成代码来进行管理。一些具体的实践包括pipeline code infrastructure as code和policy code等等。

我们先来看看什么是pipeline code。啊这个词语翻译过来就是流水线及代码。那么在没有实施piline code之前，我们是怎么配置自动化流水线的呢？左边的截图是真流水线的配置页面，从图中可以看到，传统模式下，当我们需要执行某个步骤时，是需要像填表单一样在每个输入框里面填写内容的。这种模式的弊端在于所有的配置都是没有版本记录的。此外，如果其他同事想要配置一条相同的流水线的话，只能是通过截图的方式，但其按照已填写的内容逐一填写表当中的每个输入框，不利于团队协作。而在实现了pipeline code以后，就能很好的解决这些问题。首先，我们会有代码去定义流水线，并且将相关的配置文件都保存在代码仓库里面。

这么做会有几个好处，第一点是可以方便我们进行团队协作，如果有同事想要在本地创建一条相同的流水线的话，只需要拷贝代码仓库里面的流水线配置代码，即可轻松实现一键复制。第二点好处在于，借助平台提供的自动化能力，我们可以实时监听代码仓库的变更事件，一旦检测到流水线相关的代码有变动，就可以自动触发该流水线，实现持续提成。第三点好处在于，借助地代码仓库提供的能力，跟流水线相关的每次变更都会有记录，让变更一目了然，版本可追溯。了解了PI code以及它的好处以后，我们现在来看一看coding在这一块的产品实现吧。左边的截图就是用来保存自动化流水线的代码仓库，由图中可以看到，在这个代码仓库的根目录下有个名为drink style的配置文件，这个配置文件就是用来定义自动化流水线的。如图所示，流水线的每个步骤都是以代码的形式进行配置的，我们再也不用像填表单一样去填写每个步骤的内容了。

和右边的截图就是coding持续集成流水线的配置页面。当我们新建一条流水线时，我们可以选取某个代码仓库，然后在配置来源中选择使用代码仓库中的drinkingpi这个选项。配置完以后，流水线就会自动读取代码仓库中的drinking style，并依次执行drinking style中用代码定义的每个步骤。接下来让我们来了解infrastructure code。在云计算技术和微服务架构诞生之前，服务器的数量和配置项都比较少，人们一般是通过命令行或者借助其他图形化工具来更改和管理基础设施。如果我们想更改某项配置，需要在可视化的控制面板上选中某个配置下，然后在修改相关的配置，也就是手动修改基础设施。近年来，随着云计算和微服务等技术的快速发展，服务器和配置下的数量也随即暴涨式增长。

基础设施的变更变得更复杂也更频繁。传统的人工配置方式面临着巨大的挑战，因为它难以进行扩展，需要消耗大量的人力和时间，而且还容易出错。大家都知道，人没有机器程序可靠。为了解决这个问题，并发structure s code简称为iacc便应运而生了。翻译过来就是基础设施及代码。印发CODE1书的作者对iacc的定义如下，基础设施及代码是一种使用新的技术来构建和管理动态基础设施的方式。他把基础设施工具和服务以及对基础设施的管理本身作为一个软件系统，采纳软件工程实践，以结构化的安全方式来管理对系统的变更。

简单来说，基础设施及代码就是使用机器可读的配置文件，而不是物理硬件配置或者交互式配置工具来管理和配置it基础设施的过程。IC有三个目标，分别是标准化、自动化和可视化。标准化指的是以代码来定义环境，实现开发环境、测试环境和生产环境的标准化，自动化指的是以自动化工具来进行环境的配置，比如创建环境、更新环境和销毁环境，可视化指的是借助工具实现环境信息的可视化，展示环境的单纯状态和变更历史，实现一切可追溯。左图显示的就是目前市面上一些知名度较高的IC工具，每款工具在功能上都有其侧重点，我们可以根据自己的实际情况来选择最符合需求的工具。接下来让我们一起看看如何在coding。

平台上通过结合第三方IC工具来实践吧。在这个例子中，我们选择的是一款名为telephone的IC工具。借助telephone，我们不再需要登录到服务器控制台的web页面去手动开启一台服务器，也不再需要手动配置BBC，只需要编写好相对应的telephone脚本，就可以一键完成所有的配置工作。左边的截图就是coding与telephone进行集成后的效果图，整个集成过程非常简单，只需要通过简单的几个步骤就可以实现。首先，我们将编写好的telephone脚本保存到Co代码仓库，然后在Co的持续提升模块创建一个构建计划，通过配置触发规则，可以实时监听代码仓库的变更事件。当telephone脚本发生变更时，就会自动触发执行构建计划。这个构建计划的第一个步骤就是从代码仓库中检出telephone脚本文件，第二个步骤是执行一些shell脚本，在构建服务器上安装telephone工具，第三个步骤是执行telephone pan命令。执行完这个命令以后，构建任务就可以暂停执行，并且提示我们进行人工确认。这个时候我们可以在控制台中查看将要添加的资源，确认无误后，我们可以点击继续执行按钮，构建计划就会继续往下执行telephone和派命令，自动创建相关资源。

这就是coding DES平台中集成第三方IC工具的简单演示了。接下来我们再了解一下poly CS code基础设施及代码，最核心的目标就是通过模块化的、可重用的代码组件来快速高效的创建和配置it基础设施。以telephone这款IC工具为例，我们可以从telephone rery下载那些由其他开发人员开发的telephone模块。通过服用别人已经开发好的模块，我们可以避免重复制造轮子，从而大大提高工作效率。然而，这些telephone模块在带来便利性的同时，其实也浅藏着风险。根据bridge pro公司发表的一篇名为state of open source telephone report的报道显示，截制至2020年第二个季度，有48%的telephone模块中存在着错误的配置，其中出现错误配置最多的四大范畴分别是。

数据备份和恢复vlock和recovery日志、loging、数据加密和Google，这些错误的配置会使得我们的系统变得脆弱，增加系统的售工经验，最终可能引发影响业务运营的重大问题。为了防止此类问题的发生，我们急需一种防范机制来帮助提前发现并及时处理这些潜在的错误配置问题，不断提高系统的安全性。policys code便应运而生了。POS code，翻译过来就是策略及代码。

简单来说，策略及代码是通过代码的方式去定义、更新、分享和实施策略。传统模式下，我们想要检查某项配置是否符合安全规范时，往往需要参照一些已经写好的安全规范手册来进行人工检查，这种做法费时费力，在微服务时代，这种方式显然是不可取的了。想要提高效率，我们必须借助一种自动化工具来快速检测这些潜在的安全问题。由bridge公司开发的check工具正好可以满足需求。

如左边的流程图所示，我们可以通过结合coding代码仓库、coding持续集成流水线telephone和check code来实现cos code首先，运轨人员会指定策略文件并保存到coding代码仓库，与此同时，开发人员会编写KS相关的yama文件并保存到coding代码仓库。当Co引持续提升流水线监听到存储KS相关的压文件的代码仓库有新的提交记录时，就可自动触发相关的自动化流水件。流水线的第一个步骤是从coding代码仓库中拉取KS相关的yama文件，然后会执行telephone plan命令，生成对应的telephone plan文件。紧接着C会使用checkco对刚刚生成的telephone plan文件进行扫描，如果检测出不合规项的话，就会终止流程并展示相应的不合规项，如果未发现不合规项的话，就会执行telephone和plan命令，按照telephone time里面的内容去创建或者配置我们的IP基础设施。总结一下，Po CS code具有以下优点。

精准、快速、高效，版本化控制变更可评审、自动化检测释放人力资源可重用、可共享、可审计、可追溯、安全左移，提前发现风险及时修复，强化质量门禁，提前终止不合规的任务。左边的截图就是实现了po CS code的自动化流水线的执行效果，红框的内容就是借助IC静态扫描工具check off对telephone plan进行扫描后得到的结果。右边的截图就是用来存储自定义policy策略文件的代码仓库。可以看到我们在策略里制定system size的属性值要大于等于100GB，而在CI里，Checkoff扫描出的结果是创建机器资源的计划不满足此项要求，因此提前终止了流水线。

这就是基于coding DES平台实现policy code的简单演示。现在我们来讲讲什么是get off？首先回答一个问题，为什么是提到VCS的工具有很多，为什么不是sb not等其他组合呢？大家还记得这些课程的开头，我们做了很多的铺垫，就是要回答这个问题，因为在同时满足以下五点分别是版本管理、分支策略、代码审查、历史记录、用户体验的条件下，只有get胜任。另外就是get到还是一揽子工具的组合。作为主流的get已经和其他工具有了相当丰富的集成了，所以选择get道是最友好的实现。我们先来看看get道的发展史。get道诞生于2017年，是由一家公司的CEO Alice途中的这个人提出的，随后gets的理念开始慢慢被大众接受。到了2018年末，各大云厂商纷纷采用get DOS，而get DOS工作组也在2020年正式成立了。到了2020年，街道成熟度模型诞生了。