CI/CD理解

文章目录

• • 1. 软件开发生命周期
  • 2. 代码上线
  • 3. 自动化代码上线（CI/CD）
  • • 3.1 持续集成/li>
    • 3.2 持续交付/li>
    • 3.3 持续部署/li>
  • 4. DevOps
  • 5. 总结

1. 软件开发生命周期

项目立项–>需求调研–>需求拆解–>交给不同的开发进行开发–>测试环境测试–>部署生产环境。

3. 自动化代码上线（CI/CD）

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

3.1 持续集成/h3>

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

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

3.3 持续部署/h3>

持续部署 意味着：通过自动化部署的手段将软件功能频繁的进行交付。
与持续交付以及持续集成相比，持续部署强调了通过 automated deployment 的手段，对新的软件功能进行集成。

在传统的团队组织方式中，开发人员与运维人员之间是割裂开的，软件开发流程被分割为多个独立环节，分别由不同的人员执行。这使得软件开发过程中需要付出高昂的沟通成本，层层手动的流程将大量的时间耗费在了重复的劳动中。
在 DevOps 的指导下，不同技能的人员处在同个团队中，为了一个共同的软件开发目标而工作，更好的协同工作与自动化的手段能够优化整个 Code -> Build -> Test -> Release -> Operate -> Code 的循环。这一理念看起来很美，用图画来说明就构成了一个和谐友好的大圈，不过在实际应用中也许会遇到不少问题，例如不同技能人员之间相互沟通的额外开销、团队组织形式改变后为管理所带来的困难等等。这些问题需要真正的 DevOps 在开发过程中开展起来才能解决。

5. 总结

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

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