项目测试环境自动化部署[jenkins前后端配置、Nginx配置]
持续部署：关注点在于项目功能部署到服务器后可以正常运行，为下一步测试环节或最终用户正式使用做准备。（问题点：一个环节有问题，其他环节跟着有问题）
持续集成：关注点是在于尽早发现项目整体运行问题，尽早解决。（问题点：经常性、频繁的把所有模块集成在一起进行测试，有问题尽早发现）
持续交付：关注点在于研发团队的最新代码能够尽快让最终用户体验到。（问题点：各个升级版本之间间隔时间太长，用户反馈感知迟钝，无法精确改善用户体验，用户流失严重，所以用小版本不断进行快速迭代，不断收集用户反馈信息，用最快的速度改进优化）
1、什么是持续集成
持续集成：简称CI，指的是，频繁地（一天多次）将代码集成到主干。
持续集成的优点：减少风险；减少重复过程；任何时间、任何地点生成可部署的软件；增强项目的可见性；建立团队对开发产品的信心。
持续集成的特点：自动完成、保证每个时间点上团队成员提交的代码是成功集成的、需求不明确或频繁变更的情景、帮助企业减少管理风险。
持续集成的应用场景：
持续集成(CI)系统组成部分：
主要包含如下3个部分：
- 版本控制系统，SVN
- CI SERVER
- Web服务器，tomcat
2、Jenkins概述
Jenkins是一个开源的持续集成工具，使用jenkins搭建持续集成环境，可以进行自动构建、自动编译、自动部署。
Jenkins使用安装：
1、安装插件：比如git
2、全局配置(gloable)：git配置、mvn配置、JDK配置。
3、系统配置：主目录(.jenkins)、jenkins location、邮件、邮件通知。
4、管理用户：新建用户
5、任务操作：General-源码管理-构建服务器-构建-构建执行的shell
General:丢弃旧的构建：保持构建的天数、保持构建的最大个数、发布包保留天数、发布包最大保留XX个构建
源码管理：git地址
构建触发器：构建时间表达式包含5部分数据：minute（分钟）、hour（小时）、dom（天）、month（月）、dow(星期)。每部分数据的取值可以是具体数字，星号(*)和Hash(H),星号(*)表示任意取值，Hash（H）表示随机时间或取值范围。
比如：
H/10 * * * * 表示当前时间每隔10分钟构建一次
H(0-29)/10 * * * *表示每个小时的前一半时间中每隔10分钟构建一次
构建：maven goals:设置maven执行命令：clean package(清理、编译、打包)
3、项目部署方式
项目部署方式分2种方式：手动部署、自动化部署。
自动部署实现方式：
自动化部署实现方式：
4、jenkins部署实例--XXX项目测试环境部署
原理：“自动化”的具体体现：向版本库提交新的代码后，应用服务器上自动部署，用户或测试人员使用的马上就是最新的应用程序。
前提：jenkins已经在服务器搭建成功
4.1 jenkins配置
4.2 后端脚本配置
4.3 前端脚本配置
4.4 Nginx服务器配置
4.1 jenkins后端环境配置
step by step:
A.打开jenkins，点击新建任务
B.输入一个任务名称，与开发环境对应的任务名称
C.General:点击左边树形结构的配置，添加General信息，描述项目基本信息
D.源码管理：输入源码管理，Repositories URL是git上对应后端代码地址，Branches to build 指master始终是合并后的最新的代码。
Ps:在构建之前，需要去git上把其他分支代码合并到master上。
E.构建触发器：指定时间进行轮询添加 eg:H/3 8-23 * * *
PS:构建环境可以不需要，按需使用
F.构建后操作：
A.构建后操作->增加构建步骤->执行shell,弹框显示，添加构建动作，编写shell文件，执行脚本文件，需要开发配合，编写对应的脚本。比如使用gradlew进行打包，执行python脚本
目的：通过gradlew对程序进行打包
eg:chmod 777 /home/hl/.jenkins/workspace/${JOB_NAME}/gradlew
B.由于是gradlew对程序进行打包，构建后操作->增加构建步骤->Invoke Gradle Script,勾选Use Gradle Wrapper，task中添加如下命令：clean springCloudJar -x test
C.构建后操作：构建后操作->增加构建步骤->执行shell,弹框显示，添加构建动作，编写shell文件，执行脚本文件，需要开发配合，在对应的脚本配置文件进行信息编辑。比如添加工程对应的信息，去启动工程。具体脚本执行如下：
#工程名称，变量${JOB_NAME}是jenkins中自带的固定写法
PROJECT_NAME=${JOB_NAME}
#运行的jar程序
APP_NAME=application.jar
#日志文件输出路径
LOG_PATH=/logs/app
#应用部署路径
APP_PATH=/xxx/be
#配置文件路径(默认部署路径下的application.properties),传入参数，执行命令
CONFIG_PATH=application.properties
python2.7 /xxx/app/deploy.py $PROJECT_NAME $APP_NAME $LOG_PATH $APP_PATH $CONFIG_PATH
H.Jenkins列表页查看已经新建的工程任务
I.进入工程后，点击立即构建，开始对脚本进行自动操作，构建完成后，输入对应网址，能正常打开。
4.2 后端脚本配置文件
HOSTS:部署服务器IP账号，即存放后端代码所在的服务器IP
APP_PATH:部署到服务器的路径
VERSION_CONFIG_PATH:路径是jenkins对应目录创建的任务名称
#部署到服务器的路径（需要更改）
#APP_PATH = '/xx/be'
JOB_NAME = sys.argv[1]
APP_NAME = sys.argv[2]
LOG_PATH = sys.argv[3]
APP_PATH = sys.argv[4]+'/'+sys.argv[1]
CONFIG_PATH = sys.argv[5]
JAR_PATH = '/jenkins存放的空间目录/.jenkins/workspace/' + JOB_NAME + '/main/build/libs/' + APP_NAME
PROPERTIES_FILE = '/xxx/脚本的配置文件目录/application.properties'
AUTO_SHELL = '/xxx/脚本的配置文件目录/autoShell.sh'
def scripts():
run('mkdir -p '+APP_PATH)
if not exists(APP_PATH+'/application.properties'):
put(PROPERTIES_FILE, APP_PATH)
put(JAR_PATH, APP_PATH)
put(AUTO_SHELL,APP_PATH)
with cd(APP_PATH):
run('chmod +x autoShell.sh')
if not exists(APP_PATH + '/start.sh'):
run('sh autoShell.sh '+JOB_NAME+' '+APP_NAME+' '+LOG_PATH+' '+CONFIG_PATH)
run('sh stop.sh')
run('sleep 1')
run('ls')
run('$(sh start.sh &) && sleep 1')
run('cat start.sh')
def deploy(hosts):
execute(scripts, hosts=hosts)
if __name__=="__main__":
deploy(HOSTS)
问题一：查看变量的所在目录位置
问题二：如何判断jenkins后端环境已成功
1.可以通过后端的接口文档进行判断是否成功。
2.如果不成功，解决问题的方式：通过配置文件去找到日志文件，然后根据日志文件去看问题，排查问题。
4.3 jenkins前端环境配置
PS:与后端配置一致，区别就是脚本的不同，需要前端人员提供
A-G的步骤都是一致的，与后端的区别是从H开始：
F.构建后操作：
A.构建后操作->增加构建步骤->执行shell,弹框显示，添加构建动作，编写shell文件，执行脚本文件，需要开发配合，编写对应的脚本。比如前端打包的方式是yarn安装
目的：按打包方式的命令进行安装
ex:
#前端打包
rm -rf dist/*
yarn
yarn build
B.构建后操作：构建后操作->增加构建步骤->执行shell,弹框显示，添加构建动作，编写shell文件，执行脚本文件，需要开发配合，在对应的脚本配置文件进行信息编辑。比如添加工程对应的信息，去启动工程。具体脚本执行如下：
ex:
#工程名称
JOB_NAME=${JOB_NAME}
#部署路径
APP_PATH=/xxx/test
python2.7 /存放文件的目录/fe-deploy.py $JOB_NAME $APP_PATH
4.4 前端脚本配置文件
HOSTS:部署服务器IP账号，即存放后端代码所在的服务器IP
APP_PATH:部署到服务器的路径
from fabric.api import *
from fabric.contrib.files import exists
import os
import sys
#部署服务器ip 账号（需要更改）
HOSTS = ['haishu@127.0.0.1']
#部署服务器密码（需要更改）
env.password='xxx'
# 部署到服务器的路径（需要更改）
JOB_NAME = sys.argv[1]
APP_PATH = sys.argv[2]+'/'+sys.argv[1]
DIST_PATH = '/jenkins存放空间的目录/.jenkins/workspace/' + JOB_NAME + '/dist'
def scripts():
run('mkdir -p '+APP_PATH)
run('echo 1---')
with cd(APP_PATH):
if exists(APP_PATH +'/dist'):
run('rm -rf dist')
run('echo 2----')
put(DIST_PATH, APP_PATH)
def deploy(hosts):
execute(scripts, hosts=hosts)
if __name__=="__main__":
deploy(HOSTS)
4.5 Nginx配置
Nginx配置目的：后端与前端进行端口关联，保证前端页面能调用后端的接口信息，同时添加前端的监听端口。
PS:nginx服务器一般放在部署文件存放所在的服务器上
1.找到部署服务器所在的Nginx路径，比如：/xx/nginx/conf.d
2.进入配置页，添加测试服务器地址文件(添加后端网址-对应的应用服务器地址，即测试服务器，我们只需要配置测试环境的地址).
问题一：查找Nginx的具体目录位置[nginx的位置一般放在应用部署服务器下]
nginx -V
//找到--conf-path=/etc/nginx/nginx.conf
cat /etc/nginx/nginx.conf
//找到存放的路径，对应的include路径就是我们要找的路径
/etc/nginx/conf.d/*.conf
问题二：Nginx配置后，如何生效
//查看nginx是否配置成功
sudo nginx -t
//nginx配置后，使配置生效[不是root，都需要使用sudo]
sudo nginx -s reload
目的：添加后端服务器IP+端口、前端监听端口、前端root目录、后端api等信息，根据实际需要进行添加。
upstream xxx.test.local { server 后端IP:后端端口; } server { listen 前端端口; server_name localhost; #charset koi8-r; #access_log /var/log/nginx/host.access.log main; access_log /xx/portal_access.log; error_log /xx/portal_error.log; client_max_body_size 250m; proxy_redirect off; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; root /xxx/前端存放代码的路径/dist; #前端存放路径 location / { #location /路径 {命令列表} try_files $uri /index.html =404; } location /example/api { proxy_set_header Remote_Addr $remote_addr; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass xxx.test.local; } }
5、代码质量分析工具Sonar
Sonar是一个用于代码质量管理的开源平台，用于管理源代码的质量，可以通过插件形式从七个维度检测代码质量，可以支持Java、C#、C/C++、PL/SQL、Cobol、JavaScript、Groovy等二十几种编程语言的代码质量管理与检测。
Sonar可以检测代码中的以下七大问题：
a.糟糕的复杂度分析：如果文件、类、方法等复杂度过高将难以改变，这会使开发人员难以理解它们，而且如果没有自动化的单元测试，对于程序中的任何组件的改变都将导致全面的回归测试。
b.重复：如果代码中包含大量复制粘贴的代码则质量是低下的，Sonar可以展示源码中重复严重的地方。
c.缺乏单元测试：Sonar可以很方便的统计并展示单元测试覆盖率。
d.没有代码标准：Sonar可以通过PMD、CheckStyle、Findbugs等代码规则检测工具规范代码编写。
e.没有足够的注释或注释过多
f.潜在的bug：Sonar可以通过PMD、CheckStyle、Findbugs等代码规则检测工具检测出潜在的bug。
g.糟糕的设计：通过Sonar可以找出循环，展示包与包、类与类之间的相互依赖关系，检测耦合。
