虚拟原型和虚拟控制器，可以集成到公司现有的 CI/CD 流程中。为什么我们要集成到现有流程中呢？因为 CI/CD 确实是软件交付性能的驱动因素。
这就是持续集成 （CI）、持续交付 （CDE） 和持续部署 （CD）——统称为 CI/CDE/CD（Bobrovskis 和 Jurenoks，2018）——发挥作用的地方。尽管 CI/CDE/CD 像敏捷或 DevOps 一样促进文化变革，但它包含实际的代码和工具，可简化软件到生产环境的部署。CI/CDE/CD 可以支持 DevOps 和敏捷开发，并在组织中将它们变为现实。
| 通过 CI/CDE/CD | 没有 CI/CDE/CD | |
|---|---|---|
| 集成 | ||
| 集成频率 | 代码集成频繁，每天最多集成几次。 | 代码不经常集成，可能每周或每月集成一次。 |
| 代码兼容性 | 提交是增量式的，这意味着来自不同开发人员的小代码更改更有可能相互协作而不会出现问题。 | 出现兼容性问题的可能性更高，因为大代码段可能具有许多依赖项或与其他代码不兼容的逻辑。 |
| 调试速度 | 可以更频繁地检测到错误，并更快地解决。 | 从长远来看，错误往往会堆积起来，这可能会延迟修复并使修复工作复杂化。 |
| 测试 | ||
| 自动化 | 测试是标准化的，并且很容易自动化。 | 测试是非标准化的、完全或部分手动的，并且不容易实现自动化。 |
| 工程师和开发人员的参与 | 需要最少的 QA 工程师和开发人员参与。 | QA 工程师和开发人员密切参与测试。 |
| 持续时间 | 由于自动化，整个测试阶段可以在几分钟内完成。 | 测试可能会持续数天甚至数周，具体取决于需要完成多少手动工作。 |
| 日志记录和错误报告 | CI/CDE/CD 软件通常具有高级日志记录和错误报告工具，可提供有关故障和错误的详细信息。 | 可能需要手动调试和代码探索来检测测试失败的根本原因。 |
| 部署 | ||
| 自动化 | 部署是自动执行的（持续部署），或者只需要在测试后获得批准（持续交付）。 | 部署是手动完成的。开发人员可能需要手动配置、打包和发布新代码。 |
| 部署时间 | 假设所有测试都成功，代码可以在集成后几分钟内部署。 | 部署新代码可能需要数小时、数天或数周，具体取决于其优先级和开发人员的现有承诺。 |
| 频率 | 新代码可以非常频繁地部署，每天最多部署多次。 | 新代码的部署频率可能非常低，甚至每 6 个月一次。 |
软件可以非常快速地更新和适应不断变化的客户需求。借助强大的 CI/CDE/CD 工作流程，在生产中发现错误和问题后，可以在短短几个小时内修复它们。开发人员还可以在最短的时间内添加新功能或修复程序以满足最终用户的需求（Virmani，2015 年 5 月）。 代码的质量和安全性显著提高。这一点有两个方面。首先，频繁的集成使开发人员能够快速捕获并修复其工作中的问题。其次，开发人员可以在其 CI/CDE/CD 工作流程中添加更全面的自动化测试程序，同时将对上市时间的影响降至最低。更严格的测试可以提高内部代码质量和安全标准，促使开发人员更加关注他们的工作（Arachchi 和 Perera，2018 年，5 月）。 团队可以更专注于开发新功能。CI/CDE/CD 可以节省数小时和数周的开发时间，使团队能够更好地专注于开发新功能。集成代码后，开发人员可以立即开始开发下一个计划的功能（Laukkanen 等人，2017 年）。 团队和企业被迫采用更具协作性和灵活性的工作文化。没有协作、增长的愿望和快速失败的意愿，企业就无法有效地实施 CI/CDE/CD。CI/CDE/CD 的思维方式和文化要求可能会迫使组织完全重新思考他们如何开展业务并优化其所有内部流程，而不仅仅是与软件交付相关的流程。考虑到这一点，向 CI/CDE/CD 的过渡带来的不仅仅是加速软件交付（Humble 和 Farley，2010 年）。
空客。使用 GitLab CI，航空航天公司 Airbus 将功能发布的部署时间从 24 小时缩短到 10 分钟。该公司的项目在五年内从 50 个增长到 850 个，而合并请求平均每年达到 10,000 个。空中客车公司按时发布了 98% 的项目，而其余 2% 的项目仅延迟了几个小时就发布了。CI 还大大提高了对公司项目的可见性，消除了部署中的猜测。 高盛。投资和金融服务公司 Goldman Sachs 选择 GitLab 来简化和加强其工作流程。Goldman Sachs 设法将其其中一个重要项目的发布周期从每 1-2 周一次缩短到每隔几分钟一次。许多团队的功能部署时间降至 24 小时以下。一些团队开始每天创建超过 1,000 个 CI 功能分支构建。 INDEED。通过从 CircleCI 和 Jenkins 切换到 Semaphore 2.0，在线雇佣公司 Indeed 将构建时间从 30 分钟缩短到 10 分钟。Indeed 还将其失败率从 25% 降低到 2.5%，同时将每日部署次数从 3 次增加到 10 次。 西门子。技术公司 Siemens 通过使用 GitLab SCM（源代码管理）、CI/CDE/CD 和 DevOps 转变了其协作和组织工作流程。西门子的主要目标和挑战是建立统一的 DevOps 文化，这种文化将在其拥有 20,000 多名开发人员的多个子公司中发挥作用。为了实现其总体目标，Siemens 将其 IT 基础设施迁移到 AWS，以简化其团队之间的协作。借助 CI/CDE/CD，该公司开始每月生产超过 640 万个版本，并每月部署到生产环境中超过 4 次。 Zoopla。英国房地产公司 Zoopla 采用了 GitLab Self-Managed Premium for CI/CDE/CD，包括版本控制，并改善了开发人员协作。因此，Zoopla 设法将其变更失败率从 40% 降低到 0%。同样，交货时间从 5 天缩短到 2 小时，而功能部署的频率从每周一次变为每天一次。
