继续😭
发布管理
其实虽然我们把发布管理和构建管理区分开，但是实际上发布管理和构建管理的边界已经不那么清晰了，因为随着发布过程对构建实际产生的可交付物的形态、结构、命名规范有着越来越高的要求，越来越细致的要求，两者已经紧密的联系在了一起。
甚至很多公司采用统一的构建、发布脚本。不同的项目传入的参数可能不同，但是最终打出来的包格式、结构、和命名趋于一致。做到这一点也为后面的部署管理打下了扎实的基础。
部署管理
敏捷上对“功能完成”有一个相当不错的定义就是功能交付，没有交付的功能是没有价值的。前边我们准备了那么多，做了那么多的工作，也就是为了最后能让实现的功能顺利发版、上线或者 RTM。保持一个稳定的发版节奏对于传统软件行业和互联网都很重要，因为涉及到诸多限制（后面会讲），传统软件行业不可能一天发布一个版本，但是传统软件行业也会有节奏的发布新品。最典型的就是每年的WWCD (苹果全球开发者大会)，期间苹果公司会向研发者们展示最新的软件和技术。最近 Google 和 Microsoft 也开始搞了。
部署管理重点不在技术难度，难在规模与速度。把一个软件安装到目标机上有什么难度吗？但是如果把一个 rom 安装到不同尺寸不同版本不同品牌的手机上就有难度；扔个 jar 包就能部署成功一个网站有啥难度？但是如果把jar 包扔上去的同时还能撑得起巨大的流量、数据不丢、系统不垮就有难度；上线不易，上了线发现有问题，能无损的回滚更不易。很多简单的问题一遇到大数据、大流量、大规模就会是另外一个样子。所以现在的互联网公司，比如传说中的 BAT，每家公司都造了无数的轮子来保证整个系统能正常、高效的运转。
无 CI 不 CD。没有 CI 做基础 CD 根本无从谈起。我们要能部署，还要能不断的部署。
部署的后续和上线紧密相关，一谈到上线自然躲不开 ops（那些老板、项目经理、QA、FE、RD 都一致把他们当做最可爱的人的人。）所以配置管理需要和运维人员紧密合作。
环境管理
说了这么多，不能不提环境。之所以最后谈到环境管理，一是为了前面五点一气呵成，从前到后有个连续的关系，二是环境管理太让人头疼，不想说。
我觉得之所以配置管理工程师给大家一个打杂的，不像研发人员的形象，主要是由于在环境管理方面，配置管理工程师牵扯的精力太多。
首先配置管理团队有各种各样的服务器需要去管理，svn/git/tfs/clearcase, maven nexus/artifactory, jira/redmine,其次还要提供、维护各种各样的开发环境、构建环境和运行时环境。这里的运行时环境还要分 rd 自测环境、QA 验证环境、预上线环境/stage 环境等
管理这些服务器软件的安装、升级，数据的备份、还原，还要负责各种疑难问题的解答，大到 GFW 何时升级，小到网线不通。
环境管理杂、真的很杂。你说有很大难度么，真的未必，但是每一点还都要照顾到。配置管理团队中除了自身都是准专业的运维之外，专业的运维人员真的很有必要。比如分布式存储，日志收集、服务器监控等等，很多更偏运维的工作在等着配置管理工程师去完成。
小结
上面里了啰嗦的嘚啵了六点配置管理的主要工作。其实配置管理工作不止这些，只不过这些更偏技术；很多偏管理、协调、质量、流程相关的工作都没有列出来。不过后面可能会总结一些。
下一篇讲讲传统软件企业中怎么做配置管理。
名词解释：
RTM：Release To Market
CI: Continous Integration,持续集成，有10个最佳实践，详情可搜下 Martain Fowler 的文章
CD：Continous Deployment，持续部署
ops: Operations, 运维人员
网友评论