讨论背景
上周五(2016.6.3)的时候大家在配置管理之路(ScmRoad)微信群里对maven公共组件最新版本的问题讨论的热火朝天。有的是从技术角度分析去如何管理和控制变更；有的则是通过流程、职责划分去梳理和解决这个。很多人的看法对我都很有启发。每一个观点都是公司或者项目的一个状态反应。每个公司大小不同、业务不一、人员储备、组织架构都不同，这些因素都会体现在最终方案的制定和选择上。 下面我是记录的一些精彩对话，为了让没有参与进去的朋友看得明白，括号中的内容是我进行的补充。当然也可能狗尾续貂了，还望各位别见怪。
开始讨论
大牛妈：用maven的同学？想探讨个公共组件并行版本的问题。问题是：对于公司自己内部开发的公共组件，如何降低它的版本并行度。换句话说，就是如何才能让业务线（产品线）尽可能的使用公共组件的最新版本。
各抒己见
i子休：直接用snapshot版本。
大牛妈： 都snapshot 不靠谱吧？
i子休：用snapshot可能不会break（也可能会break），但是强制升级或者删除版本则一定会break，（所以可以用snapshot，但是需要使用方）自己发布前最好测试吧。
nneos: 我想到了两种方式。主动消灭和被动接收。主动消灭：公共组件有新的版本，相关的开发组都被通知后，自己主动更新依赖到新的公共组件版本，然后发布产品。被动接受：公共组件有的新的（正式）版本，触发相关联的编译，（产品）自己生成新版本。
诺亚之舟：snapshots肯定不行。将公共组件的版本号定义到父 pom,父pom是公共的.如下：
<parent>
<groupId>com.company.abc</groupId>
<artifactId>public-pom</artifactId>
<version>1.0-module-SNAPSHOT</version>
</parent>
大牛妈： 这样的确可以，但是项目自己可以重新定义这个version，覆盖parent的version。
诺亚之舟： 开发的时候<properties>里面定义，发布后parent定义。发布的时候，要看看version 和parent定义的一样不。可以写个脚本检查
大牛妈：我们的确可以这样做。现在的问题是业务线（产品线）上很抵触我们SCM用脚本自动替换。
诺亚之舟：谁主张，谁承担责任。
laofo：的确有这个问题。如果SCM觉得公共部分需要升级去业务线（产品线）推，但是业务线（产品线）又没有这个需要，业务线（产品线）就会有相当大的抵触情绪。没给业务线（产品线）带来价值，反而带来了风险。
大牛妈：是啊，这个工作受益一方是公共组件的开发者。所以想听听大家都现状。
lisa-liu：让公共组件开发者主动推销，哪个团队愿意用哪个就用哪个。开发团队自己选择。
诺亚之舟：问题在这里啊，公共组件长期不升级，当出现安全漏洞等，需要强制升级的时候，长期不升级导致的无法快速响应谁承担责任。
大牛妈：是的，也有这方面的考虑。如果一个项目长时间不升级，等再次升级的时候，（版本）跨度太大也受不了。所以我第一个东家的公共组件（管理）比较狠，直接就是最新版本。所有人只能依赖这一个版本。
诺亚之舟：但是这个时候，当初反对强制升级的人没有任何责任，而你就是背锅的。
大牛妈：现在有谁的公共组件用最新的版本？
诺亚之舟：（我们的现实线上情况是）同一个包使用5个不同的版本，然后研发还说不会有任何影响。
赵永昕：我支持用最新版本，首先从精益的角度触发，（公共组件）升级了，（业务）不用就是浪费，而且从长远角度来看早晚也得用，早用早暴露问题早解决。其次持续集成本来就是解决这种问题的，升级本身就有何成本，所以在升级之前就先考虑好，之后要做的就是保证质量了。
大牛妈：我们的实际情况是，一个公共组件（线上）被依赖了16个正式版本
nneos：找个折中的方法，公共组件升级到特定版本，比如1.1，强制用最新的；另外，公共组件组也有责任去推动这件事。
大牛妈：有一定道理，这样可以一定程度的减少。
老顽童：做好自己该做的，谁说了都可以，能满足各种需求即可。如果我用不到你的新功能，为什么（要我）升级？新版本就不会引入新的未知风险？老版本很稳定、风险基本都知道，只要绕过了风险即可、适合就好，开发自己决定，组件做好 releases notes就好。摆摊子卖货，自己选择自己受。我替业务线（产品线）选择了（版本）（线上出了问题）算谁的？但也要有管制的工具和方法，哪天boss说了（强制所有公共组件升级到最新版本）马上就能实现，分分钟搞定。
大牛妈：其实是两个解决问题的思路，一种是boss让我们做什么，另一种是我能为项目做什么。
老顽童：为项目提供好本职工作、管理好变更管理就好。其实是一种思路。做好本职工作。boss和开发都是服务的对象。对开发来说，如何做；对boss来说怎么做。你都满足两个人的需求即可。摆摊卖东西不能越界。
大牛妈：界就是给自己画地为牢。之所以不同公司 SCM 做的事情不一样可能就是这个差别啦。
李晓琴：每个角色都有服务对象。请问公共组件为谁服务？负责人是否首先应该有责任和基本意识为自己的服务对象提供优质可靠的服务。依赖common的，有的开发也不要自己总是摆谱自己是大爷，就觉得人家这不好那不好。双方的自身问题往往是最终出现严重问题的源头。可是SCM被扯进去能做什么？ SCM该做的都做了，我们还能替她们决定什么吗？
huangshanzhi：还是公司一起做好版本规划比较好。版本火车很重要。
我的想法
每个公司都有自己的实际情况，有可能这里做的好点，那里却仍需要改善。有的做法可以直接拿来用，有的则未必。
小公司易规范
小公司或者小团队怎么整都是可以整明白的。可以用snapshot版本发布也可以用正式版本发布。这是因为：
- 公共组件组和业务线（产品线）关系很紧密，易沟通。
- 团队目标也趋于一致。更有甚者，公共组件组就是业务线（产品线）下面的一两个人在维护。平时写业务线（产品线）的业务逻辑代码，等到需要改一些基础公共组件的时候挽袖子又去改公共组件。
- 业务线急需公共组件的变更。这些公共组件的更新就是实际业务线（产品线）所需要的变更，甚至是业务线（产品线）推着公共组件去升级。
- 线上环境单一，易统一升级。正是因为公司小，团队小，所涉及的业务也不是很复杂，线上环境也很简单，统一成一个版本非常容易。
大公司挑战多
大公司则遇到的挑战则很多。
- 公共组件组和业务线（产品线）关系疏远。公共组件组也许就不是一个组织，而是很多人形成的一个虚拟组织;甚至都不是一个虚拟组织，而是分布在公司各个几角旮旯的很多人或者很多小组。这些人或者小组平时也没什么交流、没有发布计划，只是各自按照自己的节奏和需求方的需求迫切程度等各自进行着版本变更。再说业务线（产品线）这个就更复杂了，各个业务线（产品线）都有着不同的组织结构，甚至有的业务线（产品线）是独立核算的独立子公司，这些部门甚至和公共组件的维护者唯一的交集也就是pom.xm 中那么一个依赖声明了。
- 团队目标不一致，甚至是根本不一致。公共组件组是完善现有公共基础组件、同时发布更多、质量更高的公共组件；而业务线（产品线）所面临的业务压力则更大。简单的说，业务线（产品线）是有业务指标的，多长时间内多少功能要上线，UV和PV是多少都有着明确的数字可衡量。如果升级简单、易行，业务线（产品线）还是可以支持，如果有风险（我们知道公共组件的升级都是有风险的），他们则会相对更保守。
- 公共组件的变更未必都是业务线（产品线）所急需的。而且往往公共组件所涉及的功能很多，有的时候可能一次升级只是为了修复某个业务线（产品线）遇到的问题，其他的团队未必用到这个功能。就如老顽童所说，老版本很稳定、风险基本都知道，只要绕过了风险即可；升级新版本，谁知道都做了什么修改影响的范围有多大。改动小了，他们觉得没必要升；改动大了，他们觉得有风险不升级。升级公共组件就要做回归测试，甚至是全回归，时间和资源上未必都满足升级的条件。
- 线上环境复杂，统一升级困难，不可行。涉及那么广泛的公共组件肯定在很多线上服务器都跑着。有的服务很稳定，２－３年没新上线了也跑得好好的；有的业务最近发展很快，变更很频繁，一天多次上线也没问题。用正式版本，则线上服务器会保存着公共组件的N个正式版本，但至少你还知道他们用的是哪一个版本；用快照则问题更多，线上服务器跑着的都是相同标识的快照，但是md5又各不相同，这才是最要命的。
我们可以
事情这么难，我们可以做些什么？
- 公共组件组是公共组件正式版本升级计划的负责人。公共组件组应该去协调、推动这件事。公共组件组的职责不但要包括完成公共组件的维护，还要包括公共组件的推广。谁受益谁负责。受益最大的公共组件组应该来总体负责这件事。
- 既然是公共组件，那么它的使用范围必然很广，影响也很大。那么版本的升级应该趋于不频繁和通过正式版本升级。方便跟踪和识别。SCM和公共组件组应该合作把公共组件的版本发布情况、更新内容、时间等统计出来，并及时向使用到的业务线（产品线）做出提示。
- 既然是公共组件，线上肯定有多个正式版本（这是可以的）；但是一定要度，线上可以保留公共组件的几个最新正式版本，但是保留几个？保留多长时间？这些可以针对公司具体情况具体对待。SCM从中要有系统支持这些数据的获取和分析。
- 业务线（产品线）有自己的业务压力，无法时时刻刻保持使用最新正式版本的公共组件可以理解，但是应有自己的合理升级计划和安排。
- SCM不断优化自己的平台和反馈机制。把源代码、编译、提测、上线、线上等环节的信息及时、正确的展示出来，供决策者做出恰当的安排。比如线上公共组件的使用情况。包括线上公共组件有多少，每个的版本都是哪些，每个版本使用量有多大等等，这些都是最基本的。同时针对一些可能出现的问题，要有预案。比如上边诺亚之舟指出来的，出现了安全问题，这个时候我们要批量替换到一些 jar包。既然我们想到了这个问题，那我们就要想想万一这样的事情发生了，怎么去解决。
互联网第一定律：可能会出现问题的地方一定会出问题，而且很快就会出。我们可以思考一下目前的主要问题在哪里，针对自己的公司、项目选择适合自己的方式方法，推进工作。
小贴士
配置管理的工作很多时候面对的都是一些系统性的问题，指出问题来容易，解决问题难。
