不过，这种情况似乎更多发生在软件开发领域。这里分享一个有意思的真实案例，为了避嫌，略去时间、地点等关键信息，笔者曾经见过一个规模达到2亿的大型咨询项目，仅仅是由几个初入职场的新人来通过FTP管理项目上产生的大量文档、源代码等交付物，其管理效率之低下令人感叹，而在当时，CVS、SVN这样开源免费的版本控制工具早就已经面世多年。这次经历，真的给笔者带来了巨大的精神冲击，其项目规模之大、管理手段之低下，形成了巨大的反差，时常让笔者反思为什么会出现这种“春风不度玉门关”的现象？有了这次经历，后来我从电信、金融再去转战汽车、医疗设备等制造行业时，对于所出现的变化就有了比较好的“铺垫”了~

2007、2008年前后，敏捷方法论逐渐登场，并渐次发展为主流，这主要归因于外部市场环境发生了剧烈的变化，传统的瀑布、长周期交付模式，逐渐被敏捷、端到端的短迭代模式所取代，由此也给软件配置管理带来了相应的变化，持续集成、持续交付成为软件配置管理领域新的热点，因此，IBM Rational收购了BuildForge、Borland收购了Gauntlet，在开源领域，Jenkins（前身为Hudson）则成为当红炸子鸡。大量的Devops工程师开始出现，Devops发展大热，攻城略地，不再局限于持续集成和持续交付领域，而是扩展到整个生命周期，以互联网行业尤甚。

这种变化同时也带来了一个副作用，那就是似乎我们“丢掉”了软件配置管理的核心，今天我们再去招聘网站，已经难以找到一个理论功底扎实的经典配置管理工程师了，大家摇身一变改名为Devops工程师了，但就狭义的Devops来说，必须要建立在稳健的配置管理基础之上。

时代在变化，我们越来越强调全生命周期、一体化的研发管理，越来越强调工程效率自动化，甚至连人工智能在软件工程领域的应用也初现端倪，但这些愈发凸显经典软件配置管理的核心基础作用，合理的版本规划、合理的分支结构、与流程更紧密更自动化的结合、更强大的自动化等等，才能帮助我们应对越来越复杂的产品研发场景：如何搭建合理的仓库结构，以支持从项目型开发到产品型的开发？如何实现基于组件的复用？如何实现基于平台的复用？如何实现软件BOM？如何管理产品从创建到维护退出市场这一可能长达10多年的生命周期？如何对接OTA？如何实现对Docker的版本控制？…

这些是摆在今天每一个追求卓越软件配置管理的工程师面前的课题，要实现良好的软件配置管理，对人员的能力要求非常之高，良好的规划能力，与软件架构师的对话能力以实现架构解耦以便实现更合理的分支，自动化工程实现能力，对标准（CMMI、ASPICE）等的理解能力，注定了软件配置管理工程师是一个复合能力要求极高的职位。

感到自豪的是，这么多年以来，通过Teamlive团队的持续努力，我们将这些理念灌注于Polarion平台，落地实现了一些软件配置管理的理念：我们实现了SVN、Git、Perforce、PlasticSCM等和Polarion的集成，以达到开发活动与开发资产的一致性管理；我们实现了内置的代码评审；我们研发了针对SVN的集中式权限管理产品AthenaSVN（http://marketplace.teamlive.com.cn/htmls/AthenaSVN/product_detail.html），以满足软件配置管理理论中对于控制的要求（标识、控制、审计、报告是配置管理的核心四要素）；我们研发了Polarion与Jenkins的连接器，以实现持续集成（http://marketplace.teamlive.com.cn/htmls/JenKins/product_detail.html）；我们研发了QA Hub，以便以开箱即用的方式来打通各种编译、代码静态分析与自动化测试工具链（http://www.teamlive.com.cn/company/events/20200428-polarion-webinar.html）...

前路漫漫，但我相信，只要我们多多思考、多深入一线、多参与社群，就会实现软件配置管理领域的更辉煌明天，由此与有志于从事软件配置管理工作的诸君共勉。