代码合并 or 功能升级？
最近NeXT主题发布了v5.1.0版本，有很多新特性优化，我的博客随着流量的增长，性能和使用优化问题凸显，新老版本代码对比有许多的差异，根据以前多次折腾的经验，这一次不能再鲁莽的直接更新了，出了问题严重影响用户体验还有宕机风险。
过程分析
工作环境的参考
SAP的经典环境是开发（D系统）、测试（Q系统）、生产（P系统）三套环境，有的土豪公司还会有预生产环境，保持和生产环境的设置、数据一致性。现在的工作中开发全流程也是开发、测试、生产三套环境，如果加上开发人员的本地环境一般会有四套环境。在本地环境做完相应的功能开发后上传到开发环境，不同的开发人员还可以直接通过项目组的开发环境获得最新的代码。开发进行自测，完成后进入测试环境提交专门测试人员测试。完成测试和联调等一些列工作后通过投产进入生产环境正式使用。一旦发现严重问题，生产环境回滚，在开发或测试环境下查找错误并及时纠正。
代码合并的工作只会出现在最后一步投产之前，由开发人员自己进行代码合并，优势是对于变动的内容熟悉，合并效率高，出错率相对较低。而SAP对代码做了封装，以类似于数据包的形式进行环境间的内容传输，效果更好，出错率更低。
博客环境的不同
我们的博客是否可以采用这样的策略呢，先来看看相似的地方，博客的一套环境可以分为三个部分：
- 源代码：博客模版本身的代码，如果源代码没有修改过，是可以考虑直接替换的部分。
- 配置和代码修改：基于个人的需求，经常会在源代码的基础上做配置，甚至直接修改源文件，这部分是修改的最核心内容，影响到功能和用户体验。有可能一些代码修改实现的功能在新版本里已经默认实现了，这一部分会导致冗余，需要比较小心。
- 博文、页面、草稿：这部分内容相对独立，处理起来比较容易，但是也要注意数据的存储位置，防止内容丢失。
不同点呢，首先代码不是自己开发，所以即使是直接进行代码合并，也很有可能会绕弯路。另外，代码合并的量比较大，一个博客修改174个文件，也的确是很麻烦。而且，自己还不是专业的程序猿，中间出现问题调整容易陷入技术黑洞。
所以这个过程并不是经典的开发过程，更像是基于产品的版本过程。需要调用的是自己以前版本升级的经验。
版本升级参考
和开发合并代码不同，版本升级优先考虑的是功能是否保留完整。整个过程大致分为如下几个阶段：
- 梳理现有的功能清单。（博客可能还要梳理现在的实现方式）
- 代码升级：实际工作中根据情况有两种方案，如果原有的改动不大，直接升级标准产品，基于标准产品的功能再做实现。如果原有的改动非常大，先做代码合并，再进行功能验证和二次开发。（博客考虑先不做代码合并，直接部署新版本）
- 功能验证和二次开发：确保所有的功能可以正常使用。
博客升级实现方案
实现步骤
所以此次博客升级的实现方案有以下几个步骤：
- 部署测试环境为最新版本环境v5.1.0，并进行数据的迁移，保证两边的数据一致性。
- 现在的生产环境和最新的标准环境间进行功能比对，找出需要优化配置的功能点，梳理出清单和实现方式。
- 在测试环境基于v5.1.0进行功能优化。
- 直接将测试环境的代码作为生产环境代码部署。
注意点
- 测试环境是带有数据的，所以节省了后续数据的迁移。如果调整的时间周期比较长还可能出现数据不同步的情况，可能还要再做一次数据同步。
- 测试环境也是包括本地部署和远程部署的。
- 如果时间周期较长，可以把测试环境的远程部署设置为爬虫不可见。
后续的版本管理
并不需要长期保留测试环境的远程部署，大版本升级后的小修改直接做本地数据备份后调试本地环境，没问题远程部署即可。一旦有大的版本升级，可以参考该博客的策略执行。
分布式管理在哪里？
通篇的内容分析是基于我在企业信息化实际工作中的经验总结。这里有一个核心是：这是一次基于开发的代码合并还是基于功能的产品升级的问题。虽然是企业信息化经验，也并没有涉及到SVN的集中式版本管理要求，所以不牵扯分布式版本管理也是正常的。本来博客的升级就是一个人的事情，并不涉及协同，而自己又不是专业的开发出身，未使用分布式版本管理和代码合并也是正常的。
和这种大版本升级比起来，代码管理（无论是分布式还是集中式）都更适合用在开发过程里，由开发人员进行过程控制，在不断的小功能优化或者是自己的一套开发过程中使用更能体现出威力吧。
PS：这一次的梳理完全是意识流状态，因为想升级，没有闹明白，索性写一写，梳理思路，最后的收获不仅仅是思路，更是搞明白了版本管理到底要用在什么地方，纠正了我的一个认知偏差，分布式版本管理大法好，哪里都可以用的偏差。
完
声明: 本文转载需标明出处，禁止用于商业目的。
ChangeLog
170311 新建