持续集成学习笔记－入门篇（9）团队管理：成员&权限设置、成果追踪与结果通知

笔者认为，即便项目团队内只有一个人做开发，CI的支持作用也很大。何况实际工作是团队作战，哪怕这个团队只有3、5个人。此时，团队成员管理中的一部分工作就与持续集成挂上钩了。笔者目前能想到的主要有三方面工作：

l  成员及权限设置：项目成员的文档、源代码操作权限设置；内部网站上的成员信息展示

l  成果追踪：项目成员何时、提交了哪些源代码，这些工作应可以追踪到

l  结果通知：构建结果应能自动定位问题来源，并通知相关的项目成员

头一个方面实际上是后两个的前提。SVN、Jenkins、Maven site都或多或少地涉及到用户权限或信息设置问题。因此，第一个问题就产生出来了：应该在哪里设置用户权限？

理想状态下，当然希望能象商业软件（如Rational Rose）那样，只在一个地方设置用户信息和权限（开发权限、构建权限等），然后各类工具都可以自动获取信息。具体到笔者的学习过程中，实际上就是希望在SVN中设置好用户信息和权限，在Maven site中可以实时显示出来，并且Jenkins也能读取SVN的用户信息，从而直接针对用户设置构建权限。

但SVN、Jenkins、Maven毕竟是三个独立的工具，即便是号称整合了Jenkins的 uberSVN，也没法做到Jenkins和SVN共用同一套用户信息。不过，能用到CI服务器的CI管理员本来就比软件开发的成员数量要少很多，所以这里我们暂不用考虑CI服务器（Jenkins）的用户及权限设置问题，而只把精力集中到软件开发团队中的成员，这样就只涉及到SVN和maven两个了。

不幸的是，即便如此，用户的信息也要设置两遍（SVN、maven的pom.xml）。注意，这两遍中，成员的名字（name）一定要设置成一样，这样maven才能与SVN的用户联系对应起来。再通过一些插件（比如maven-changelog-plugin）的帮助，实现各工具的相互配合，从而完成上述三方面的工作。

 

一、设置成员信息和权限

（一）SVN的成员信息、开发权限设置

在一个非开源的商业软件开发工作中，需要给予不同成员不同开发权限，以保护公司的核心技术机密。

但是直接手工进行svnserve.conf、passwd、authz三个文件中的用户和权限设置很容易出错，而且就算按照官方文档指南步骤一步步来，往往也会发现权限设置无效。这主要是因为SVN的服务配置后面的原理比较多样和复杂导致的。笔者作为菜鸟，是通过VisualSVN Server的帮助进行SVN用户的管理和权限设置的。

首先在VisualSVN中设置一个仓库，笔者起名叫newdemo。设置这个仓库的过程参考下图，就不说具体过程了，真的很简单，读者自己尝试吧。

然后右键单击newdemo，选择Properties

至于后面的设置，就不用说了吧。笔者自己设置了zhangsan、lisi、wangwu三个用户。至于如何设置用户针对不同目录的读写权限，也很简单：就是在不同目录上单击右键，在选择Properties后出现的界面里，去设置不同用户的permissions。

连接newdemo仓库的url采用的是https://格式，为https://firstlevel/svn/newdemo/。其中，firstlevel是本机的计算机名称，随不同机子不同而变化。这个url可以通过“Copy URL to Clipboard”得到。

至于后续如何将自己的源代码提交到这个仓库，以及更新代码等就不细说了。

（二）maven的成员信息设置

项目开发网站的“项目团队”信息中，应该告诉团队：所有成员是谁，联系方式是什么。这需要在pom.xml中设置。在pom.xml中，我们加入了zhangsan、lisilisi两个成员。

注意：与上面的SVN中的用户设置对比，两者都有zhangsan用户。至于两者的联系结果，请看下一节《自动追踪成员提交成果的情况》

 

<project>

  ...

<developers>

    <developer>

        <id>dev001</id>

        <name>zhangsan</name>

        <email>[email protected]</email>

    </developer> 

        <developer>

        <id>dev002</id>

        <name>lisilisi</name>

        <email>[email protected]</email>

    </developer>  

<!-- Wangwu、zhaoliu的用户信息请自己添加吧，此处省略-->

 </developers>

...

</project>

 

执行 MVN site命令（或者通过Jenkins执行构建）后，我们可以在maven 生成的网站“项目团队”界面中看到成员的信息情况。

 

二、自动追踪成员提交成果的情况

    这个报告可能是公司老板最希望看到的东西，而程序员恐怕就不一定很乐意了，呵呵。在maven site里，可以自动生成版本控制系统变更记录文档：通过maven-changelog-plugin，实现自动跟踪成员提交源代码的情况。在pom.xml中的具体设置如下：

 

 <project>

  ...

  <!-- changelog报告的生成需要明确指明SCM来源。若无SCM设置，其它报告可以生成（因为Jenkins设置了源代码仓库所在位置），但changelog报告无法生成。-->  

 <scm>

     <connection>scm:svn: https://firstlevel/svn/newdemo/trunk</connection>

     <developerConnection> scm:svn: https://firstlevel/svn/newdemo/trunk</developerConnection>

</scm>

...

 <build>

    ...

          <plugins>

       ...

       <plugin>

              <groupId>org.apache.maven.plugins</groupId>

               <artifactId>maven-site-plugin</artifactId>

               <version>3.1</version>

          <configuration>

         <reportPlugins>

...

<!--生成版本控制系统变更记录文档-->

                <plugin>

                    <groupId>org.apache.maven.plugins</groupId>

                    <artifactId>maven-changelog-plugin</artifactId>

                    <version>2.2</version>  

                    <!--生成最近60天内的变更记录--->

                    <configuration>

                         <type>range</type>

                         <range>60</range>

                    </ configuration>              

                 </plugin>

...

</reportPlugins>

               </configuration>

             </plugin>

...

           </plugins>

...

         </build>

...

</project>

 

我们以用户zhangsan的身份向SVN仓库提交代码后，执行 MVN site命令（或者通过Jenkins执行构建）后，我们可以在maven 生成的网站项目报告中发现多了两个报告：Developer Activity和Change Log

点击Change Log，我们发现zhangsan的提交记录

仔细看一下，就会发现zhangsan是个超链接。点击一下，就到了“项目团队”的界面。类似的，打开Developer Activity，我们会看到不同开发者提交代码的数量总结。其中，zhangsan也是个超链接（因为只用zhangsan的名义提交了代码，所以其他用户的名字不会显示。）

这说明maven-changelog-plugin是从SVN中提取成员信息，如果maven中developer的name与SVN中的用户name一样，则maven会认为这两个是同一个人！所以可以通过超链的方式把SVN的用户与maven的用户连接在一起。我们在开篇提到用户设置时，就建议要将svn和maven的用户name设置成一样的，这样才能使两者对应联系起来。

如果读者有兴趣，可以尝试一下在pom.xml中，将developer的name设置成与SVN中的用户name完全不同，再看一下结果如何。

通过changelog报告，再与其它测试报告（比如surefire、findbugs）相结合，就能大致判断一个程序员的工作绩效：提交的代码数量越多（从覆盖功能的角度说）、速度越快，而相应代码出现的测试bug越少，自然工作效果越好。当然，要严格较起真来，你还得考虑这些功能的实现难度、代码编写的规范程度、重构情况等等。但与两眼一抹黑相比，总算是一个进步吧。关键的是：上面的工作结果可以定量化，以后程序员也有客观证据来证明自己的工作效果了。

 

三、通过邮件通知设置，自动地向成员发送构建结果信息

    当构建结束后，应该可以通过多种渠道（email、IM等）向团队成员通知构建结果。可以在pom.xml中进行通知设置（ciManagement的notifier设置），也可以通过Jenkis，在“构建后操作”的“Email Notification”中设置。这里只讲后一种。

1、  进入到jenkins->系统管理->系统设置，进行“邮件通知”各选项设置。这里的邮箱实际上是发送消息的邮箱。

 

2、在为newdemo设置的job里，选择“构建后操作”的“Email Notification”功能。在Recipients中填写收件邮箱地址，下方两个选项可以根据自己的需要进行选择。如果构建出现问题，则会自动发送邮件至Recipients中设置的邮箱地址。

 

目前正在研究如何将邮件自动通知到pom中设置的developer的邮箱中去，等有了结果再写篇博客吧。