问题描述
想知道在CI中是否应该运行性能测试，以及多久运行一次。他们使用了一些测试应用程序性能的工具，比如gatling。虽然可以偶尔运行这样的测试，但实际上并没有定期运行。他们讨论了如何定期运行测试并将其添加到每个构建中，但是CI的速度变慢了。另一方面，了解代码更改是否降低了应用程序的性能是很重要的。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
将性能测试与CI解耦，为每种测试类型创建一个独立的环境。最好的例子是生产环境，它由用户“测试”。
在这里，环境指的是用于部署特定版本应用程序的服务器（我将其称为构建）。在这样的环境中，你通常会有与生产环境相似的设置。根据你的团队限制，我提出了以下解决方案：
无法创建新环境
– 在流量最小的时候（通常是晚上），安排一个任务来启动负载测试。测试完成后，应该有一个报告，足够详细，以指示根据内部NFR阈值需要在哪些方面进行改进。
可以创建新环境
1. 为负载测试创建一个新环境。
2. 对于每个新的构建，如果在CI服务器上成功部署和/或测试，则部署到新环境。
3. 运行负载测试并保存结果。根据你的CI工具，你可以配置报告和根据结果质量配置警报。
无论哪种方案，你都需要指定负载测试套件，以便能够确定延迟过高的位置。我个人建议你选择第二种解决方案。虽然它需要更多的设置和维护工作，但它对以下原因是最有益的：
- 告诉你构建何时开始变得不稳定。对于第一种解决方案，你可能需要进行调查，因为在一天内会发生很多变化。
- 对于使系统变慢的“是什么/谁”有很高的可见性。此时，团队已经意识到问题，并可以立即解决。长期来看，夜间任务可能会被忽视。
- 可以作为性能门，所有响应时间超过一定阈值的构建都将停止继续（例如，进入生产环境），直到响应时间得到改善。这在夜间任务中很难实现。此外，你需要等待一天才能看到改进的结果，或者手动运行测试。
如果你正在进行CI/CD的过程中，快速失败比延迟失败更可取。花一天的时间来解决问题可能会对你的上市时间产生重大影响。
方案2
使用脚本或工具来管理容器的启动顺序可能会增加复杂性，并且需要确保容器A和容器B之间的依赖关系正确设置。
另一种方法是编写脚本或使用工具来控制容器的运行顺序。你可以使用docker run命令来手动控制容器的启动顺序，或者使用一些第三方工具来管理容器的依赖关系。
以下是一个简单的bash脚本示例，可以在容器A启动后启动容器B：
#!/bin/bash
# 启动容器A
docker run -d --name container_a your_image_a
# 等待容器A完全启动
while ! docker exec container_a echo "Container A is ready"; do
sleep 1
done
# 启动容器B
docker run -d --name container_b your_image_b
在这个示例中，我们首先使用docker run命令启动容器A，并将其命名为container_a。然后，使用一个循环来等待容器A完全启动（这里是通过在容器内运行echo命令来测试）。一旦容器A就绪，我们再使用docker run命令启动容器B，并将其命名为container_b。
以上是两种解决方案，你可以根据你的需求和团队的限制选择适合你的方法。