前言

我最近参与的代码托管是使用SVN。感觉和我平时用的SVN有点不一样。我一直在构思和探索在PLM项目中使用版本管理软件来管理代码开发过程。我想借此机会详细总结一下。

问题

在PLM项目实施过程中，开发团队常常被诟病为小作坊，没有开发流程，没有代码版本管理，或者代码管理只是归档。

这是由于 PLM 项目的性质决定的。开发比例比较小，以辅助为主，二次开发居多。功能相对独立。我参与过的项目有一个开发工程师，同时兼任项目经理、业务顾问，实施的有小项目，也开发了十多个大项目。在大多数项目配置中，只有一两个开发人员，而且他们不一定在现场。因此，开发过程中并不迫切需要代码管理和开发流程规范。他们往往是在后期的项目上线和运维升级过程中，才暴露出不规范代码版本管理和开发流程的弊端，比如以下情况：

1. 代码冲突

当多人并行开发组合包时，库文件版本、工具类等会发生冲突。

2. 代码冗余

原本各自维护的项目和工具类，最终合并时，工具类中有很多重复的类似方法。然而，它已经处于后期阶段，他们不愿意花费额外的时间进行代码重构、集成和重新测试。

3.版本难以追溯

例如，如果没有代码和变更记录的物理备份，代码回滚将非常困难。有的客户遇到了只能在企业内网上写代码，而且内网上没有版本管理软件。在维护期间，为了避免代码版本出现问题，我给开发团队采用了物理代码备份的开发流程规范。修改代码前，对最新的代码进行备份，并在记录文件中记录签到的人、时间及原因。以及更改的代码文件的列表。为了避免出现问题，大家都尽量避免再次检查和修改未检查的代码。幸运的是，协同开发和运营的场景相对较少，并且团队严格遵守这个流程，没有出现过这样的问题。代码版本问题。

4.生产环境和代码不匹配

因为没有开发流程，随着上线后的运维和人员流动和交接，最终的结果往往是最新的代码与生产环境的部署包不匹配。 Java 代码还可以被反编译以生成生产代码以匹配最新代码。相比之下，C代码就更难了。只能通过重新开发梳理功能来恢复代码，这给运维和升级带来了额外的工作量和风险。

5. 代码丢失的风险

如果没有良好的代码本地和异地备份机制，辛苦编写的代码可能会意外丢失。有过磁盘或者虚拟机损坏经历的同学一定有同感。

解决

通常我们在实施项目时，需要帮助客户梳理业务流程，然后在PLM软件上实施。其实我们的开发团队也需要根据情况梳理出一个开发流程，然后在svn或者git等版本控制软件上实现。

我的团队使用svn，学习成本相对较低。使用svn的4年时间里，我们在svn上共管理了26个客户的37个大大小小的项目代码。我们不断总结实践，总结基于svn的PLM。项目特性开发流程（svn中的相关概念请参考“关于svn”章节）。我们使用的开发流程和规则（图1，后面的“项目案例”章节会结合这个开发流程来介绍我在上汽大通项目的PLM项目的开发和运维过程中的实际案例）：

1.：，用于维护代码与生产环境一致

2.：分支，开发时每个项目对应一个分支

3.tags：标签，快照，每个项目最终部署上线后，代码（基于主干合并分支后的代码）对应一个标签

4、项目及日常bug修复开发流程如下：

4.1.开发管理器是基于当前创建的

4.2.分配开发工程师和权限，并通知开发工程师

4.3.开发工程师会在当地考察进行开发

4.4.开发工程师定期将代码同步到本地电脑（一般在每天工作开始时），并定期提交代码到本地电脑（当代码达到一定成熟度时，建议每天下班后） ）

4.5.开发经理定期同步最新代码（一般是在其他项目上线或者运维bug修复上线之后）

4.6.功能测试时根据代码进行编译和发布

4.7.当最终功能上线时，开发经理\开发工程师合并代码，编译快速测试，发布标签

5、应急修复开发流程如下：

其他步骤和项目与常规错误修复相同。不同之处在于不需要创建它。可以直接查看本地修复bug。测试通过后，可以直接提交发布。

图1：基于svn的PLM项目开发流程

关于svn

svn有一个非常标准的目录结构，就是这样的。例如，如果项目是proj，svn地址是svn://proj/，那么标准的svn布局是：

图2：标记的svn的目录结构

这是标准布局，主开发目录，分支开发目录，tags为标签归档目录（不允许修改）。不过svn对于这些目录应该如何使用并没有明确的规范，更多的是根据用户自己的习惯。

svn中各个目录的含义

：，如果把一个软件项目从开始到消亡比作一个故事的话，主要情节都是svn记录在这里的。

：分支有很多用途，比如：版本发布维护分支，新功能开发分支，甚至缺陷修复分支等。

Tags：标签，或者说快照，当某个版本发布时，会存档在这里。

示例如图：

图3：标准svn目录结构

使用svn的开发过程可以分为集中式和分散式两种：

集中化：进行重大开发

一般来说，我们一切的发展都是以发展为基础的。当一个版本/开发结束时（开发、测试、文档、制作安装程序、打包等），代码处于冻结状态（人为规定，可以通过钩子来完成）。管理）。此时，应该基于当前冻结的代码库来创建标签。当下一版本/阶段的开发任务开始时，开发继续进行。

这时，如果发现之前发布的版本（ ）有一些bug或者有一些紧急的功能需求，而正在开发的版本（ ）无法满足时间要求，那么就需要对之前的版本进行修改。开发时应根据版本对应的tag制作相应的()。

这是一个非常标准的开发模式，很多公司都采用这种模式进行开发。始终是开发的主目录。

去中心化：主要开发分支

在这种开发模式下，它不承担具体的开发任务，而主要负责版本发布。在版本/阶段开发任务开始时，会在现有版本的基础上创建新的开发分支，并基于该分支进行开发。

这实际上是一种去中心化的开发。当各个部分相对独立（功能）时，可以打开多个dev分支进行开发，这样每个人/组就不会互相影响。比如.和.等等.但这是一件非常痛苦的事情。

因此，如果你在组合包时有选择性，可以在2.0开发完成后，将.0（使用）和.0（新版本开发）一起返回。或者先把.0改成.0，测试一下，然后返回。

两种方法都有各自的优点和缺点。第一种方法可以获得相对纯净的开发分支，而第二种方法则更安全，因为它需要测试。

当多人协作时，分包是最常见的问题。严重时甚至会导致代码覆盖、回滚。原因是分支管理器创建分支后不再从主干拉回数据或者拉回数据需要很长时间，导致最终合并。当返回主干时，分支的文件甚至结构都与主干有较大差异，造成更多的冲突。需要人工操作，浪费大量时间。

针对这个问题，有没有一种解决方案可以在提交分支时检测分支最后合并的版本是否与主干版本匹配？如果不匹配，就不允许提交，迫使大家养成从主干拉取数据的习惯？如果可以实现这一点，那么当分支合并回主干时，冲突实际上就会消除。

两种方法的优缺点

第一种开发模式（进行主体开发，集中式）：

优点：管理简单。

缺点：当需要开发的模块较多、开发人员/团队较小时，很容易发生冲突，影响对方的开发。因为所有的改变都可能触动对方的改变。

第二种开发模式（分支为主开发，分散式）：

优点：各自独立开发，不易互相影响。

缺点：管理复杂，承包时麻烦，容易死亡。

工程案例

接下来我会结合一个比较复杂的项目场景来介绍一下实际的开发流程。本案例时间跨度约一年，加上日常的系统运维，可视为同一客户7个项目的并行开发。作为一名开发经理，我借用上面总结的PLM项目中的开发流程，避免了很多陷阱。

首先介绍一下案例情况。客户是上汽大通。该工程主线由0.3升级为0.3。升级过程中，并行开发了6个项目，共投入了9名开发工程师。角色和项目状态如图4所示。从表中可以看出，其中5个是多个开发协作项目，其中4个无法使用svn来管理其所有代码，因为部分开发没有使用svn ，这会造成额外的代码比较和合并工作量。

图4：开发、角色、是否使用版本管理软件和项目矩阵

本例我使用的开发流程如下，主要添加不使用svn开发的代码处理：

1.：，用于维护代码与生产环境一致

2.：分支，开发时每个项目对应一个分支

3.tags：标签，快照，每个项目最终部署上线后，代码（基于主干合并分支后的代码）对应一个标签

4、项目及日常bug修复开发流程如下：

4.1.开发管理器是基于当前创建的

4.2.分配开发工程师和权限，并通知开发工程师

4.3 开发工程师在本地检查进行开发

4.4.对于不使用svn的开发，开发经理需要下载最新的代码并离线发送。

4.5.开发工程师定期将代码同步到本地电脑（一般是每天工作开始时）并定期提交代码到本地电脑（当代码达到一定成熟度时，建议每天下班后进行）

4.6.对于不使用svn的开发，开发经理需要定期接收代码和代码进行离线比对，与开发人员确定修改内容后再合并到

4.7.开发经理定期同步最新代码（一般是在其他项目上线或者运维bug修复上线之后）

4.8.功能测试时根据代码进行编译和发布

4.9.当最终功能上线时，开发经理\开发工程师合并代码，编译快速测试，发布标签

5、应急修复开发流程如下：

其他步骤与项目的常规错误修复相同。不同之处在于不需要创建它。可以直接在本地查看修复bug，测试通过后直接提交。

使用这种开发流程后，虽然每次合包的时候开发经理都要比较代码很麻烦，但好在稳定可靠，没有出现重大的代码版本错误。也通过日常编码避免了意外（没有使用svn代码） 后来我开始使用svn进行开发。我在提交代码之前没有同步最新的代码，导致本地旧代码被提交到网上。）我在日常编码的过程中及时发现了代码撤回的情况。

总结

总体而言，对 PLM 项目代码使用版本管理利大于弊。如果您的开发团队不使用它，强烈推荐它。