高级持续交付与最佳实践

# 高级持续交付与最佳实践 ## 1. 高级持续交付 ### 1.1 旧系统改造活动 在处理旧系统时，通常会涉及以下活动： - **重构**：从新特性预期出现的地方开始重构旧代码是最佳选择。这样做能让我们为未来的新特性请求做好准备。 - **重写**：如果计划重写部分旧代码，应从最难测试的代码入手。通过这种方式，可以不断提高项目的代码覆盖率。 - **引入新特性**：在实现新特性期间，使用特性开关模式是很有价值的。这样，一旦出现问题，就能迅速关闭新特性。在重构过程中也应采用相同的模式。 在修改旧代码时，遵循先添加通过的单元测试，再更改代码的规则是很好的做法。采用这种方法，我们可以依靠自动化来检查是否意外更改了业务逻辑。 ### 1.2 人为因素的理解 在将自动化交付流程引入旧系统时，人为因素的影响可能比其他任何情况都更为明显。为了实现构建过程的自动化，需要与运维团队进行良好的沟通，并且他们必须愿意分享自己的知识。对于手动 QA 团队也是如此，他们需要参与编写自动化测试，因为只有他们知道如何测试软件。许多公司在引入持续交付流程时遇到困难，原因是团队参与度不够。 ### 1.3 数据库相关要点 - 数据库是大多数应用程序的重要组成部分，因此应纳入持续交付流程。 - 数据库模式更改存储在版本控制系统中，并由数据库迁移工具进行管理。 - 数据库模式更改有两种类型：向后兼容和向后不兼容。前者较为简单，后者则需要一些额外的工作（将更改拆分为多个随时间分布的迁移）。 - 数据库不应成为整个系统的核心。首选的解决方案是为每个服务提供自己的数据库。 ### 1.4 交付流程考虑 - 交付流程应始终为回滚场景做好准备。 - 应始终考虑三种发布模式：滚动更新、蓝绿部署和金丝雀发布。 - 旧系统可以逐步转换为持续交付流程，而不是一次性完成。 ### 1.5 练习 #### 1.5.1 使用 Flyway 在 MySQL 数据库中创建非向后兼容的更改 1. 使用官方 Docker 镜像 `mysql` 启动数据库。 2. 使用正确的数据库地址、用户名和密码配置 Flyway。 3. 创建一个初始迁移，创建一个包含三列（ID、EMAIL 和 PASSWORD）的 `USERS` 表。 4. 向表中添加示例数据。 5. 将 `PASSWORD` 列更改为 `HASHED_PASSWORD`，用于存储哈希后的密码。 6. 按照文中描述，将非向后兼容的更改拆分为三个迁移。 7. 可以使用 MD5 或 SHA 进行哈希处理。 8. 检查数据库是否没有以明文形式存储任何密码。 #### 1.5.2 创建一个 Jenkins 共享库，用于构建和单元测试 Gradle 项目 1. 为库创建一个单独的仓库。 2. 在库中创建两个文件：`gradleBuild.groovy` 和 `gradleTest.groovy`。 3. 编写适当的 `call` 方法。 4. 将库添加到 Jenkins。 5. 在管道中使用库中的步骤。 ### 1.6 问题 1. 什么是数据库（模式）迁移？ 2. 你能说出至少三种数据库迁移工具吗？ 3. 数据库模式的主要两种更改类型是什么？ 4. 为什么多个服务不应该共享一个数据库？ 5. 单元测试和集成/验收测试的测试数据有什么区别？ 6. 在 Jenkins 管道中使用什么关键字使步骤并行运行？ 7. 重用 Jenkins 管道组件的不同方法有哪些？ 8. 在 Jenkins 管道中使用什么关键字进行手动步骤？ 9. 文中提到的三种发布模式是什么？ ### 1.7 进一步阅读资源 - [Databases as a Challenge for Continuous Delivery](https://phauer.com/2015/databases-challenge-continuous-delivery/) - [Zero Downtime Deployment with a Database](https://spring.io/blog/2016/05/31/zero-downtime-deployment-with-a-database) - [Canary Release](https://martinfowler.com/bliki/CanaryRelease.html) - [Blue-Green Deployment](https://martinfowler.com/bliki/BlueGreenDeployment.html) ## 2. 持续交付最佳实践 ### 2.1 团队内部掌控流程 团队应从接收需求到监控生产，全程掌控整个流程。拥有一个小型的 DevOps 团队，全面负责产品是很重要的。具体做法如下： - 掌控持续交付管道的每个阶段，包括如何构建软件、验收测试的要求以及如何发布产品。 - 避免出现管道专家，团队的每个成员都应参与创建管道。 - 找到一种好的方式在团队成员之间共享当前管道状态（以及生产监控情况），团队空间中的大屏幕是最有效的解决方案。 - 如果开发人员、QA 和 IT 运维工程师是不同的专家，确保他们在一个敏捷团队中共同工作。基于专业知识划分的独立团队会导致无人对产品负责。 - 要记住，给予团队自主权会带来高工作满意度和出色的参与度，从而打造出优秀的产品。 ### 2.2 自动化一切 从业务需求（以验收测试的形式）到部署过程，都应实现自动化。手动描述和带有操作步骤的维基页面很快就会过时，导致形成难以传承的知识，使流程变得缓慢、繁琐且不可靠。因此，只要是第二次做的事情，就应该实现自动化： - 消除所有手动步骤，因为它们是错误的根源。整个过程必须具有可重复性和可靠性。 - 永远不要直接在生产环境中进行任何更改，而是使用配置管理工具。 - 使用完全相同的机制部署到每个环境。 - 始终包含一个自动化的冒烟测试，以检查发布是否成功完成。 - 使用数据库模式迁移来自动化数据库更改。 - 使用自动维护脚本来进行备份和清理，别忘了删除未使用的 Docker 镜像。 ### 2.3 对一切进行版本控制 对软件源代码、构建脚本、自动化测试、配置管理文件、持续交付管道、监控脚本、二进制文件和文档等所有内容进行