为什么KeeBoot只有方案没有产品实体？

一位之前的挖财老同事跑去了新的社交电商翘楚-云集家里某个部门做技术负责人， 回头来问我， 之前那套发布系统有没有现成的？

比较抱歉的是，我的回答是，没有。

为什么呢？ 因为这东西太非标品了，作为一个创业公司的产品，收入显然不足以支撑研发投入，而且既然是非标品， 那么就意味着没法批量复制，自然产品的未来天花板也是看得到的， 所以，我们不做这样的产品。 但老同事显然是吃到了这样的服务交付和治理平台在之前研发链路支撑上甜头，所以肯定不死心，所以，我就推荐他看看Gitlab的商业版产品，能花钱买现成的，显然更靠谱。

但是在当前时代下， 研发团队要提高软件的交付效率， 在某一个阶段，一定需要在交付和治理平台这个层面加大投入， 这属于研发阶段基础设施的重要一环， 上承接SourceCodeControl，下平滑软件的发布和部署， 中则总控整个交付流程， 说它一夫当关万夫莫开也不为过。

我们说，KeeBoot是方案而没有产品实体不能标准化是因为， 每个公司的组织结构，团队能力， 技术体系等都不同， 加上KeeBoot要连接和整合整个软件交付链路上所有的资源(配合CMDB)， 其中的组合数量是很多的：

• 源代码的SCM， 有的用Github， Gitlab， 有的用SVN/CVS(时代跨度)，像KEEVOL则更是小众的用GOGS；
• 编译工具， Maven，SBT，WebPack， Gradle，etc;
• CICD工具， Jenkins, CircleCI, GitlabCI, etc;
• 服务器资源， 机房拓扑，etc；
• Storage；

还有很多非功能性需求，比如安全， 质量， 架构等所有的需求都可以落实到这个平台上， 而这些工作则需要不同的团队根据自己组织和团队的情况来落实，牵扯的因素之多可想而知。

所以， 东西肯定是好东西， 但KeeBoot软件交付和治理平台方案不同于一般意义上的DevOps平台(虽然为了简化，我们一般也会这样跟客户讲)，要让每个企业用上，就需要企业根据自身情况进行定制，这就需要先诊断，再下刀(出方案细节并推进落地）。

KeeBoot软件交付和治理平台配合KEEVOL的技术与管理顾问服务，可以帮助企业贴身的完成平台的搭建落地，帮助企业极大提高软件的交付效率， 至于那时候也不需要提什么微服务了，因为KeeBoot的宗旨本身就是提供无微不至的服务！