了解下：CI／CD理解

guozhiwei · 发表于 2022-2-28 08:31:24

　　项目立项–>需求调研–>需求拆解–>交给不同的开发进行开发–>测试环境测试–>部署生产环境。devops 工具https://www.jfrogchina.com/devops-tools/的最新消息欢迎进入网站了解，网站有专业的客服人员进行详细的解答！

　　一个软件产品从开发到用户使用涉及的开发环境、测试环境、预发布环境、生产环境如何理解?

　　1、开发环境: 开发同学开发时使用的环境，例如java环境、go环境、python环境2、测试环境: 一般会由测试人员自己来部署，然后在此环境进行测试。3、预发布环境: 测试环境到生产环境的过渡。测试环境可能会受到一些限制，一些流程或者数据没有测试到，就可以在预发布环境进行验证，从而保证产品上线质量。4、生产环境: 即线上环境，用户使用的环境。由运维人员来维护，其他人员几乎无权限

　　预发布环境和生产环境区别

　　1）预发环境中新功能为最新代码，其他功能代码和生产环境一致。

　　2）预发环境和生产环境的访问域名不同。

　　3）注意事项：预发布环境一般会连接生产环境的数据库，测试时要注意，以免产生脏数据，影响生产环境的使用。

　　发布方式效率干扰安全性手动发布慢干扰因素多不安全自动发布快干扰因素少安全

　　手动实现代码上线?

　　1.开发通过QQ/微信发送压缩包，rz上传，解压部署。

　　2.手动scp方式上线代码。

　　3.手动xftp方式上线代码。

　　4.登陆代码托管平台，手动执行git pull。

　　手动上线方案缺点：

　　1.全程运维参与，占用大量时间

　　2.如果节点多，上线速度慢

　　3.人为失误多，目录管理混乱

　　4.回滚不及时，或者难以回退

　　持续集成持续交付持续部署

　　持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。

　　从上图来看持续集成的流程：

　　开发人员提交代码到 Source Repository （源代码仓库），并通过 git hook 等触发 CI Server（持续集成服务器）的相关功能。执行编译 -> 测试 -> 输出结果的流程，向开发人员反馈结果的 report

　　持续集成的好处：

　　1.易于定位错误：每一次的代码集成都需要执行相关的测试工作，持续集成频繁的集成次数天然的将复杂的代码逻辑切割为了小块，也就使得每一次测试中遇到的错误能够更加容易的被定位；

　　2.易于控制开发流程：更为细致的工作提交也就意味着更容易判断当前的工作进度，这对于管理者规划开发流程而言提供了一个有效的参考，同时也为开发人员省下了汇报工作的时间；

　　3.易于CodeReview：对于大块工作的切分自然也有助于做 CodeReview；

　　4.易于减少不必要的工作：build 以及 test 过程的自动化可以为你节约一大票的时间，从而投入到有价值的工作中去。

　　持续交付指的是：一种能够使得软件在较短的循环中可靠的发布的软件工程方法。

　　与持续集成相比，持续交付的侧重点在于交付，其核心对象不在于代码，而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试，其变动到持续交付后还需要一些额外的流程。

　　可以看到与持续集成相比较，持续交付添加了 Test -> Staging -> Production 的流程，也就是为新增的代码添加了一个保证：确保新增的代码在生产环境中是可用的。

　　在这一增加的流程中，Test 环节不仅仅包含基本的单元测试，还需要延伸到更为复杂的功能测试以及集成测试等。在这里，Staging 指的是类生产环境，其尽可能的对真实的网络拓扑、数据库数据以及硬件设备等资源进行模拟，从而为测试人员反馈代码在生成环境中的可能表现。流程中每一个环节的执行结果都会对开发人员进行反馈，每一个出现的错误都会导致版本的回滚。当测试完毕确认无误之后，将由相关人员对其进行手动部署到生产环境。

　　持续部署意味着：通过自动化部署的手段将软件功能频繁的进行交付。

　　与持续交付以及持续集成相比，持续部署强调了通过 automated deployment 的手段，对新的软件功能进行集成。

　　可以看到，同持续交付相比持续集成的区别体现在对 Production 的自动化。从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预，完全通过自动化的方式执行。这一策略加快了代码提交到功能上线的速度，保证新的功能能够第一时间部署到生产环境并被使用。

　　介绍完了持续集成、持续交付和持续部署三大件，接下来介绍 DevOps。与三大件不同，DevOps 更偏向于一种对于文化氛围与思想的构建。

　　在传统的团队组织方式中，开发人员与运维人员之间是割裂开的，软件开发流程被分割为多个独立环节，分别由不同的人员执行。这使得软件开发过程中需要付出高昂的沟通成本，层层手动的流程将大量的时间耗费在了重复的劳动中。

　　在 DevOps 的指导下，不同技能的人员处在同个团队中，为了一个共同的软件开发目标而工作，更好的协同工作与自动化的手段能够优化整个 Code -> Build -> Test -> Release -> Operate -> Code 的循环。这一理念看起来很美，用图画来说明就构成了一个和谐友好的大圈，不过在实际应用中也许会遇到不少问题，例如不同技能人员之间相互沟通的额外开销、团队组织形式改变后为管理所带来的困难等等。这些问题需要真正的 DevOps 在开发过程中开展起来才能解决。

　　持续集成是三者中最简单的，同时也是开销最低的。由于不需要类生产环境的配合，测试环境也可以仅支持单元测试的执行，使得持续集成的实现是最为便宜的。考虑到现实开发过程的种种限制，向资源与成本做妥协，舍弃持续交付或者持续部署这样看起来很美的方法，退而转向持续集成也是很合理的选择；持续交付面向开发初期或者软件稳定性或者安全性要求较高的领域，新增代码提交、编译、测试等一系列环节均可以通过自动化工具完成，很好的节约了人力资源的同时，还对新增代码的功能进行了有效的保障。在手动执行的部署环节，还可以添加在执行完毕标准测试之外的可能需求，以保证发布功能的可靠；持续部署面向稳定的发布上线后的功能更新。自动的，无需人工干预的部署可以保证新增功能第一时间被发布到生产环境中，确保其尽快的被用户所使用。其与持续交付相比，就在于其功能可靠性与功能及时性的侧重不同。

　　参考链接1：https://www.zhihu.com/question/23444990