• 无论您的堆栈是什么，在讨论解决方案之前，您所描述的是任何CI-CD流程的基本用例。您所描述的所有费力的手动步骤都可以使用任何CI工具完成。
• 现在，让我们考虑一下您已经拥有的内容，并讨论一下您想要的解决方案的步骤-您正在使用bitbucket，它至少提供了步骤1和2 -仅将批准的PR合并到master/main中。
• 第3步是我们开始CI自动化流程的地方-您在Bitbucket存储库中的某些操作上定义一个webhook，它触发CI作业/管道（可以是Jenkins服务器、gitlab-ci或许多其他CI解决方案）。这样，您甚至不需要“部署”按钮，因为合并操作可以触发作业，作业可以自动运行单元测试、集成测试（如果您定义了它们），构建工件/停靠映像，最后部署。
• 步骤4需要对Docker容器设计有一些基本的了解--Docker镜像不是VM。它有它的用例和相关场景，更重要的是要遵循建议的体系结构指南。为了使它简短，我只提到分离的原则--每个服务应该在一个单独的容器中。它允许升级和更容易的调试，这意味着，您需要的不是包含整个系统的Docker映像，而是容器的编排，每个容器包含一个独立的软件单元，并具有明确的责任。Kubernetes在这里发挥作用。
• 返回到配置项作业-PR合并后，作业启动，运行预定义的单元测试，构建容器，并上载到注册表。
• 移动到CD -根据您的过程，在更新和测试的docker镜像在您的注册表（可以是artfactory/GitLab注册表/docker注册表...），CD作业可以采取任何镜像，并部署在您的Kubernetes集群。这就是它！该过程完成。

一点建议-如果您没有专业的DevOps团队，或者对Docker、CI-CD流程和Kubernetes没有很好的了解，并且您的开发团队规模较小（不幸的是，似乎是这样）您可能需要考虑雇佣一家DevOps公司来为您构建DevOps/CICD基础架构，最好是一个完全托管的DevOps解决方案，然后进行移交。我写的一切都只是指导方针和基本点，给予你一个大局。祝你好运！

所有其他的答案都在这里，很好，但我还是想给你一点建议。
最近我也在开发一个产品，我们有三个团队成员。这是一个node.js项目。如果你在AWS上，你可以使用AWS管道。这将检测来自特定GitHub分支的推送，更改将被部署到服务器。管道服务也有一个构建阶段。你也可以配置空闲通知。但是你应该至少有两个环境生产和开发来检查开发中的部署是否正常工作。AWS也有AWS代码提交和AWS代码部署这样的服务。
这只是一个基本的解决方案，你实际上不需要花哨的软件来设置ci/cd。

这种设置通常由与Kubernetes耦合的CICD工具支持。

• 可以是内部部署的，如Jenkins+Kubernetes，也可以是Jenkins Kubernetes plugin，后者在Kubernetes集群中运行动态代理。

您可以在Bibin Wilson的“How to Setup Jenkins Build Agents on Kubernetes Pods“中看到一个示例。

• 或者是云服务，如Bitbucket pipeline deploying a containerized application to Kubernetes

在这两种情况下，思路都是一样的：为每个推送的分支创建一个临时的执行环境（一个包含正确组件的Docker容器），以便执行测试。
这样，所述测试可以在特性分支和集成分支（如main）之间的任何合并之前发生。
如果测试通过，Jenkins本身可以触发自动合并（假设特性分支首先在目标分支之上重定基，在您的例子中是main）

我们的团队也有类似的流程，我们使用gitlab-ci。
因此，存在一些码头外基础设施（nginx与测试台DNS），我们只创建dev 1，dev 2...站立（5代表10个开发人员和6个以上微服务的团队）。对于每个devX支架和每个微服务，我们都部署到我们CI-CD中的devX按钮。我们只是在部署后的测试时间为特性Y保留在松弛的devX中。完成测试并修复漏洞后，我们合并到主分支，其他功能早午餐可以在devX标准上部署和测试。

• 下一步，我将更新的“main”分支手动部署到安装了IIS和MSSQL的测试服务器上。
• 一旦完成，我通知测试人员测试新上传的应用程序，以确保“添加关于窗口”是正确的，工作良好。
• 如果测试人员发现一个bug，我必须从“main”分支恢复任务分支合并，并告诉开发人员修复任务分支中的bug。

1.如果有多个环境，那么开发人员可以将自己部署到这些环境中，即使只有一个“开发人员”环境也会有很大的帮助，开发人员应该能够部署自己并通知测试人员，而不需要通过你。
1.部署是“手动”的是可疑的。如何手动？理想情况下，它应该只是几个按钮点击。有时你甚至可以有它，使推到一个分支做部署（通过webhook）。
1.你应该能够从除main之外的分支进行部署。这意味着什么或者看起来像什么可能会有很大的变化，但关键是如果你强迫所有东西都在那里，并且在它不工作的时候不得不恢复，你就创建了很多不必要的工作。理想情况下，应该有一些本地测试的方法。如果真的不能，那么你至少需要允许一种从任何分支进行部署的方法（或者类似于强制推到名为“dev”的分支之类的东西）。
从另一个Angular 看，除非应用程序严重损坏，否则不需要回滚更改，除非发布即将到来，您可以在另一个拉取请求中修复它。

***总而言之，这里的主要问题听起来像是只有一个测试环境，部署到该环境的过程过于手动，而且开发人员无法自己部署。***这类事情是一个巨大的瓶颈。即使是开始测试，也会有一个繁重的过程，这会对每个人的士气造成很大的打击--这可能比速度的损失更糟糕。你不需要“不一定需要每个开发人员能够在按下按钮时启动尽可能多的环境，但开发人员确实需要一些自主权才能进行测试。

让应用程序在Docker容器中运行可以极大地帮助在本地运行它，并使部署过程更简单。我试图远离具体的产品建议，因为这听起来更像是一个过程问题。