实际开发中咱们须要对一些公共类库进行开发,并基于Jenkins进行CI/CD(CI:持续集成,CD:持续部署),其余项目经过NuGet引用。上文讲述了如何搭建本地NuGet服务器并发布NuGet包,这里再也不赘述。git
CI/CD流程以下图:
json
首先公共类库代码经过Git管理,编辑完代码后上传到Git服务器。安全
配置Jenkins Job,按设定的触发条件进行构建任务。bash
构建开始,删除Workspace中旧文件,从Git服务器下载最新代码,执行编译,生成NuGet包,上传到NuGet服务器。服务器
这样,别人就能够引用或者更新最新的公共类库的NuGet包进行业务开发了。并发
新建一个.net core 的类库,在工程文件处右键,选择属性,在“打包”中勾选“在版本中生成NuGet包”,而后设置基本信息。以下图:
visual-studio
编译生成,就会在Debug/Release目录生成一个nupkg文件:
测试
关于版本号:
这里指Net Framework风格的版本号,
即,主版本号.子版本号[.编译版本号[.修订版本号]]
英文对照:
Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Number]]
主版本号和次版本号是必选的;
编译版本号和修订号是可选的,可是若是定义了修订号部分,则编译版本号就是必选的。
全部定义的部分都必须是大于或等于 0 的整数。
应根据下面的约定使用这些部分:
Major :具备相同名称但不一样主版本号的程序集不可互换。例如,这适用于对产品的大量重写,这些重写使得没法实现向后兼容性。
Minor :若是两个程序集的名称和主版本号相同,而次版本号不一样,这指示显著加强,但照顾到了向后兼容性。例如,这适用于产品的修正版或彻底向后兼容的新版本。
Build :编译版本号(内部版本号)的不一样表示对相同源所做的从新编译。这适合于更改处理器、平台或编译器的状况。
Revision :名称、主版本号和次版本号都相同但修订号不一样的程序集应是彻底可互换的。这适用于修复之前发布的程序集中的安全漏洞。ui
在Visual Studio中选择NuGet包管理器,搜索“MSBump”,安装,而后在工程文件下新建一个.msbump文件,写入以下代码:spa
{ Configurations: { "Debug": { BumpLabel: "dev", LabelDigits: 4 }, "Release": { BumpRevision: true, ResetLabel: "dev" } } }
上文表示:当编译配置为“Debug”时,版本号生成一个dev前缀后面跟四位数字的标签,数字从0001开始递增。当编译配置为“Release”时,修订版本号会+1,清除dev标签。固然,也能够直接在.msbump中这样写:
{ BumpRevision: true }
意思就是每次编译无论debug仍是release,都会使修订版本号+1
前提操做:
须要下载NuGet.exe,而且把NuGet.exe所在目录和MSBuild所在目录加入到环境变量中,这样方便在Jenkins中直接使用msbuild和nuget命令。
这里再也不赘述,自行百度,就是安装Java那套环境
新建任务,起个名字,选择“构建一个自由风格的软件项目”,点击“OK”:
咱们用的是Git管理代码,因此源代码管理里选择Git,输入仓库地址和用户名密码,选择须要拉取的分支名称:
触发条件,能够根据本身的需求,好比每日定时调度:
编译环境中选择编译开始前清空Workspace,保证拉取最新代码不冲突:
编译步骤中,选择执行Windows批处理命令,主要执行以下操做:
1.进入工程文件目录
2.还原全部依赖的包
3.执行编译Release版本
4.进入Releas目录
5.将生成的nupkg文件推送到NuGet服务器
6.因为生成操做修改的修订版本号,因此将修改的文件提交
代码:
cd GAIA.GIS\ msbuild -t:restore msbuild /p:Configuration=Release cd bin\Release\ nuget push *.nupkg -Source http://192.168.1.209:1024/nuget iwehave2305! git commit -a -m updateversion
如图 :
建立编译后事件,将修改记录推送到git服务器,也能够加失败邮件通知等等操做:
保存
当即构建测试一下,大功告成~