-
Choerodon平台版本：0.21.5
-
运行环境：自主搭建
-
问题描述：请问一下，我这边自主搭建的猪齿鱼，使用K8S不同的命名空间，创建不同的 dev, uat, prd环境，现在我们这边要针对每个环境使用对应代码分支构建镜像，请问有没有办法每个猪齿鱼环境只能看到对应的分支构建的镜像，而不是把所有的镜像都显示出来？
分支只与功能进行关联。
每次的提交以及制品都要满足一次提交多地部署。
分支、制品、版本等等与你要部署的环境不应该有任何的关系的。
（1）你好，我们现在每个C7N环境是支持部署多个应用服务的，所以选择了应用服务之后，可以选择这个应用服务下对应的所有镜像；暂时不支持限制为【在某个猪齿鱼环境中只能看到某个应用服务某个分支构建的镜像】。
（2）你的意思是：在变更某个实例时，希望可以通过筛出某一个的分支构建的镜像，从里面进行选择吧？
（3）请问你们希望限制为【每个环境只能看到一个应用服务某个分支构建的镜像】的原因和场景是怎样的呢？（因为dev环境中肯定会部署feature、master等多个分支构建的镜像，来进行测试）
我想请问，如果我有两个功能开发，有一个A功能分支开发测试完成能够上正式环境，但是另外一个B分支还是目前还在测试环境测试，这个时候我要部署正式环境，现在如果只用一个分支构建镜像部署的话，就会把B分支没有开发好的代码部署到正式环境，这种应该不行吧
一般也有一种分支管理规范就是一个分支对应一个环境的，比如说prd,uat,dev
场景就是，
一般项目开发规范中，每个环境会对应一个分支，这样分开的原因能保证有些还在dev，或者uat阶段的代码能够跟prd分支隔离，保证没有测试通过的代码，不会上线到正式环境
比如说
正式环境：prd分支
UAT环境：uat分支
开发环境：dev分支
每个环境对应一个分支，那么每个环境也只能部署这个分支构建的镜像，现在猪齿鱼上每个环境能够把所有分支构建的镜像选择到，这样有时候要选择对应的分支镜像会比较麻烦，而且如果操作失误把dev环境的镜像部署到了正式环境，那很危险
一般也有一种分支管理规范就是一个分支对应一个环境的，比如说prd,uat,dev
不确定你说的这个规范是啥，这种用法都是自己想的。比较合适的玩法是要部署生产一定是tag后的版本，分支是跟你任务类型挂钩的，常用的类型有release、feature、hotfix、bugfix等分支，分支管理策略目前主要的就是git flow和github flow分支模型。跟你的环境都是没有任何关系的。你开发时候的内容跟你要在哪里部署是没有关联的。按你的描述吧，生产等敏感环境部署的应该是带版本号也就是有tag过的版本，而不是某个分支内容
你描述的这种分支模型其实漏洞很多的，比如如何定位某个环境运行的内容在哪个分支的哪个commit？出了问题如何回滚？一旦维护多个版本多个环境你这复杂度瞬间指数增长，想想都会一锅粥啊。
其实你说的有道理，我同意，不过每个环境对应一个分支的确是有一定好处的，这样保证新开发好的功能先上线，未开发好的功能后上线，做到代码的隔离，
每个环境对应一个分支，这是很常用的分支开发规范，很多项目都是这么做的，对应到猪齿鱼上来可以衍生为每个分支构建的镜像对应一个环境，支持能够过滤掉其他分支的镜像就可以了，
就像你刚说的分支模型，实际上gitlab分支模型里面，是有推荐每个环境对应一个分支的
关于你的问题
比如如何定位某个环境运行的内容在哪个分支的哪个commit？
答：因为环境本来就是跟分支对应的，某个环境出问题直接找到对应的分支就好了，
出了问题如何回滚？
答：这个跟目前的猪齿鱼现在的部署的方式一样 ，这里应该不影响
其实按照你说的tag的那种方式其实也可以，那在选择制品镜像的的时候，我应该怎么只选到到tag构建的镜像而不是所有的镜像呢
你好，我想请问下如果我提的这个需求不合理，那请问下面这个场景有什么好的解决办法吗？
现在开发环境，测试环境，生产环境都是用的master 构建的镜像，
那我想问一下，现在我有两个需求A和B需要开发，A和B的代码都合并到了master，现在发布了测试环境，测试之后A需求没有问题，可以发正式环境，但是B测试出来还有BUG需要继续修改。现在我要发正式环境上线A功能，这个时候如何才能不要把B的代码发上去呢？
注意：A和B可能是新的功能，也有可能是基于现有功能的调整
你好，我们是这么建议的：
- 正式环境只部署tag；
- tag只基于所有新功能（修复）测试验收通过的分支打出；
- 如果希望某个分支随时候能够打tag并部署到正式环境，就不应该将不稳定（未测试通过）的代码合入此分支。与此同时，新特性或者修复的代码在各自的分支开发，测试验收通过后合入稳定分支。
