持续集成 windows下jenkins常见问题填坑

【过程改进】持续集成 windows下jenkins常见问题填坑

没有什么高深的东西，1 2天的时间大多数人都能自己摸索出来，这里将自己遇到过的问题分享出来避免其他同学再一次挖坑.

---

目录

　　1. 主从节点

　　2. Nuget自动包还原

　　3. powershell部署

　　4. 内网机器实现基于变化的构建

　　5. Github私有项目pull时限

---

　　所谓主从，主要应用的场景例如多种环境（windows/linux，.net/java/php）需要不同的构建基础，而我们又不想都将一系列的步骤和环境混杂在一台构建服务器上，所以类似于go中的代理，jenkins也提供了slave节点的概念，大家可以把不同类别的项目的构建部署在分类的节点服务器上。节点服务器不需要安装完整的jenkins包，构建事件的分发由master端来执行。

这里需要注意的就是主从节点之间的通信，我这里选择是将从节点以windows service的方式启动，而我碰到的坑就是环境变量的配置问题，当我在主从服务都安装好jdk并且配置完环境变量后，发现启动从节点时还是怎么都找不到jdk，卡了半个小时才发现jenkins 从节点的环境变量是需要在web系统中配置的，此坑填平，后者慎入。

至于slave端的分配在构建配置中

---

　　用.net开发的同学nuget应该大多都涉及到，类似java的maven，神器之一，不多说。如果用visual studio开发这里会有一个选项

选中这里的话 会再在你rebuild项目的时候 自动将丢失的包补齐，当然仅限于公众平台上的内容，如果是同学们自己开发的local版本的包还会遇到另外的问题，这里我们重点不计较这些。

回到jenkins上来因为jenkins的构建条件中目前还不支持直接使用.net的ide，所以我们需要安装msbuild的插件

装完以后构建后发现编译失败，各种组件丢失。这里再填一坑，首先卸载我们的主要输出项目，然后编辑项目属性内容，在最后加上一个节点配置

<Target Name="AfterBuild">
    <MSBuild Condition="'$(Configuration)|$(Platform)' == 'Release|x86'" Projects="NuGet\NuGet.msbuild" />
  </Target>
  <Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />　　

　　还原项目，这样再使用msbuild命令就OK了。

---

　　powershell的使用场景可以这样理解，在我们build通过一个项目后，我们需要将他部署在一台测试服务器上，但是我们的数据库配置需要修改，如何去除人工的干预，这里就需要使用到powershell或者其他工具了。

powershell的使用你可以分为2种，一种是写好ps脚本然后通过batch command中powershell命令来完成，另外一种是jenkins直接安装powershell命令，这里更推荐后者，因为有些时候你并没有权限上服务器上修改脚本或者其他元素，所有后者更直观简单，简单的数据库连接修改脚本

$original_file = 'xx\web.config'
$destination_file =  'xx\web.config'
(Get-Content $original_file) | Foreach-Object {
    $_ -replace 'name="dbdemo" connectionstring=".+" ', 'name="dbdemo"  connectionString="server=(local);database=basedemo;user id=demoUser;password=!@#qqq" providerName="System.Data.SqlClient" '
} | Set-Content $destination_file -encoding UTF8

---

　　如果我们的master机器部署在内网，github通过hook的方式回调不到，那么我们就很难基于github项目的push动作来进行基于版本的即时构建。怎么办？这里可以使用一个取巧的办法

在poll scm模式下选择* * * * *，当系统发现本地文件没有变更时，会忽略掉此次构建。

---

　　github私有项目，主要也就是ssh授权的问题，这里的坑不是权限认证问题，而是github插件的时限问题，默认是10分钟，由于某些项目可能资源比较大，第一次pull的时候耗费时间比较长，但是控制台提示一直停留在认证那个阶段，让操作人员误以为是认证问题，这个估计也算个坑吧。填坑方法如下图：

ok 简单的填坑总结。有些问题虽然小但是一点一点排查总归还是浪费时间，希望对大家有帮助