从传统到云无服务器 - 第三部分
内容提要
本文介绍了在Google Cloud上使用Cloud Build进行持续集成的测试和流水线配置，包括测试过程、配置文件编写和镜像推送。下一篇文章将讨论自动化部署和安全策略。
延伸解读
测试策略：使用模拟数据库隔离单元测试
文章中的单元测试通过设置环境变量 TESTING=True 来切换应用使用 mongomock 模拟的 MongoDB 实例，避免测试依赖真实数据库。同时，使用 unittest.mock.patch 替换 todos.insert_one 方法，以验证数据库操作是否被调用，而不实际执行插入。这种隔离使测试快速且可重复，适合在 CI 流水线中频繁运行。
流水线步骤依赖：waitFor 控制执行顺序
Cloud Build 配置文件中，步骤默认按顺序执行，但通过 waitFor 可以显式指定依赖关系。例如，构建镜像步骤等待 run-tests 完成，推送镜像步骤等待 severity check 完成。这确保了只有测试通过且漏洞检查通过后，镜像才会被构建和推送，避免无效或存在风险的镜像进入仓库。
漏洞扫描与严重性检查：自动化安全门禁
流水线中集成了镜像漏洞扫描，并通过 _SEVERITY 变量定义需要拦截的严重级别（如 CRITICAL 和 HIGH）。扫描后，使用 gcloud 命令列出漏洞并检查严重性，若发现匹配的漏洞则构建失败。这为持续集成增加了一道安全门禁，防止已知高危漏洞的镜像被部署。
后续步骤：自动化部署与安全策略
文章提到下一部分将涵盖持续部署，包括将 MongoDB 迁移到 Google Firestore、在 Cloud Run 上部署应用，并通过 Binary Authorization 实施安全策略，只允许经过批准的可信镜像部署。这表明当前 CI 流水线是更大部署流程的基础，后续将结合安全策略实现完整的 CI/CD。
Q&A
如何在Google Cloud上使用Cloud Build进行持续集成？
在Google Cloud上使用Cloud Build进行持续集成时，每次推送到主分支时会触发Cloud Build，首先运行单元测试，测试通过后构建镜像并检查漏洞。
Cloud Build的配置文件使用什么格式编写？
Cloud Build的配置文件使用YAML格式编写，包含用户定义的变量和执行步骤。
如何编写单元测试以测试Flask应用？
使用Python的unittest模块编写单元测试，创建一个测试类并定义测试方法，使用mock对象模拟数据库操作。
Cloud Build如何处理Docker镜像的安全性？
Cloud Build在构建Docker镜像后，会调用镜像扫描器检查漏洞，并根据漏洞的严重性决定是否推送镜像。
Cloud Build的流水线步骤有哪些？
Cloud Build的流水线步骤包括安装测试依赖、运行单元测试、构建Docker镜像、检查镜像、扫描漏洞和推送镜像。
下一篇文章将讨论哪些内容？
下一篇文章将讨论自动化部署和安全策略，包括将Mongo数据库迁移到Google Firestore。
