我们正在使用codepipeline和codebuild以及bitbucket cloud作为源代码存储库。
我们不会频繁发布，并且我们的发布在发布之前会受到严格的监管(首先由客户在登台环境中进行审查)。
由于代码管道不支持基于标记的版本，我们在develop,staging和production环境中有单独的分支并且特性分支将经常合并到开发分支中。开发分支将很少合并到分级分支中，分级分支将合并到主分支中。
每个分支都有一个代码管道当这些分支中有更新时会触发。
我们目前手动创建从开发到暂存再从暂存到主控触发相应的管道。
-
我想了解应该如何修改当前设置(最低限度地)使其成为真正的CI-CD，但没有彻底检修
-
我应该如何确保阶段/生产管道不应该通过，除非开发管道已经为相同的代码触发(我正在考虑在开发管道部署时更新SSM中的版本列表，以便如果阶段/主版本在SSM中找不到，管道将不会通过。有更好的方法吗?我应该这样做还是采取不同的方法?
p。S:功能标志听起来不像是一个好选择，因为由于不经常部署，我们最终会有很多代码只有功能标志。是的，我知道基于主干的分支是每个人都在谈论的话题，但我不明白它如何适合我们的代码管道(没有基于标签的触发器)和不经常部署到staging/prod?
在我看来，您的构建和部署过程准确地反映了您的发布过程。
我认为在贵公司有以下情况:
- 您需要生产分支来对生产进行热修复。这些更改需要合并回暂存。
- 即将发布的版本(prod +1)在登台很长一段时间。你继续对需要合并回的暂存分支进行更改开发并转发给生产分公司
- 未来的版本(prod +2)是在开发分支上完成的代码准备好后需要合并到staging分支。
- 你花了很多时间管理代码合并(可能还有灭火)代码回归引起的问题)
CICD中的C代表'连续"。CI/CD设计为加速频繁地发布到生产环境，但你明确地说你不经常发布。
你的问题:
- 更接近真正的CI是使用基于主干的开发和短寿命的功能分支。您的管道将构建单个部署工件并部署相同的工件通过开发、登台和制作。特性标志或类似的标志将被用来保持你的代码总是可发布的-不需要基于标签的触发器，因为每个提交都可能是可释放的。
你已经表示你在某种程度上理解这一点，但不认为它适用于你的操作环境。
- 如果你必须有不同的管道运行不同的分支为不同的环境，对我来说，这是你的代码管理过程的问题，而不是代码管道。你应该主要在源代码中处理这个问题，它在你的代码管理工具和过程中。
您的问题2向我表明，您在公司内部对这一过程没有信心，并且正在寻求在AWS内部解决AWS之外的问题。
这都反映了一个不幸的现实，即在不同的环境中拥有长寿命的分支。
这正是开发CI作为解毒剂的场景，但是您忽略了CI/CD的好处所需要的两个主要技术(基于Trunk的开发和特性标志)，并且您的发布周期不支持其中一个主要好处，即频繁发布到生产环境。
每个组织都有自己的约束和特定的权衡，我当然不了解全部情况。在我看来，你的问题中的潜在问题是你如何发布和管理你的代码的直接结果，如果没有实践，你不能期望CI/CD的好处，这确实意味着你如何工作的根本改革。