一种基于PLMS、SVN和Jenkins进行软件项目全生命周期管理
的方法
技术领域
[0001] 本
发明涉及软件项目管理、版本控制和版本集成发布技术领域，具体涉及一种基于PLMS作为触发源下发任务，引发SVN进行版本控制，再由Jenkins监测SVN更新进行自动集成、测试，最终发布
软件包的管理方法。
背景技术
[0002] 目前，有基于项目状态
跟踪管理工具结合配置管理工具使用来进行软件项目管理的方法；也有基于配置管理工具结合集成管理工具来进行软件自动集成的方法。这些方法都有一定的局限性，即未从全局的
角度来考虑软件项目的全生命周期管理，以致存在如下的问题：如果仅以项目状态跟踪管理工具和配置管理工具结合使用，那么在项目状态跟踪管理工具跟踪配置管理工具进行版本控制后没有最后一个环节产出最终的软件包；如果仅以配置管理工具和集成管理工具结合使用，那么缺少对任务以及
缺陷的登记和跟踪，后续的开发集成等动作都缺少触发源。因此，有必要将项目状态跟踪管理工具、配置管理工具和集成管理工具结合在一起进行软件项目的全生命周期管理。
发明内容
[0003] 本发明的目的在于提供
一种基于PLMS、SVN和Jenkins进行软件项目全生命周期管理的方法，对软件项目进行闭环管理，并防止在管理过程中某些环节管理缺失或问题跟踪丢失，确保在整个软件项目生命周期内，所有项目相关活动都是在可控可监测且在有反馈的状态下进行的。其中，PLMS是Project Lifecycle Management System的缩写，是使用ruby语言对开源软件Redmine进行二次开发产生，符合CMMI（Capability Maturity Model Integration，软件能
力成熟度集成模型），作为项目状态跟踪管理工具使用；SVN是 Subversion的简称，作为配置管理工具使用，对软件开发过程中的各个域的产物进行版本控制；Jenkins作为集成管理工具使用，对SVN变更进行监测，自动持续集成、测试和生成软件包以及相关测试报告。
[0004] 为了实现上述目的，本发明采用的技术方案为，一种基于PLMS、SVN和Jenkins进行软件项目全生命周期管理的方法，需要用到一种包括客户端和安装有PLMS、SVN及Jenkins的三台
服务器的全生命周期管理系统，所述客户端和服务器之间以及各服务器之间采用网络互联；
[0005] 所述PLMS服务器记录和跟踪项目状态、任务和缺陷等；
[0006] 所述SVN服务器以PLMS记录的条目为触发源进行开发维护，并在版本管控的同时主动关联PLMS的相关条目；
[0007] 所述Jenkins服务器全时监控SVN的更新状态，并按照配置信息定时自动提取版本、集成、测试和生成软件包以及相关测试报告；
[0008] 并且所述PLMS服务器反向根据Jenkins提供的报告
修改相关条目的状态。
[0009] 进一步地，上述方法具体包括如下步骤：
[0010] （1）a、项目立项的开发阶段，项目负责人在客户端将项目开发内容分割为若干个任务记录到PLMS中，在PLMS中再分配到相关子系统负责人，由子系统负责人
指定对应责任人（即对应的开发人员）；
[0011] b、项目开发阶段，项目的相关人员都能将发现的缺陷（Defect）、不符合项（NCs）以及客户的变更
请求作为条目记录到PLMS，并指派给项目负责人，由项目负责人直接指定对应责任人；
[0012] c、项目发布测试阶段，测试人员将发现的缺陷作为条目记录到PLMS，并指派给项目负责人，由项目负责人直接指定对应责任人；
[0013] （2）开发人员以PLMS中记录的条目作为触发源进行软件产品开发；
[0014] （3）开发人员完成阶段性开发后，将开发的包括文档、代码及报告等输出产物上传到SVN中进行版本控制，并在上传时，选择PLMS中对应的开发任务或缺陷的ID号作为上传comment的一部分；
[0015] （4）完成输出产物上传至SVN后，Jenkins根据自身的配置信息对SVN中相应的项目库进行监控，并调用配置信息中的相关脚本进行版本收集和/或版本编译；其中，在只是上传文档的情况，Jenkins不会进行版本编译；
[0016] （5）在具有版本编译的情况，若版本编译成功，则Jenkins根据配置信息进行下一步的自动测试，测试完成后生成测试报告；若版本编译不成功，则Jenkins将自动发送邮件给相关责任人，责任人修改完编译错误后继续从步骤（3）向下执行，直到编译成功；
[0017] （6）Jenkins完成自动测试后，继续调用脚本进行软件包生成，生成软件包后系统自动发送邮件通知项目相关人员；
[0018] （7）PLMS根据Jenkins提供的测试报告修改相关条目的状态。
[0019] 作为本发明的一种改进， 所述的软件项目是一个循环
叠加的动态实施过程，项目的产出是可以交付的产品。
[0020] 作为本发明的一种改进， 所述客户端和安装有PLMS、SVN和Jenkins的三台服务器之间采用局域网或虚拟专用网（VPN，Virtual Private Network）进行互联，三台服务器之间采用局域网进行互联。
[0021] 作为本发明的一种改进，所述PLMS服务器中记录的任务、缺陷及客户的变更请求等相关条目的处理阶段包括打开阶段、处理中阶段和关闭阶段，其中打开阶段包括新建状态、重新打开状态和延期解决状态，处理中阶段包括正在进行中状态，关闭阶段包括已解决状态和关闭状态。
[0022] 相对于
现有技术，本发明将PLMS作为项目状态跟踪管理工具、SVN作为配置管理工具以及Jenkins作为集成管理工具结合在一起使用，从而能够有效地对软件项目进行全方位全过程全生命周期的管理，确保项目开发的所有步骤、阶段都有据可依，有源可溯，进而实现项目数据的
可视化协同浏览，异地团队也可以参与评审，大大提高了软件项目的开发
质量和效率，提高了软件产品的竞争力；PLMS作为项目状态跟踪管理工具经过二次开发后更适合软件项目管理使用，能生成更加完善的报表，SVN作为配置管理工具能有效控制开发人员的权限，大大提升了数据安全，并能较好地对开发过程中的输出产物进行强有力管控，Jenkins作为集成管理工具大大减少配置管理员的工作量且有效避免人为引入的问题，使得整个软件编译、测试和生成报告的过程更加流畅。
附图说明
[0023] 图1为本发明由PLMS、SVN和Jenkins组成的全生命周期管理系统的结构示意图。
[0024] 图2为本发明的配置管理工具SVN的工作
流程图。
[0025] 图3为本发明的项目状态跟踪管理工具PLMS中条目状态流转后关系图。
[0026] 图4为本发明的集成管理工具Jenkins的工作流程图。
具体实施方式
[0027] 为了加深对本发明的理解和认识，下面结合附图对本发明作进一步描述和介绍。
[0028] 一种基于PLMS、SVN和Jenkins进行软件项目全生命周期管理的方法，所述的软件项目是一个循环叠加的动态实施过程，项目的产出是可以交付的产品。
[0029] 其中，PLMS是Project Lifecycle Management System的缩写，是使用ruby语言对开源软件Redmine进行二次开发产生，原本的Redmine只有简单的对issue（问题）和task（任务）进行常规的跟踪管理，通过开发添加了适用于对Defect（缺陷）、Task（任务）、Peer Review（同行评审）、Change Request（变更请求）和NCs（不符合项）跟踪标签的管理，并且增加了一些对于适合于公司组织架构的组和角色的权限控制，让其适合公司的开发流程以及符合CMMI（Capability Maturity Model Integration，软件能力成熟度集成模型）III的开发模型，作为跟踪项目状态工具使用。
[0030] 该方法需要用到如图1所示的全生命周期管理系统，包括多个客户端（Client或Slave）和安装有PLMS的服务器、安装有SVN的服务器以及安装有Jenkins的服务器，所述客户端与三台服务器之间采用局域网或虚拟专用网VPN进行互联，三台服务器之间采用局域网进行互联。所述PLMS服务器（PLMS Server）记录和跟踪项目状态、任务和缺陷等，所述SVN服务器（SVN Server）以PLMS记录的条目为触发源进行开发维护，并在版本管控的同时主动关联PLMS的相关条目；所述Jenkins服务器（Jenkins Server）全时监控SVN的更新状态，并按照自身的配置信息定时自动提取版本、集成、测试和生成软件包以及相关测试报告；并且所述PLMS服务器反向根据SVN和Jenkins提供的报告修改相关条目的状态。
[0031] 具体在图1中反映出来的三台服务器及客户端之间的关系如下：
[0032] 101：PLMS记录的条目作为触发源推动SVN进行版本更新；
[0033] 102：根据SVN中相关文件的上传版本内容更新PLMS中记录的相对应的任务、变更请求、同行评审或不符合项的状态；
[0034] 103：SVN配置库更新触发Jenkins服务器进行编译等工作；
[0035] 104：Jenkins将生成的产物上传到SVN服务器进行版本控制；
[0036] 105：根据Jenkins输出的测试结果更新PLMS相对应的缺陷或变更请求的状态；
[0037] 106：根据PLMS的任务触发Jenkins任务的新建和运行；
[0038] 107：客户端连接PLMS服务器，对项目状态进行跟踪处理；
[0039] 108：客户端连接SVN服务器，对项目的输出产物进行版本控制；
[0040] 109：客户端连接Jenkins服务器，查看或编辑项目持续集成配置、状态和结果。
[0041] 因此，上述方法具体可包括如下步骤：
[0042] （1）a、项目立项的开发阶段，项目负责人在客户端将项目开发内容分割为若干个任务记录到PLMS中，在PLMS中再分配到相关子系统负责人，由子系统负责人指定对应责任人；
[0043] b、项目开发阶段，项目相关人员都能将发现的缺陷作为条目记录到PLMS，并指派给项目负责人，由项目负责人直接指定对应责任人；
[0044] c、项目开发阶段，系统工程师（或项目管理工程师）将客户的变更请求作为条目记录到PLMS，并指派给项目负责人，由项目负责人直接指定对应责任人；
[0045] d、项目开发阶段，质量管理工程师将发现的不符合项作为条目记录到PLMS，并指派给项目负责人，由项目负责人直接指定对应责任人；
[0046] e、项目发布测试阶段，测试人员将发现的缺陷作为条目记录到PLMS，并指派给项目负责人，由项目负责人直接指定对应责任人；
[0047] （2）开发人员以PLMS中记录的条目作为触发源进行软件产品开发；
[0048] （3）开发人员完成阶段性开发后，将开发的包括文档、代码及报告等输出产物上传到SVN中进行版本控制，并在上传时，选择PLMS中对应的开发任务或缺陷的ID号作为上传comment的一部分；
[0049] （4）完成输出产物上传至SVN后，Jenkins根据自身的配置信息对SVN中相应的项目库进行监控，并调用配置信息中的相关脚本进行版本收集和/或版本编译；其中，在只是上传文档的情况，Jenkins不会进行版本编译；
[0050] （5）在具有版本编译的情况，若版本编译成功，则Jenkins根据配置信息进行下一步的自动测试，测试完成后生成测试报告；若版本编译不成功，则Jenkins将自动发送邮件给相关责任人，责任人修改完编译错误后继续从步骤（3）向下执行，直到编译成功；
[0051] （6）Jenkins完成自动测试后，继续调用脚本进行软件包生成，生成软件包后系统自动发送邮件通知项目相关人员；
[0052] （7）PLMS根据Jenkins提供的测试报告修改相关条目的状态。
[0053] 其中，所述PLMS服务器中记录的任务、缺陷及客户的变更请求等相关条目的状态包括打开状态、正在进行中状态和总关闭状态，其中打开状态包括新建状态、重新打开状态和延期解决状态，总关闭状态包括已解决状态和关闭状态。这几种状态间的切换关系如图3所示。由图3可知，将新记录到PLMS中的任务、缺陷或变更请求等条目的状态设为新建状态（New），对于处于新建状态的条目的状态可切换为延期解决状态（Deferred）、正在进行中状态（In Progress）或已解决状态（Resolved）；对于处于延期解决状态的且准备着手解决的条目的状态可设置为正在进行中状态，对于处于正在进行中状态的条目的状态可设置为延期解决状态或已解决状态；对于处于已解决状态的条目的状态可设置为关闭状态（Closed）或重新打开状态（Reopened），对于处于关闭状态的条目的状态可切换为重新打开状态，对于处于重新打开状态的条目的状态可切换为正在进行中状态或已解决状态。具体关系可表示如下：
[0054] 301：将新录入PLMS的任务、缺陷或变更请求等设置为延期解决状态；
[0055] 302：将延期解决的问题设置为正在进行中状态；
[0056] 303：将正在进行中的条目设置为延期解决状态；
[0057] 304：将新建状态的条目设置为已解决状态；
[0058] 305：将新建状态的条目设置为正在进行中状态；
[0059] 306：将重新打开的条目设置为正在进行中状态；
[0060] 307：将正在进行中的条目设置为已解决状态；
[0061] 308：将已解决的问题设置为重新打开状态；
[0062] 309：将重新打开的条目设置为已解决状态；
[0063] 310：将已关闭的问题设置为重新打开状态；
[0064] 311：将已解决的问题设置为关闭状态。
[0065] 在配置管理工具SVN中包含有项目库（Repository），SVN的工作流程如图2所示，具体如下：
[0066] 201：在客户端本地创建
工作空间（Working Copy）；
[0067] 202：更新当前工作空间；
[0068] 203：在最新的工作空间进行任务开发；
[0069] 204：开发过程中需要和项目库进行同步（Sync Repos）；
[0070] 205：完成开发后进行提交文档、代码及报告等输出产物，并判断是否有冲突（Conflict）发生冲突的情况是：多名开发人员同时开发同一文件，且上传前都没有将Working Copy和服务器进行同步更新；
[0071] 206：如果存在冲突，则需要先解决冲突，冲突解决后进入步骤209；
[0072] 207：如果不产生冲突，还需要判断是否有需要合并的内容（Merge），其中，此处的合并指的是对多个文件或一个文件的不同修改处的操作，如果需要选择性的上传就需要合并，如果全
覆盖上传就不需要合并，直接全部上传；
[0073] 208：如果有需要合并的内容，要先合并再进入步骤209；
[0074] 209：冲突已解决或内容已合并后，准备提交开发输出的产物；
[0075] 210：提交更新（即步骤209中的开发输出的产物）到项目库（Repository）。
[0076] 所述集成管理工具Jenkins主要包括持续集成服务器（Jenkins）和编译服务器（Build Server），该工具的工作流程如图4所示，具体如下：
[0077] 401：开发人员将更新（即开发输出的产物）提交到SVN上的项目库（Repository）；
[0078] 402：编译服务器接受项目库的变更；
[0079] 403：编译服务器将编译成功后的内容上传到项目库；
[0080] 404：编译服务器将编译报告返回给持续集成服务器；
[0081] 405：如果项目库有更新，持续集成服务器触发编译服务器进行相关任务的运行，如编译、测试、静态监测等；
[0082] 406：持续集成服务器对项目库的更新进行同行评审，同行评审时需要根据105流向PLMS新建同行评审条目，再继续按照相关流程执行；
[0083] 407：配置管理员对项目任务进行配置和控制；
[0084] 408：持续集成服务器发送集成状态报告以及相关测试报告（包括功能测试、性能测试QAC等）给配置管理员等。
[0085] 需要说明的是上述
实施例，并非用来限定本发明的保护范围，在上述技术方案的
基础上所作出的等同变换或替代均落入本发明
权利要求所保护的范围。
