持续集成 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系统中配置的,此坑填平,后者慎入。

持续集成 windows下jenkins常见问题填坑_第1张图片

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

持续集成 windows下jenkins常见问题填坑_第2张图片

 


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

持续集成 windows下jenkins常见问题填坑_第3张图片

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

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

持续集成 windows下jenkins常见问题填坑_第4张图片

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

<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动作来进行基于版本的即时构建。怎么办?这里可以使用一个取巧的办法

持续集成 windows下jenkins常见问题填坑_第5张图片

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


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

持续集成 windows下jenkins常见问题填坑_第6张图片

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

持续集成 windows下jenkins常见问题填坑_第7张图片

 

 

你可能感兴趣的:(windows)