jenkins简介
jenkins是一个可持续集成的开发工具，在自动化构建过程中可以给我们省下非常多的时间。所以，目前在我们的项目中需先对android项目和ios项目构建自动打包，后续可能服务端也会集成到jenkins上。jenkins相当于是一个构建服务器，它是依托在tomcat服务器上的。所以，我们只需要在本地访问jenkins服务器，并点击我们需要的打包操作，那么jenkins会自动执行配置和构建脚本进行打包。
jenkins相关工具开发
安装tomcat服务器
官网：http://tomcat.apache.org/download-90.cgi, tomcat是一个开源的web应用服务器，我们可以把它当成一个网站来对待，因为jenkins是放在tomcat服务器上的，所以我们必须在打包机器上安装tomcat，只需要在tomcat官网下载mac版本的最新版，并进行解压就行了，这里我们选择最新版的tomcat9，并下载安装包，mac下，我们可以选择zip压缩包或者tar.gz包下载，zip压缩包可以直接通过双击进行解压，tar.gz包需要通过终端命令tar -xzvf XXXX.tar.gz 进行解压
jenkins安装
官网：https://jenkins.io/download/ ,只需要安装jenkins.war文件，这个文件适配了所有底层系统平台。
.war文件封装了web应用模块，里面就包含了我们jenkins的页面信息。
此时我们需要将这个jenkins.war文件改名为ROOT.war，然后替换掉解压之后的tomcat服务器的webApp目录下的ROOT.war，这样下次我们访问tomcat就是读取了jenkins的页面文件了。
此时，我们需要开启tomcat服务器，当然需要通过命令来启动，关闭也一样,在tomcat解压文件的bin目录下，就是tomcat给我们提供的命令，在mac终端启动需要启动的是.sh后缀的命令，但我们第一次执行 sh startup.sh时，会报下面的错误：
这个是由于我们初始解压的状态下，我们并没有执行的权限，我们需要执行chmod 777 *.sh,就会将所有.sh结尾的文件权限都改成可执行的状态。
再次运行sh startup.sh，开启成功如下图所示：
jenkins服务器搭建
在打包机器上访问本机的8080端口，即localhost:8080，就会开始初始化jenkins服务器，当初始化完毕之后，jenkins服务器需要验证我们的账户信息：
我们只需要将提示路径下对应的initialAdminPassword内容复制到输入框就可以了。
然后继续进行一系列插件的初始化，初始化完毕之后就会进来jenkins主页。
jenkins打包项目创建
当我们进来jenkins主页的时候，当然我们还没任何可以打包的项目，我们需要点击左上角的新建按钮创建代码自动打包工程。
我们只需要输入工程名称，选择自由风格的打包风格即可。这样，主页面就会出现我们这个构建的打包工程。
在开始构建打包的前，我们必须首先在本地安装好git，因为jenkins在每一次构建打包时，通过git命令从gerrit仓库fetch拉取最新的入库代码进行打包，所以需要安装git。mac下的git好像不是自带的，需要我们自己进行安装。在这里我们先安装一个mac下非常好用的工具 Homebrew，它是mac下的一个命令行的辅助下载工具，亲测很好用。官网：https://brew.sh/，我们在终端执行下面的命令会自动给我们安装homebrew，并且进行配置 /usr/bin/ruby -e “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)”
brew的使用非常方便，对于下载一个工具，我们只需要类似这样的命令： brew intsall XXXX ，我们安装git只需要通过下面这一行命令：
brew install git，就可以开始下载了。
android打包
对于android项目的打包，我们需要在打包机器的本地安装编译所需的sdk，并且在jenkins上指明sdk的路径，在系统管理->系统设置->全局属性，添加上我们的sdk路径。
当我们构建了kkmh-android打包项目后，点击这个项目中的配置，就可以开始进行我们项目的配置了。
参数化构建
这个参数构建就是在我们选择打包时，可以提供给我们的一些选项，对于android，我们目前设置了打包分支和打包类型的选项：
所对应的打包时选择页面如下：
源码管理
配置该项目对应的gerrit仓库，当然也可以是svn或者git仓库
这个我们需要看看branches to build这个选项，这个是配置我们需要构建打包的分支，在我们打包时，会通过这个指定的分支拉取最新的代码并进行打包。我们在上一部设置了全局变量的choice，让我们在进行打包时选择了BUILDBRANCH的值，全局变量的值我们可以通过${XXXXX}进行读取。在这里我们先看jenkins自带的几个我们后面会用到的全局变量：
- BUILD_NUMBER 这次打包的number
- WORKSPACE jenkins创建项目的工作空间，一般来说是在jenkins目录的WorkSpace下
- BUILD_URL 对于每一次打包生成的路径
显示打包名称插件
enkins默认打包的显示的名称为#${BUILD_NUMBER},如果我们想要自定义这个名称的话，我们需要安装setBuildName插件，在系统管理->管理插件->可选插件中搜索set Build Name并进行安装，在配置中的构建环境中就会多出来一个setBuildName的选项：
gradle配置
它可以提供一些选项，通过对这些选项的配置，生成相应的打包操作脚本。在配置的构建中选择 invoke gradle script：
但是我们项目中没有通过这种方式，我们直接通过打包脚本去执行操作。其实打包android项目最主要的就下面的一句话而已：
./gradlew clean assembleDebug
但是我们想要对这个打包操作做更多的处理，所以我们需要将其封装成.sh的shell脚本，然后在构建选项选择excutor script：
去执行我们指定的脚本文件。
ios打包
关于ios打包，因为之前没接触过关于ios的任何构建，所以在构建遇到了各种各样的坑。
- ios的构建环境和android一致，设置可选择的打包分支和打包类型。
- 与android一致，设置buildName
- ios仓库设置也与android设置基本一致，只是代码仓库有进行修改而已。
- ios打包处理：ios打包也有相应的插件，安装了xcode插件之后，就构建选项中就会出现一个xcode选项
- 我们项目中也没用上这个插件，也是直接通过脚本设置。
对于ios命令打包，我们必须确认我们完成以下几点： - 在打包机器上安装了xcode环境
- 拥有对应ipa的生产证书和发布证书和provision，我们在打包命令中引用的这个provisioning file并不是这个文件的名称，而是这个文件中的uuid所对应值
对于ios打包，它分成了下面两个步骤
从源码生成app文件或者.archive文件
从app文件或者.archive文件导出.ipa文件
所以我们需要执行两个照着步骤执行两个命令：
{%codeblock%}
#.app生成，目前不用
xcodebuild -target $target_name -configuration $package_type -sdkcode_sign_identity PROVISIONING_PROFILE=$proversion_file
#xcrun打包，目前已废弃，若要使用，需要手动拷贝PackageVersion到新版本xcode，正因为这样，不采用.app的中间件生成方式打包
xcrun -sdk iphoneos PackageApplication -v $app_path -o $ipa_path
#生成.archive中间件
xcodebuild archive -archivePath $archive_path -scheme $scheme_name -configuration $package_type -sdkcode_sign_identity" PROVISIONING_PROFILE=“KaTeX parse error: Expected 'EOF', got '#' at position 17: …rovesion_file" #̲xcodebuild打包，其中…code_sign_identity” -archivePath $archive_path_dest -exportPath $ipa_path -exportOptionsPlist $plist_path
{%endcodeblock%}
在导出ipa文件时，我们需要一个plist文件，指定打包类型，和对应的teamId - 我们选择打app-store的包，并且指定对应的teamId，这个TeamId是我们的发布证书的id值
在ios打包需要额外做打包命令之外的一个操作，需要在打包前将preject.pbxproj文件中的Automatic设置为Matual属性，因为如果利用工具的话，它可以自动为我们指定，但是jenkins目前没发现指定的这个属性的地方，为了ios的本地编译的方便，只是打包脚本中做这个处理：
sed -i ‘’ ‘s/Automatic/Manual/g’ $project_file //利用sed替换字符串
蒲公英上传处理
当我们打完包，我们需要上传到某个地方以便测试进行下载或者渠道发布，这里，我们首先集成了蒲公英的上传处理。我们先看看蒲公英的app上传文档：
我们只需要在脚本中按照文档中所指定的上传命令就可以进行上传了，我们需要指定上传apk或者ipa文件，也需要指定在蒲公英上注册的userkey和apikey，不过我们想要显示二维码在每次上传完成之后都能够显示该次的build所生成的二维码，那么我们就需要去解析蒲公英平台的返回值。因为我们是用shell写的脚本而不是python，python自带json解析器，而shell没有，我们必须要在打包机器上下载一个开源的json解析器-----jq，官网：https://github.com/stedolan/jq ，
我们通过命令brew install jq进行下载，然后将jq命令复制到全局命令中：
我们先看看这个蒲公英的返回值：
在这一系列的返回值中，我们需要用到appKey和appQRcodeUrl，分别app的下载地址和二维码地址，在这里我们需要明确一点，每次返回的二维码是具有唯一性的，也就是每次上传之后返回的二维码是不一样的,appKey也是唯一性的，每次都指向该次生成的app,然而appShortcutUrl只是一个确定的短链接，每次都指向最新的一个apk文件,。所以我们需要在脚本中收集返回值appKey和appQRcodeUrl，以便我们用来显示在构建历史中。我们看看shell中关于这部分代码的处理：
构建后操作
当我们的apk和ipa文件打包完成之后，我们应该将每一次的生成文件和apk或.ipa文件收集起来。首先通过配置中的构建后操作选择archive the artifacts选项，添加我们要收集的文件
对应的显示页面如下：
这个构建产生的apk和二维码png都是存储在本地的。
现在需要做相应的二维码显示和下载地址链接，首先通过系统管理->插件管理->可选插件中搜索set build description插件，并进行安装。安装完成后，在构建后操作会多出这个选项，因为我们需要显示二维码和下载的超链接，所以我们需要利用html标签来进行显示，如下：
img图片显示引用我们存在本地的QRcord.png图片，href超链接指向蒲公英上该次build的下载地址。下面是jenkins打包生成的显示页面：
脚本
脚本后续再上传。可能每一个步骤的详细过程不是很详细。不过大概步骤就是这样。