问题描述
在一家小型创业公司工作。公司有三个环境（生产环境、开发环境和预发布环境），使用GitHub作为版本控制系统。所有环境都在EC2上运行Docker。用户希望有一个简单的CICD解决方案，可以在某些分支合并后自动触发构建，或者手动触发构建。用户希望当有代码合并到dev-merge分支时，自动构建并部署到开发环境，同样的操作也适用于预发布环境，并将镜像推送到ECR并进行Docker更新。用户尝试过Jenkins，但觉得对于小规模基础设施来说过于复杂。用户也考虑过GitHub Actions（自托管运行器），但需要在仓库中编写YAML文件。用户希望找到一个可以在不编写代码的情况下修改流水线或整体流程的解决方案（就像Jenkins提供的通过GUI手动配置作业的方式）。用户询问关于Team City（自托管社区版）的意见。用户只考虑免费且可自托管的选项。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
我建议重新考虑使用配置即代码（你所说的代码托管的CICD配置），这被认为是最佳实践。它的优点是你可以设置你的工具指向你的仓库，然后它就可以“自动工作”了。这提供了一个单一的真理来源，以及“简单”（相对于手动重新配置所有作业来说）的灾难恢复。
唯一的缺点是，如果你更新流水线而不想推送代码更改到你的生产分支，那么你就会遇到问题，但只有在你想要进行回滚时才会影响你。此外，你可以使用git checkout feature/otherbranch -- Jenkinsfile命令将文件拉到你的生产分支。
Jenkins:
我在一些自己的项目中使用Jenkins，并有一个几乎符合你要求的设置（除了我在每次推送时构建，并根据单独的配置在单独的仓库中部署）。以下评论是基于这个设置的，你可以在GitHub上的演示项目中获取灵感。
你可以将流水线配置放在一个单独的仓库中，并编写代码来手动检出代码，但这意味着你必须让该作业经常轮询第一个分支（以模拟开箱即用的触发器，如果你只使用一个仓库）。
或者，你可以通过手动配置Jenkins中的流水线来消除第二个仓库，但你必须为每个分支创建一个流水线（你将错过多分支流水线的好处，再次建议你重新考虑配置即代码的方法）。
方案2
在OneDev中，可以在GUI中配置流水线。详情请参见这里。
但我不确定这是否适合你，因为它是一个带有CI/CD的Git服务器。
但也许可以设置一个镜像（这可能会复杂化事情）。
或者你完全切换到OneDev，这可能有风险。