问题描述
在一个小团队（3人）中开始了一个项目，由于没有单元测试，只依赖手动测试，他们不得不进行大量的hack，并构建了一个大型应用程序。现在他们有了巨大的技术债务，并开始实施CI/CD。他们的目标是在整个项目中开始使用Cypress测试，然后进行一些单元测试和代码重构，并在CI/CD流水线上实施静态分析工具。
他们的想法是不再使用本地环境，而是使用基于服务器的环境。开发人员将代码推送到Gitlab，Gitlab Runner在Digital Ocean上将代码库推送到staging服务器，开发人员在Digital Ocean上使用本地Cypress Runner进行调试和自己的修改，如果他破坏了某些东西或忘记进行完整的回归测试，会在第二次部署之前触发一个命令行测试回归运行器，以防止代码通过到部署/生产服务器。
问题1：我们需要将部署环境与staging分开在2个droplets中吗？我们能在同一个droplet中配置这个吗？
问题2：我们需要使用Docker吗？如果不需要，应该如何实现？
问题3：我们可以做什么设置来减少手动工作？我们的问题不是需要批准，而是尽可能自动化，因为我们既没有IT/DevOps人员，也没有QA。
注意：第一阶段是实现完整的回归测试，第二阶段是实现代码质量工具（静态分析器）如sonarqube，phpStan等。
Stack：LAMP堆栈，使用PHP Codeigniter和vanilla JS。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
在CI/CD流水线中，为了减少错误并促进重构，可以按照以下步骤进行设置：
1. 将完整回归测试放在静态分析之后。这样可以避免在静态分析之前浪费完整回归测试的成本。
2. 为了避免完整回归测试和静态分析成为瓶颈，可以将这些测试拆分为两个主要的功能阶段：
– (pre-)integration阶段：在较早的流水线阶段执行这些测试的子集。这些测试应该是较短的，以保持足够高的提交速率，并避免瓶颈。这些测试的目标质量水平应低于部署，但足够高以保持开发流程。如果希望阻止而不是检测和修复回归错误，可以使用这些测试来限制提交/合并，这样它们实际上就是(pre-)integration阶段。
– post-integration阶段：执行更长的完整回归和/或静态分析测试。这里的目标是将质量提高到部署水平，如果未达到目标，则阻止实际部署。在这个阶段检测到的回归错误对于开发来说并不是阻塞的，修复它们的优先级较低。
方案2
使用Docker可以自动化配置服务器镜像和应用程序镜像，以便部署到staging和生产环境中。
使用Docker可以自动化配置服务器镜像和应用程序镜像，以便部署到staging和生产环境中。
Docker使用标准镜像，您可以通过向镜像添加自定义软件安装和命令来构建镜像。由于Docker的设计是每个容器（一个运行的镜像）运行一个服务，因此您还可以将应用程序拆分为微服务，从而获得更多的好处。
请参考Docker的”images”、”containers”和”Dockerfiles”，以了解其原理和架构。
使用Docker自动化基础设施的好处有很多：
– 您的设置变得不容易出现手动错误。
– 在staging和生产环境中更快地启动服务（您的应用程序或软件）。您可以批量启动容器。
– 更简单地了解设置服务器所涉及的任务。当您开始编写Dockerfiles时，您会思考开发和运维的过程，因为您必须为服务器的设置编写顺序命令。这将带来对您自己的流程以及如何改进它的更深入的理解。
方案3
为了减少手动工作，您可以尝试采用以下方法：
– 采用KISS原则（Keep It Simple, Stupid）。从小事做起，列出您经常进行的手动测试清单。
– 如果这些测试与测试REST端点和/或负载测试有关，请考虑使用诸如JMeter之类的工具来将您的测试编码化，并将其保存为文件，然后在例如Jenkins中触发（使用性能插件）。您可以将测试以CSV格式加载，并从Jenkins中调用JMeter。
这只是一些建议（有很多其他可能性）。希望这能为您的CI/CD设置提供灵感。