Jenkins
Jenkins概述
中文文档
- https://www.jenkins.io/zh/doc/
简介
- Jenkins的主要开发者是川口耕介, 是在MIT许可证下发布的自由软件
- Jenkins是一个用Java编写的免费开源的持续集成工具，允许持续集成和持续交付项目，无论用的是什么平台
- Jenkins提供了软件开发的持续集成服务。它运行在Servlet容器中(例如Apache Tomcat)
- Jenkins支持软件配置管理(SCM)工具，包括AccuRev SCM、CVS、Subversion、Git、Perforce、Clearcase和RTC，可以执行基于Apache Ant和Apache Maven的项目，以及任意的Shell脚本和Windows批处理命令
功能
- 持续的软件版本发布/测试项目
- 监控软件开发流程，快速问题定位及处理，提高开发效率
特性
-
开源的java语言开发持续集成工具，支持CI/CD(持续集成 持续交付 持续布署)
-
易于安装部署配置
- 可通过yum安装、下载war包、docker容器等快速实现安装部署，可方便web界面配置管理
-
消息通知及测试报告
- 集成RSS/E-mail，通过RSS发布构建结果或通过e-mail通知，生成JUnit/TestNG测试报告
-
分布式构建
- 支持Jenkins能够让多台计算机一起构建/测试
-
文件识别
- Jenkins能够跟踪哪次构建生成哪些jar，哪次构建使用哪个版本的jar等
-
丰富的插件支持
- 支持扩展插件，你可以开发适合自己团队使用的工具，如git，svn，maven，docker等
产品发布流程
- 产品设计成型 -> 开发人员开发代码 -> 测试人员测试功能 -> 运维人员发布上线
CI/CD
持续集成
Continuous Integration
-
介绍
- 一种软件工程流程，将所有工程师对于软件的工作复本，每天集成数次到mainline上
- 最早由Grady Booch提出，之后成为极限编程(extreme programming,XP)的一部分。在测试驱动开发(TDD)的作法中，通常还会搭配自动单元测试
- 持续集成的提出，主要是为了解决软件进行系统集成时面临的各项问题，极限编程称这些问题为集成地狱(integration hell)
- 强调开发人员提交了新代码之后，立刻进行构建、(单元)测试。根据测试结果，确定新代码和原有代码能否正确地集成在一起
-
目的
- 及早发现集成错误且由于修订的内容较小所以易于追踪，这可以节省项目的时间与成本
- 避免发布日期的前一分钟发生混乱，当每个人都会尝试为他们所造成的那一点点不兼容的版本做检查
- 当单元测试失败或发生错误，若开发人员需要在不除错的情况下还原代码库到一个没有问题的状态，只需要放弃一小部分的更改 (因为集成的次数频繁)
- 让 “最新” 的程序可保持可用的状态供测试、展示或发布用
- 频繁的提交代码会促使开发人员创建模块化，低复杂性的代码
- 防止分支大幅偏离主干。若未经常集成，主干又在不断更新，会导致以后集成的难度变大甚至难以集成
持续交付
Continuous Delivery
- 一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况
- 它的目标在于让软件的构建、测试与释出变得更快更频繁。这种方式可以减少软件开发的成本与时间，减少风险
- 持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中做更多的测试
持续部署
Continuous Deployment
- 持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境
- 持续部署即在持续交付的基础上，把部署到生产环境的过程自动化
简单总结
-
持续集成(Continuous Integration, CI)
- 代码合并，构建，部署，测试都在一起，不断地执行这个过程，并对结果反馈
-
持续交付(Continuous Deployment, CD)
- 将产品部署到测试环境、预生产环境, 手动(选择性的)布署到生产环境
-
持续部署(Continuous Delivery, CD)
- 将最终产品自动布署到生成环境, 给用户使用
持续交付与持续部署
- 持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署, 人为控制
- 持续部署意味着所有的变更都会被自动部署到生产环境中,自动部署
- 如果要实施持续部署，必须先实施持续交付
持续交付与DevOps
- 含义相似，但是两个不同的概念
- DevOps的范围更广, 它以文化变迁为中心, 特别是软件交付过程所涉及的多个团队之间的合作(开发,运维,QA,管理部门等), 并且将软件交付的过程自动化
- 持续交付是一种自动化交付的手段，关注点在于将不同的过程集中起来，并且更快、更频繁地执行这些过程
- 因此，DevOps可以是持续交付的一个产物，持续交付直接汇入DevOps
实现CI/CD
-
CI/CD 框架
- CI/CD工具有很多，其中Jenkins是应用最为广泛的一种
-
源代码控制管理
- CI/CD工具与源代码控制管理(SCM)工具集成是最佳实践之一，推荐Git
-
自动化构建工具
-
将源代码构建成某种想要的格式，并且将清理、编译、测试、部署到某个位置这些任务自动化
-
常用语言对应的开源构建工具
- Java: Maven, Ant, Gradle, Bazel
- JavaScript: Grunt, Gulp
- Ruby: Buildr, Rake
- Python: A-A-P, SCons, BitBake
- C#: Cake
-
-
应用服务器
-
构建出应用之后，还需要应用服务器来发布我们的应用
-
常见的网页应用服务
- Java：Tomcat, Jetty, WildFly …
- Python: Django, Tornado …
- JavaScript: Node.js
-
-
代码覆盖测试
-
代码测试框架：进行编写与运行测试
- Java: JUnit, EasyMock, Mockito, PowerMock
- Python: Pytest, Hypothesis, Tox
-
代码质量改进工具：提升代码的质量
- Java: Cobertura, CodeCover, Emma, JaCoCo
- Python: Coverage.py, Hypothesis, Tox
- JavaScript: Jasmine, Karma, Mocha, Jest
-
部署Jenkins
版本要求
-
jdk-1.11
-
jenkins-2.346
-
maven-3.5
-
git-1.8
- 不低于1.7
安装运行
-
配置java环境
export JAVA_HOME=/usr/local/java
export PATH=
J
A
V
A
H
O
M
E
/
b
i
n
:
JAVA_HOME/bin:
JAVAHOME/bin:PATH
- . /etc/profile.d/java.sh
-
安装jenkins
-
curl -o /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo
-
rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key
-
yum install -y jenkins
-
/etc/sysconfig/jenkins
- 主配置文件
-
/var/lib/jenkins
- 默认的JENKINS_HOME目录
-
/usr/lib/jenkins/jenkins.war
- WAR包
-
-
-
运行jenkins
JENKINS_JAVA_CMD=“/usr/local/java/bin/java”
- 修改启动文件
- # vim /usr/lib/systemd/system/jenkins.service
[Service]
EnvironmentFile=-/etc/sysconfig/jenkins
#让Jenkins配置文件生效，'-'表示若没有该文件不影响启动
- systemctl daemon-reload
- 启动jenkins
- systemctl start jenkins;systemctl enable jenkins
- 启动超时处理
- # netstat -tanp |grep java
tcp6 0 0 :::8080 ::😗 LISTEN 2361/java
-
安装Maven
export MAVEN_HOME=/usr/local/maven3.5
export PATH=
M
A
V
E
N
H
O
M
E
/
b
i
n
:
MAVEN_HOME/bin:
MAVENHOME/bin:PATH
- . /etc/profile.d/maven.sh
- mvn -v
- 配置国内镜像加速
- # vim /usr/local/maven3.5/conf/settings.xml
#找到mirrors标签，加入以下内容
alimaven
aliyun maven
https://maven.aliyun.com/nexus/content/groups/public/
central
-
测试maven
-
git clone https://gitee.com/leedon21/easy-springmvc-maven.git
- 下载源码
-
cd easy-springmvc-maven/
-
mvn package
- 打包，构建成功后会生成war包或jar包
-
mvn clean
- 清除
-
mvn clean package
- 先清除再打包
-
-
安装git
- yum install -y git
系统配置
-
服务启动后,使用浏览器访问http://jenkins-ip:8080
-
初始化配置
-
1、根据提示解锁jenkins
-
2、安装推荐插件，若有失败项，点击重试
-
3、创建管理员帐户
-
2可能出现离线问题
- vim /var/lib/jenkins/updates/default.json
将goole.com改为baidu.com - vim /var/lib/jenkins/hudson.model.UpdateCenter.xml
url中https改为http
#其他国内备用地址：
https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
http://mirror.esuni.jp/jenkins/updates/update-center.json
- vim /var/lib/jenkins/updates/default.json
-
-
插件管理
-
在线安装
- 系统管理->插件管理->可选插件->搜索(显示的是未安装插件)->勾选->Install without restart
- 若有安装失败的，基本上都是网络超时或依赖前面失败的插件，重新安装直到全部成功
-
离线安装
-
下载
-
官网
- http://updates.jenkins-ci.org/download/plugins/
-
国内
- https://mirrors.tuna.tsinghua.edu.cn/jenkins/plugins/
-
-
上传
- 系统管理->插件管理->高级->Deploy Plugin选择插件->Deploy
-
-
需额外安装的插件
- Publish Over SSH
- GitLab
- Maven Integration
- Blue Ocean
-
-
Publish over SSH配置
-
系统管理->系统配置->Publish over SSH->填写Jenkins SSH Key->填写SSH Servers->保存
-
Jenkins SSH Key
-
Passphrase
- 远程服务器登录密码
-
Path to key
- 远程服务器私钥路径
-
Key
- 远程服务器私钥内容
-
-
SSH Servers
-
SSH Server Name
- tomcat(远程服务器名字)
-
Hostname
- 1.1.1.25(远程服务器IP)
-
Username
- root(远程服务器登录用户名)
-
Remote Directory
- /tmp(远程服务器接收文件的目录)
-
Test Configuration
- 测试
-
-
-
全局工具配置
-
系统管理->全局工具配置->配置JDK->配置Git->配置Maven->保存
-
JDK
- JDK安装->填写JDK别名->填写JAVA_HOME(java命令的路径去除‘/bin/java’)->去勾选自动安装
-
Git
- yum安装的git采用默认配置
-
Maven
- Maven->填写Maven Name->填写MAVEN_HOME($MAVEN_HOME)->去勾选自动安装
-
配置jenkins连接gitlab
介绍
- 有许多第三方网站和应用程序可以与Jenkins进行交互，例如程序代码仓库，云存储系统和服务等
- 此类应用程序的系统管理员可以在应用程序中配置凭证以专供Jenkins使用
- 一旦在Jenkins中添加/配置这些凭证，Pipeline 项目就可以使用凭证与这些第三方应用程序进行交互
gitlab创建用户
- 创建一个管理员用户jenkins，在jenkins服务器上使用此用户来拉取代码
jenkins创建凭据
-
系统管理->Manage Credentials-> 全局->添加凭据->选择类型->配置->Create
-
类型
-
Username with password
-
用户名
- jenkins(gitlab用户名)
-
密码
- gitlab用户密码
-
ID
- 1(自定义，不冲突)
-
描述
- passwd(自定义)
-
-
SSH Username with private key
-
ID
- 2(自定义，不冲突)
-
描述
- ssh key(自定义)
-
Username
- jenkins
-
Enter directly
- 添加jenkins服务器私钥
-
-
-
类型二选一即可，若克隆使用SSH则选择私钥，若克隆使用HTTP则选择密码
创建构建任务
（Java应用）
介绍
- java源代码不能直接运行，需要通过maven或其它工具打包成jar包或war包才可以运行
准备工作
-
配置maven
-
配置java应用服务器(tomcat)
-
上传测试代码到gitlab中
-
gitlab web
- 创建一个项目组 qfedu
- 创建测试项目 easy-spring
-
gitlab server
- git clone https://gitee.com/leedon21/easy-springmvc-maven.git
- cd easy-springmvc-maven/
- git remote add spring git@1.1.1.21:jenkins/easy-spring.git
- git push spring master
-
jenkins配置任务
-
新建任务->自定义任务名称-> 选择任务类型->确定->配置->保存
-
maven项目
-
源码管理
-
选择Git
-
Repository URL
- git@1.1.1.21:jenkins/easy-spring.git(克隆链接)
-
Credentials
- jenkins(ssh key)(选择凭证，与克隆类型对应)
-
-
构建触发器
-
手动构建(默认)
- Build whenever a SNAPSHOT dependency is built
-
自动构建
-
-
Build
- 构建war包，按maven默认配置
-
Post Steps
-
Add post-build step选择Send files or execute commands over SSH
-
SSH Server Name
- tomcat(远程主机名)
-
Source files
- target/*.war(源文件)
-
Remove prefix
- target(去除前缀,可选)
-
Remote directory
- 远程目录
-
Exec command
- 执行远程命令
-
-
-
自由风格项目
-
源码管理
- 同maven项目
-
构建
- 增加构建步骤选择‘执行shell’
- 命令：/usr/local/maven3.5/bin/mvn package
-
构建后操作
- 同maven项目
-
任务构建
-
步骤
-
我的视图->选择任务->立即构建
- 左边’构建执行状态‘会显示任务进度状态
-
点击任务标签’#1‘旁下拉选项可进行查看操作，’控制台输出‘可查看构建详细过程(排错)
-
-
过程
-
创建目录
- 系统在/var/lib/jenkins/workspace中创建一个以项目名称命名的目录
-
拉取源码
- 进入项目目录中通过git拉取远程仓库的源码
-
源码打包
- 在项目目录中通过maven进行打包，成功后生成target目录，里面包含源码war包
-
远程传输
- 通过SSH将war包传输到目标主机的远程目录上
-
远程命令
- 在远程主机上执行命令(如执行发布脚本)
-
验证
-
Jenkins
- 看/var/lib/jenkins/workspace中是否生成war包
-
tomcat
- 看远程目录中是否有war包，是否达到远程命令效果
构建触发器
定时构建(Build periodically)
- 按日程表所设置的时间进行构建，如：H/30 * * * * 每隔30分钟构建一次
轮循 SCM (Poll SCM)
- 按日程表所设置的时间进行查询，若远程仓库有变化则构建，若没有变化则不构建
Push事件触发
-
当有人向GitLab仓库某分支(自定义，一般为master)成功的push代码时，立即触发构建
-
配置
-
jenkins
-
安装GitLab插件
-
构建触发器勾选’Build when a change is pushed to GitLab‘
-
选择启用触发器条件
- Push Events(推送事件)
- Accepted Merge Request Events(接受的合并请求事件)
-
高级
-
Allowed branches
- 通过Filter branches by name过滤分支
- Include包含或Exclude不包含
-
Secret token
- Generate生成token(通信的验证令牌,可自定义)
-
-
-
gitlab web
-
设置外发请求
- 扳手->设置->网络->外发请求->全部勾选->保存
-
设置webhook
- 进入要自动构建的项目->设置->Webhooks->填写URL(jenkins中触发器类型后面)->填写token(jenkins中生成的)->添加
-
-
-
测试
- 将仓库克隆到本地，修改内容后保存推送，观察任务是否自动构建
远程触发构建
-
通过预定义的URL来触发构建
-
配置
-
开启匿名用户读权限
- 系统管理->全局安全配置->授权策略勾选’匿名用户具有可读权限‘->保存
-
构建触发器勾选’触发远程构建 (例如,使用脚本)‘，自定义身份验证令牌
-
-
验证
-
访问指定URL，观察是否触发自动构建
-
URL
- JENKINS_URL/job/spring/build?token=TOKEN_NAME
- http://1.1.1.22:8080/job/spring/build?token=abc
-
可通过浏览器访问或使用curl(常在脚本中使用)
-
参数化构建
介绍
- 任务中定义参数，构建前选择参数，将参数传递给脚本，实现定制化的任务
配置
- 配置任务->General中勾选’参数化构建过程‘->添加参数->选择参数类型->配置参数->保存
参数类型
-
布尔值参数
-
名称
- 变量名
-
Set by Default
- 勾选则默认为true，不勾选则默认false
-
-
选项参数
-
名称
- 变量名
-
选项
- 定义选项，一行一个，第一行为默认选项
-
-
文本参数
-
名称
- 变量名
-
默认值
- 定义默认文本，构建前可修改
-
-
Extended Choice Parameter
-
需安装插件Extended Choice Parameter
-
Name
- 变量名
-
Basic Parameter Types
-
Single Select
- 单选参数1
-
Multi Select
- 多选参数1
-
Radio Buttons
- 单选参数2
-
Check Boxes
- 多选参数2
-
Text Box
- 文本参数
-
Hidden
- 隐藏的默认值，不显示
-
-
Number of Visible Items
- 可见选项数
-
Delimiter
- 多个参数值分隔符，默认‘,’
-
Choose Source for Value
- 参数值来源
-
-
Git 参数
-
需安装插件Git Parameter
-
名称
- 变量名
-
参数类型
-
标签
- 仓库中的所有标签列表，返回标签名
-
分支
- 仓库中的所有分支列表，返回分支名
-
-
默认值
- 定义默认值，可不填
-
注意
- 参数名称不能为中文
- 所有类型参数在构建时都可选择或修改，若不选择则使用默认值
- 定义的参数可以传递到shell命令及本地脚本中
实验
-
目标
- 使用tag进行版本管理，通过operation参数选择操作（构建|回滚）
-
操作
-
构建
- 通过tag拉取代码 -> 构建 -> 将成品加入版本库管理 -> 调用ansible-playbook发布
-
回滚
- 进入成品库 -> checkout到指定tag -> 调用 ansible-playbook发布
-
-
配置任务
-
新建任务->任务名spring->自由风格->确定->参数化构建->源码管理->构建->保存
-
参数化构建
-
添加Git 参数
-
名称
- tag
-
参数类型
- 标签
-
-
添加选项参数
-
名称
- operation
-
选项
- build
rollback
- build
-
-
-
源码管理
-
选择Git
-
Repositories
-
Repository URL
- git@1.1.1.21:jenkins/spring.git
-
Credentials
- 选择SSH的凭证
-
-
Branches to build
- $tag
-
-
-
构建
-
增加‘执行 shell’
- /tmp/spring.sh
-
-
-
配置Jenkins
-
编写构建脚本
- [root@jenkins ~]# vim /tmp/spring.sh
#!/bin/bash
workdir=/var/lib/jenkins/workspace/spring #工作空间中的任务目录
if [ “$operation” == “build” ];then #判断操作是否‘构建’
cd KaTeX parse error: Expected 'EOF', got '#' at position 49: …vn package #̲打包 while :;do …tag"
git tag KaTeX parse error: Expected 'EOF', got '#' at position 53: … #̲版本标签，tag在构建时选择
else #操作为‘回滚’
cd /spring
git checkout $tag #切换到指定tag版本
fi
ansible-playbook -i /tmp/spring.host /tmp/spring.yaml #调用ansible发布版本
git checkout master #切回master分支，因为在标签中保存版本可能出错
- [root@jenkins ~]# vim /tmp/spring.sh
-
编写playbook
- [root@jenkins ~]# vim /tmp/spring.yaml
-
-
hosts: all
user: root #远程连接到root用户执行
gather_facts: false
vars:- appdir: /var/lib/tomcat/webapps #tomcat发布目录
- app: easy-springmvc-maven #应用名称
tasks: - name: remove old #删除原有应用版本
file:
dest: “{{appdir}}/{{app}}”
state: absent - name: copy app #将版本库中war包拷贝到发布目录
copy:
dest: “{{appdir}}”
src: “/spring/{{app}}.war” - name: restart tomcat #重启tomcat(可选)
shell: “{{item}}”
loop:-
/usr/local/tomcat/bin/shutdown.sh
-
“nohup /usr/local/tomcat/bin/startup.sh &” #ansible远程启动(脱离终端)
-
编写host
- [root@jenkins ~]# vim /tmp/spring.host
1.1.1.25
- [root@jenkins ~]# vim /tmp/spring.host
-
配置版本仓库
-
创建目录并授权
- mkdir /spring;chown jenkins.jenkins -R /spring
-
仓库初始化
- cd /spring
git init
git config --system user.name “tom”
git config --system user.email “tom@qq.com”
- cd /spring
-
注意权限
- 该仓库为Jenkins用户操作，整个目录属主属组要设为Jenkins
- –global设置的用户信息是针对当前系统用户即root，所以要用–system设置针对所有系统用户，或者切换到jenkins再用–global
-
-
配置ansible
-
安装ansible并在配置文件中关闭指纹
-
传公钥
- [root@jenkins ~]# usermod -s /bin/bash jenkins
[root@jenkins ~]# su - jenkins
-bash-4.2$ ssh-keygen
-bash-4.2$ ssh-copy-id root@1.1.1.25
-bash-4.2$ exit
[root@jenkins ~]# usermod -s /bin/false jenkins - jenkins默认登录shell为/bin/false不能登录，但执行ansible任务是jenkins用户，需要传递jenkins的公钥到tomcat的root用户，所以临时修改登录shell
- [root@jenkins ~]# usermod -s /bin/bash jenkins
-
-
-
验证
- 保存
- git add .
git commit -m “green”
- 推送到master
- git push origin master
- 打标签
- git tag v1.0
- 推送到标签
- git push origin v1.0
- 构建操作
- 任务构建，tag选择版本，operation选择‘build’
- 回滚操作
- 任务构建，tag选择版本，operation选择‘rollback’
- 观察tomcat网页是否发生相应变化
流水线
概念
-
pipline
- 流水线，定义整个构建过程，通常包括构建应用程序、测试和交付应用程序的阶段
-
node
- 节点，执行流水线的机器
-
stage
- 阶段，定义阶段性的任务，是多个step的子集。名称自定义，用户可视化流水线过程
-
step
- 步骤，在阶段内定义单一的任务，表明要做什么
-
Jenkinsfile
- Jenkins流水线以编码脚本的形式提供，脚本名称通常为 “Jenkinsfile”
语法
-
声明式
-
脚本式
-
以Groovy语言为基础，语法结构同Groovy相同
-
结构
- pipeline {
agent any
- pipeline {
stages {
stage(‘pull code’) {
steps {
git credentialsId: ‘1’, url: ‘git@1.1.1.21:jenkins/spring.git’
}
}
stage(‘maven package’) {
steps {
sh ‘’/usr/local/maven3.5/bin/mvn package’
}
}
stage(‘Deploy’) {
steps {
sh ‘ansible-playbook -i /tmp/spring.host /tmp/spring.yaml’
}
}
}
} -
文档
- https://www.jenkins.io/zh/doc/book/pipeline/jenkinsfile/
新建
-
脚本式
- 新建Item->定义名称->选择Pipeline->确定->流水线->写脚本->保存->构建
- 写脚本可利用左下角‘流水线语法’工具，选择相应步骤并填写，再‘生成流水线脚本’
-
插件
- 安装Blue Ocean 插件，当前版本可能使用有问题
- 打开Blue Ocean->创建流水线->Git->仓库URL->创建流水线->添加阶段->添加步骤->保存->填写描述信息->Save & run
用户和权限管理
背景介绍
- 默认授权策略‘Logged-in users can do anything’无法进行权限管理，所有可登录用户都有admin权限
- Role-Based Strategy可以对构建的项目进行授权管理，让不同的用户管理不同的项目，将不同环境的权限进行区分。该插件可以很灵活的根据需求来进行划分权限，包括正则匹配等
安装插件
- Role-based Authorization Strategy
开启插件功能
- 系统管理->全局安全配置->授权策略->选择Role-Based Strategy->保存
权限划分
-
系统管理->Manage and Assign Roles
-
Manage Roles管理角色
-
针对角色赋予不同权限，再将该角色分配给用户。角色就相当于一个组
-
角色类型
-
Global roles
- 默认有一个admin用户的，有所有权限
-
Item roles
- 项目角色
-
Node roles
- 节点相关的权限
-
-
选择角色类型->Role to add->定义角色名称->Add->分配权限->Save
-
-
Assign Roles分配角色
- 将角色与用户名进行绑定，以实现角色的实例化
- 选择角色类型->User/group to add->填用户名->Add->分配角色(可多个)->Save
-
角色策略宏
案例
-
需求
- tom为S项目组的管理人员，jerry为S项目组的开发人员
- 项目管理人员可以创建项目，并指定的项目具有全部权限
- 开发人员不能创建或删除项目，可以构建，但不能删除构建
-
配置
-
创建角色
-
全局角色
-
manager
- 查看，创建项目权限
-
developer
- 仅查看权限
-
-
项目角色
-
ItemS Manager
- 以S开头的项目(Pattern:S.*)的全部权限
-
ItemS Dev
- 以S开头项目的构建，取消，读取，读取空间等权限
-
-
-
分配角色
-
全局角色分配
- tom：manager，jerry：developer
-
项目角色分配
- tom：ItemS Manager，jerry：ItemS Dev
-
-
-
登录测试
应用发布
介绍
- 在项目迭代的过程中，不可避免需要进行项目上线
- 上线对应着部署或者重新部署，部署对应着修改，修改则意味着风险
方案
-
蛮力发布
-
方式
- 主要靠手工完成，先将老版本全部下掉，再将新版本发到机器上去
-
优势
- 操作简单，服务器成本低
-
不足
- 迭代过程中服务中断, 用户将受到影响
- 如果新版本有问题, 回滚也将消耗大量时间, 造成服务长时间不可用
-
适用场景
- 开发测试环境
- 非关键应用（用户影响面小）
- 初创公司什么都缺，找夜深人静用户访问量小的时间干
-
-
蓝绿发布
-
方式
- 先不停掉老版本，直接部署一套新版本，等新版本运行起来后，再将流量切换到新版本上
- 通常生产环境需要两组配置(蓝绿配置)，一组是active的生产环境(绿配置)，一组是inactive(蓝配置)
- 用户访问的时候，只会让用户访问active的服务器集群。在绿色环境运行旧版v1
- 当想要升级到v2 ，在蓝色环境中进行操作，即部署新版本应用，并进行测试
- 若测试正常，把负载均衡器/反向代理/路由指向蓝色环境。随后需要监测新版本应用运行情况
- 若运行良好，删除旧版使用的资源。若运行异常，通过负载均衡器指向快速回滚到绿色环境
-
优势
- 操作简单，升级切换和回退速度非常快
-
不足
- 需要两倍机器资源, 成本较高
- 切换是全量的，如果V2版本有问题，则对用户体验有直接影响
-
适用场景
- 对用户体验有一定容忍度的场景
- 机器资源有富余或者可以按需分配
- 暂不具备复杂滚动发布工具研发能力
-
-
灰度发布
(金丝雀发布)-
方式
- 指在黑与白之间，能够平滑过渡的一种发布方式，如AB Test
- 使用HTTP Header 匹配指定测试人员的流量到新版本上，然后当新版本内部测试通过后，可以再按百分比，将用户流量一点一点导入到新版本中，比如先导入10%观察一下运行情况，然后再导入20%，如此累加，直到将流量全部导入到新版本上，最后完成升级，如果期间发现问题，就立即取消升级，将流量切回到老版本
-
步骤
- 准备好部署各个阶段的工具，包括：构建工具，测试脚本，配置文件和部署清单文件
- 从负载均衡列表中移除掉“金丝雀”服务器
- 升级“金丝雀”应用（排掉原有流量并进行部署）
- 对应用进行自动化测试
- 将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）
- 如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
-
优势
- 保证整体系统稳定性，在初始灰度的时候就可以发现、调整问题，影响范围可控
- 新功能逐步评估性能，稳定性和健康状况，如果出问题影响范围很小，相对用户体验影响也少
- 用户无感知，平滑过渡
-
不足
- 发布中自动化程度不够，发布期间可能引发服务中断
-
适用场景
- 对新版本功能或性能缺乏足够信心
- 用户体验要求较高的网站业务场景
- 缺乏足够的自动化发布工具研发能力
-
-
滚动发布
-
方式
- 一次滚动式发布一般由若干个发布批次组成，每批的数量一般是可以配置的。例如第一批 1 台(金丝雀)，第二批 10%，第三批 50%，第四批 100%
- 每次发布时，先将老版本 V1 流量从 LB 上摘除，然后清除老版本，发新版本 V2，再将 LB 流量接入新版本。这样可以尽量保证用户体验不受影响
- 每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程比较缓慢(其中金丝雀的时间一般会比后续批次更长，比如金丝雀10分钟，后续间隔5分钟)
- 回退是发布的逆过程，将新版本流量从 LB 上摘除，清除新版本，发老版本，再将 LB 流量接入老版本。和发布过程一样，回退过程一般也比较慢的
-
优势
- 用户体验影响小，体验较平滑
-
不足
- 发布和回退时间比较缓慢
- 发布工具比较复杂，LB 需要平滑的流量摘除和拉入能力
-
2075
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
