CI/CD

Continuous Integration (CI)

    持续集成是一种软件开发实践，开发人员会定期（通常每天）将代码更改集成到共享分支中。每次集成都会自动触发构建和测试序列，以检测并早期解决任何集成错误。

Continuous Delivery (CD)

    持续交付延续了持续集成的实践，确保你可以随时将新代码更改部署到生产环境中。这意味着除了自动化测试之外，发布过程也被自动化，以减少发布新版本的复杂性和努力。

      在CI/CD环节中，通过运用Git和Container计算可以非常容易的实现整个过程，通过Git实现对代码与版本的管理，通过Container实现构建与发布，CI/CD的落地并不是特别复杂的事情。

Code Preview

    是一种开发工具，它允许开发者在提交或合并代码更改之前预览其效果。这意味着开发人员可以在真实环境中测试和验证他们的更改，而不仅仅是在他们的开发环境中。

我们如何去做Code Preview？

1. Code Preview应该在那个环节去做？

2. Code Preview应该关注代码的什么方面？

    Code Preview也是属于代码管理的范畴，代码的管理，我们通常是采用Git管理，无论是用GitHub、GitLab、Gitee，他们对git的操作支持都是一样的。通常对于代码的管理可以通过branch、tag来管，代码的协作我们通过也是通过branch或PR来协作。

Code Preview应该在什么环节去做？

       在很多公司的项目管理下，大家通常都是通过branch来管理开发代码模块，由成员各自建立branch分支来维护开发项目，其实这并不是git所推荐的方式。

      建议的方案是：项目代码的直接由项目的技术负责人master来维护，他先创建好项目，然后其他同事参与项目的维护是通过fork该项目来维护，master根据项目的环境与进度设置不同的branch分支，大家完成了代码以后PR到master的仓库对应的branch下，由master完成Code Preview以后再merge到项目的branch下，然后再执行CI/CD的过程。master还需要再PR流程中设置 PR check list,当项目成员体检过来的时候，需要先完成PR的CI过程，然后master再去做Code Preview。

Code Preview应该关注那些地方？

        首先master需要要求大家在开发功能的过程中，必须完善相关的单元测试，并满足对应的单元测试覆盖率限制要求，当团队提交过来代码以后，至少会执行如下CI环节，首先是代码的Code Build，再是Code Junit Test，单元测试执行完成以后会自动根据测试的覆盖率结果生成一个自动化的结果。从而每一个PR都能看到如下三个自动化检测的过程：代码能否编译通过、代码单元测试能否执行通过、代码的覆盖率是否满足要求。

        同若代码的单元测试已经完成了所有的业务检测，那么针对master来说Code Preview主要关注的是：单元测试脚本是否合理、代码是否符合内部规范、代码有无明显缺陷与隐患