- Choerodon平台版本：0.21
- 运行环境：自主搭建
- 问题描述：
一个代码库下有多个应用，但是choerodon一个应用对应的是一个代码库，目前使用choerodon服务版本，可以构建一个代码库下的不同子应用，但是在使用choerodon发布的时候，只能手动选择应用然后再手动选择发布应用下的哪一个子应用（choerodon中定义的是服务版本），请问这个可以进行相关优化吗，以支持子应用从而实现流水线发布。
这块确实没有支持的计划，因为现在多数类似的场景都是走的微服务架构，一般会把一个大的应用服务拆分成多个小的应用服务，我们也评估一下，目前接到这种需求确实不多。
因为大的项目可能采用微服务架构，小的项目采用的还是传统的架构，希望你们能够增加这个功能，丰富 Choerodon功能，满足更多用户需求，对于你们来说可能是个小的改动，但是能改变很多小企业。
的确我们现在也特别尴尬，作为公司运维部门，很希望引入choerodon这套系统，但是目前开发部门未使用微服务架构，服务未做拆分，导致我们看着这么好的系统工具不能使用，这种是多么的痛苦。希望你们能评估一下，更多的兼容，满足不同的需求，无论传统的还是现代互联网企业，或者大项目和项目。
确实，我们会针对类似需求进行评估优化
这个是否考虑应用可以支持绑定代码库，这样就能解决这个问题了，其他则不需要进行任何修改。
我们后来有做探讨，仍然觉得应用服务其实指的就是一个代码库，后续会在应用服务上再加一层应用，以满足一个应用包含多个应用服务的情况。但是对应单个代码库对应一个服务，以及后续服务的版本、部署等等这个应该不会再改变了。因为一个代码库在进行开发时只会针对该代码库打出唯一的版本、tag等等，如果从开头就进行多代码库、子应用的拆分会导致后面的流程全部出问题，该逻辑我们也与多方进行过讨论，目前单代码库对应单应用的结论基本是肯定的，因为一旦不是这样即使不在猪齿鱼体系下，代码应用的tag版本、发布维护的逻辑等等都会违背现有的主流应用代码管理逻辑
举一个简单的例子，一个父类的java应用下有多个子应用，都在同一个代码库下，在进行版本发布的时候如何基于git代码管理的逻辑给某个子应用打tag呢？这就导致无法以子应用的流程和逻辑去管理附带所有的版本、分支、任务、部署等等
在应用服务上再加一层应用的确能很好的解决问题，非常明智。多个应用对应一个代码库需要变动的很多，对用户之前的使用习惯影响比较大。目前通过在应用服务上再加一层应用这个方案会在哪一版本中体现了，大概什么时候，非常期待。
你好，请问下一版本实现这一功能了吗？