项目测试环境自动化部署[jenkins前后端配置、Nginx配置]

持续部署：关注点在于项目功能部署到服务器后可以正常运行，为下一步测试环节或最终用户正式使用做准备。（问题点：一个环节有问题，其他环节跟着有问题）

持续集成：关注点是在于尽早发现项目整体运行问题，尽早解决。（问题点：经常性、频繁的把所有模块集成在一起进行测试，有问题尽早发现）

持续交付：关注点在于研发团队的最新代码能够尽快让最终用户体验到。（问题点：各个升级版本之间间隔时间太长，用户反馈感知迟钝，无法精确改善用户体验，用户流失严重，所以用小版本不断进行快速迭代，不断收集用户反馈信息，用最快的速度改进优化）

1、什么是持续集成

持续集成：简称CI，指的是，频繁地（一天多次）将代码集成到主干。

持续集成的优点：减少风险；减少重复过程；任何时间、任何地点生成可部署的软件；增强项目的可见性；建立团队对开发产品的信心。

持续集成的特点：自动完成、保证每个时间点上团队成员提交的代码是成功集成的、需求不明确或频繁变更的情景、帮助企业减少管理风险。

持续集成的应用场景：

持续集成(CI)系统组成部分：

 

主要包含如下3个部分：

1. 版本控制系统，SVN
2. CI SERVER
3. 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 / {
        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可以找出循环，展示包与包、类与类之间的相互依赖关系，检测耦合。