使用Jenkins实现.net程序自动化编译系列--实践篇

    经过前面几篇文章，已经搭建好Jenkins、NuGetServer服务器，并完成了第一次自动构建，第一次包依赖上传、包依赖使用测试。

    接下来正式进入使用阶段，正如写一个Demo案例或原型实现起来简单快速，但距离产品级的的代码依然很遥远，使用自动化编译方案也是类似的，搭建好平台只是万里长征第一步，后面的路依然漫长，本文从实际使用出发，根据实际需求，逐步完善自动化编译方案，最终无缝融入到工作流程中，解决了长期以来的工作痛点：手动打包效率低，易出错，发布时间长，只有专业人员能实施，非专业人员无法参与。

 

    Jenkins使用背景：

    我司产品架构为微内核架构，又称插件式架构，其中插件管理部分，包括插件加载、启动、销毁、插件间通信、管理等与产品无关的功能，独立出来，成为一个单独的解决方案。业务组件作为插件在另一个解决方案中，这意味着，完成一次打包，需要：

• 编译两个解决方案
• 将编译好的两个解决方案整合到一起，组成一个完成的程序包。

    因此，首先要在Jenkins中配置两个项目，其一对应插件管理解决方案，其二对应业务组件解决方案。具体步骤参考安装篇中项目配置。

    这里不禁产生一个问题：Jenkins中的项目编译完生成位置在哪里？

    我们知道Jenkins编译项目时，首先从源码服务器指定路径下载代码到Jenkins所在机器，得先确定源码下载到了哪里？Jenkins会将源码下载到Jenkins.xml中配置的工作目录下，Jenkins.xml在Jenkins的安装目录下，可以修改该配置指定源码下载目录，修改该文件后需要重启Jenkins改动才能生效。

    在VS中编译一个解决方案，生成目录为对应项目配置好的目录，比如bin\Debug、bin\Release下，同样Jenkins编译生成的项目目录也是项目配置好的生成目录。由Jenkins源码下载目录，再加上项目编译生成目录，就可以确认Jenkins中配置的解决方案最终生成目录了。有了明确的生成目录就可以将两个解决方案编译后的文件合到一起，这里使用批处理文件复制命令xcopy，具体参考批处理复制。

 

    实际使用中我们产生了如下需求：

1. 如何恢复解决方案中项目的依赖包？
2. 将编译完的程序压缩为.zip格式的压缩包，便于传输
3. 将压缩好的程序包上传到指定服务器FTP目录中，便于软件工程师、测试工程师使用
4. 编译失败后通知给软件工程师，及时处理构建错误
5. 不仅仅使用时才能编译，希望每日都能自动编译，这样能确保每日都能检查构建是否成功，及时发现构建问题，保持敏捷性

 

    以下为对应需求的解决方案：

1. 下载安装Jenkins插件：Nuget，并在执行编译解决方案文件之前，执行批处理命令：nuget restore XXX.sln
2. 将文件压缩，安装winrar，由于winrar支持批处理压缩，因此可以使用winrar批处理压缩命令，使用Jenkins构建完成后执行即可
3. 上传压缩包到指定FTP目录，使用Jenkins插件：Publish over FTP，下载安装，并配置FTP账号，配置指定上传目录即可
4. 编译失败通知相关人员，这里使用Jenkins邮件通知插件：Mailer
5. 每日构建，Jenkins本身支持定时构建语法，在构建触发器中配置定时构建语法即可，如每天早上6点构建一次：0 6 * * *

 

     完成以上配置后，最终实现了一键编译源码打包，完整的工作流程是这样的：

     Jenkins就像一个指挥官，先从源代码管理服务器拉取最新代码，如果有引用的Nuget包依赖，则执行包依赖恢复批处理命令，从服务器中下载相关依赖，然后开始编译，编译完多个项目后，复制多个项目的编译文件成为一个完成的程序包，之后再次调用批处理命令，将该程序包压缩为指定格式的压缩包，然后上传压缩包到指定FTP，这个流程完全实现了流水化、规范反、工程化作业。一旦发生构建错误，邮件通知立刻将相关信息发送给指定人员。相关人员发现问题后快速排查构建失败的原因，修复问题，使构建流程重新恢复正常。由于每日构建每天触发整个打包构建流程，因此整个构建完全实现了自动化作业。