Jenkins搭建.NET自动编译测试并实现半增量部署

@hzl201 2020-04-13 09:26 字数 18724 阅读 3353

Jenkins搭建.NET自动编译测试并实现半增量部署

运维 jenkins

前言

以前写前端项目打包部署，都是手动运行命令，打包完，然后压缩，再上传到服务器解压。 这种方式确实有点low并且效率也不高。
自从用了Jenkins持续集成工具，写前端项目越来越工程化，再也不用担心忘记部署项目，也不用烦躁每次打包压缩后还要部署多个服务器和环境，更开心的是每次家里写完代码，不用远程公司部署项目，提交代码后自动会为你部署。
本文基于.NET4.0的web项目和SVN的代码仓库以及Windows(其他系统平台大同小异)，简述Jenkins实现自动部署的配置。

1项目开发与持续优化

1.1持续部署

有时候开发人员在更新代码时在本地测试是正常的，但放在服务器上运行就会出问题。只有在生产环境下能正常跑起来的代码才算合格，关注点在于项目功能部署至服务器后可以运行。
引用一些名词解释：

部署（deployment）还是发布（release）？部署一般指把应用或者服务“安装”到目标环境（开发、测试或者生产）中，而发布则应指把应用或者服务交付给最终用户使用。尽管这两个动作（尤其是在生产环境中）经常是同时发生的，但它们理应是两个完全不同的阶段。实际上一个好的持续交付流程恰恰应该把“部署”和“发布”解耦，变成两个可以独立控制的阶段。
部署的内容包括什么？无论是增量部署还是全量部署，都需要关注其部署的内容是什么，尤其是在广泛讨论微服务的今天。如果从部署角度看，我们把任何可以独立部署的内容称为一个“部署单元”。一个部署单元可以是一个模块，几个模块的联合体或者一个完整的应用，而如何划分则要视具体场景来定。一般来说，划分部署单元的最佳实践为一个可以独立演化、部署且和应用其他部分松耦合的集合。

（1）全量部署 full
全部文件重新拷贝并覆盖。优点稳定性好，但对带宽的要求大，更新时间长。
（2）增量部署 min
更新上个版本与最新版本之间的文件。优点速度快，对带宽的要求小，更新时间短，但若更新失败，则需要全量更新覆盖一次。
引用增量部署的优势：

部署速度快。增量部署每次仅对增量部分进行更新，无论是文件分发还是配置更新的内容都会更少，部署需要的时间也就相对较短。
减少变化量。增量部署可以减少对于整个系统的变化幅度，很多已经完成的配置工作不需要每次重复设置。从而可以避免误操作，降低部署失败率。
提高安全性。增量部署每次只会涉及到增量代码部分，不会直接暴露系统的整个代码部分更新，避免系统代码泄露的风险。

但增量部署也有缺点：

增量部署对于任何部署外的更新非常敏感，降低了部署流程的可预期性。在日常工作中经常会出现为修复一个问题而临时修改运行环境的部署外更新，一旦这些部署外更新未及时考虑到增量计算中，非常容易导致之后的增量部署失败。全量部署过程则会完整执行完整个环境的配置、初始化以及部署工作，对于这些部署外更新有更好的容错性。
增量部署让回滚操作变得非常不容易。每次回滚都需要逆向计算增量部分，然后做回滚操作。及时的备份策略有机会降低这个难道，但是如果需要回滚多个版本仍然是一个巨大的挑战。
增量部署无法直接满足从头部署最新系统的日常需求。在云环境中资源的动态变化（尤其是虚机的增加和减少）逐渐会成为一个常态，用户时刻都可能面对两种场景的部署要求：从上个版本升级到最新版本，或者从零重新部署最新版本应用。显然，这两种部署需求一个增量更新，另一个则是全量更新。

（3）半增量部署 semi-increment
只更新近期有更改的文件。保存一个时间范围内的更新文件，最长一个月，集合了全量部署与增量部署的优点。压缩包小，对带宽的要求小，更新时间短，容错率高，可以实现一个月内的增量更新。
但同时也有缺点：
无法完成初始化的部署操作，若已部署过的系统，但不知道部署时的版本号，只能先进行一次全量部署，而且若因为网络原因导致部署失败，则没有提示，需要人工操作进行判断。

1.2持续集成(Continous Intergration)

一个大项目是由多个模块组成的，每一个模块都有具体的小组负责开发，但有时候本模块独立测试正常，但与其他模块一起集成测试就会出问题。需要经常把所有模块集成在一起进行测试，尽早发现问题。关注点在于尽早发现项目整体运行问题，尽早解决。

1.3持续交付(Continous Delievery)

用小版本不断进行快速迭代，不断收集用户反馈信息，用最快的速度改进优化。关注点在于研发团队的最新代码能够尽快让最终用户体验到。

1.4当前现状分析

（1）开发人员少且项目工期紧
开发人员时间、地点不固定，每天还要进行旧模块的修改和新功能的提交，每个开发人员的时间都很宝贵。
（2）项目后期维护人员少但项目多
运维人员每天除了要处理现场工作，还要协助开发人员调试新功能，人员相对较少，但工作量大。
（3）客户的需求一变再变
功能需求是在项目进展过程中持续变化的，在使用中会不断有新的需求出现，这是不可避免的，唯一确定的是需求是持续变化的。只能建立统一的文档，平时由运维人员收集修改建议，论证后再录入待办任务，由部门领导安排优先级，设置好交付时间，具体责任到开发人员进行修改。
（4）传统的运维方式费时费力
每个人更新代码的经验不一样，开发人员对自己的代码比较了解，有时只需替换近期修改的文件即可，但大部分运维人员的开发水平相对较弱，只能全部进行文件的复制替换，不仅费时费力，而且容易出错，遇到网络和服务器的原因还容易导致更新失败。

1.5自动化增量部署的优势

（1）降低风险
代码有更新后会第一时间在生产环境进行多次测试，降低代码错误导致的问题。有时候代码在开发人员本地的测试环境是没问题的，但生产环境与测试环境有可能不一样，只有通过生产环境的检验才能证明代码质量合格。
（2）减少重复劳动
每次更新时，编译、测试、打包、部署的操作都要重新进行一遍，让正常人做重复的事情，估计重复三次就不想再继续了。增量部署可以只更新增量的文件，相对全量部署能节约时间。按一个节点10分钟全量部署计算，提交一次代码就要部署一次，假如每天有10个节点，就是100分钟，这些还没算上更新失败的次数。而增量部署只需要1分钟1个节点。增量部署有以下几个优势：
部署速度快。增量部署每次仅对增量部分进行更新，无论是文件分发还是配置更新的内容都会更少，部署需要的时间也就相对较短。
减少变化量。增量部署可以减少对于整个系统的变化幅度，很多已经完成的配置工作不需要每次重复设置。从而可以避免误操作，降低部署失败率。
提高安全性。增量部署每次只会涉及到增量代码部分，不会直接暴露系统的整个代码，避免系统代码泄露的风险。
（3）快速部署
部署首先要保证稳定，再谈速度。简单来说自动部署就是把人工需要做的操作一步一步写下来，具体到每一步操作什么内容，再编写出部署脚本，期间有可能会出现各种干扰情况，需要先判断是否具备部署条件再进行部署。部署时会执行命令实现快速更新，下载更新包会受网络影响，时间不固定，但下载到本地后执行更新是瞬间的事情。增量部署能自动判断哪些节点需要更新，自动判断需要更新哪些文件。通过经常对代码进行小改动，从而避免整个系统出现大问题。
（4）增强项目的可见性
持续集成让我们能够注意到趋势并进行有效的决策。持续集成系统为项目构建状态和品质指标提供了及时的信息，并可以统计哪些模块的代码质量一般。
（5）建立团队对开发产品的信心
可以让开发人员清楚的知道每次构建的结果，从而得出他们对软件的改动造成了哪些影响。

2持续部署系统

视频操作演示：
Jenkins搭建.NET自动编译测试并实现半增量部署_哔哩哔哩_bilibili

2.1分析

手动的方法就不说了，曾经作为新手的我1小时才更新了四台，说多了都是泪。

手动部署方式

自动部署后，开发人员只需要提交源码就行了，其他的流程都交给自动化部署工具执行。在这里没有使用钩子程序，而是每天定期执行的方式部署。

自动部署方式

Web源码发布费时费力，需要先下载源码，进行编译，发布到本地，再将所有文件复制到服务器，但很多文件是不需要更新的。可以对流程进行优化。运行vs，获取最新源码，进行文件编译，发布到本地，按生成时间进行筛选，最终效果是获取指定SVN版本号间的改动文件，例如不同的发布环境下面的代码是根据不同的svn版本进行发布的，可以先查出来某一服务器上发布的svn版本，对旧的的svn版本和最新的svn版本做对比，筛选出有更新的文件，但操作难度太大参考：从SVN导出指定版本号之间修改的文件