网站建设征收文化事业建设费吗,手机软件开发培训班,新闻资讯到底是哪个公司的,网站建设具备知识技能CI/CD入门(二) 目录 CI/CD入门(二) 1、代码上线方案 1.1 早期手动部署代码1.2 合理化上线方案1.3 大型企业上线制度和流程1.4 php程序代码上线的具体方案1.5 Java程序代码上线的具体方案1.6 代码上线解决方案注意事项2、理解持续集成、持续交付、持续部署 2.1 持续集成2.2 持续… CI/CD入门(二) 目录 CI/CD入门(二) 1、代码上线方案 1.1 早期手动部署代码1.2 合理化上线方案1.3 大型企业上线制度和流程1.4 php程序代码上线的具体方案1.5 Java程序代码上线的具体方案1.6 代码上线解决方案注意事项2、理解持续集成、持续交付、持续部署 2.1 持续集成2.2 持续交付2.3 持续部署3、Maven 私服 Nexus3 3.1 Maven和Nexus3 简介3.2 安装 Maven 3.2.1 下载 maven3.2.2 安装 java 环境3.2.3 添加环境变量3.2.4 验证版本3.3 安装 nexus3 3.3.1 下载3.3.2 安装nexus3.4 仓库介绍3.5 向 nexus3 私服上传 jar 包 3.5.1 准备环境 3.5.1.1 创建3rd_part库3.5.1.2 创建 3rd_part 管理用户3.5.2 直接浏览器4、常见错误 1、代码上线方案 1.1 早期手动部署代码 纯手动Scp、Rsync上传代码。纯手动登陆Git pull 或者 Svn update。纯手动xftp、ftp、filezilla上传代码。开发发送压缩包rz上传解压部署代码。 缺点 全程运维参与占用大量时间。如果节点多上线速度慢。人为失误多目录管理混乱。回滚不及时或者难以回退。 上线方案示意图 1.2 合理化上线方案 开发人员(rd)需在个人电脑搭建LAMP环境测试开发好的网站代码并且在办公室或 IDC机房的测试环境测试通过最好有专职测试人员(ts)。程序代码上线要规定时间例如三天上线一次如网站需经常更新可每天下午 20 点上线这个看网站业务性质而定原则就是影响用户体验最小。代码上线之前需备份网站程序出了问题方便回退另外从上线技巧上讲上传代码时尽可能先传到服务器网站临时目录传完整后一步mv过去或者通过In做软链接— 线上更新代码的思路。如果严格更新把应用服务器从集群节点平滑下线然后更新。尽量由运维人员管理上线对于代码的功能性开发人员更在意而对于代码的性能优化和上线后服务器的稳定运维更在意服务器的稳定因此如果网站宕机问题归运维管就要让运维上线这样更规范科学。否则开发随意更新出了问题运维负责这样就错了运维永远无法抬头。web代码规范化上线流程图 1.3 大型企业上线制度和流程 JAVA代码环境上线时有数台机器同时需要更新或者分批更新 本地开发人员取svn代码。当天上线提交到trunk否则长期项目单开分支开发然后在合并主线(trunk)办公内网开发测试时由开发人员或配置管理员通过部署平台jenkins实现统一部署(即在部署平台上控制开发机器从svn取代码编译打包发布到开发机包名如idc_dep.war).开发人员通知或和测试人员一起测试程序没有问题后由配置管理员打上新的tag标记。这里要注意不同环境的配置文件是随代码同时发布的。配置管理员根据上一步的tag标记checkout出上线代码并配置好IDC测试环境的所有配置执行编译打包(mvn,ant)(php不需要打包)然后发布到IDC内的统一分发服务器。配置管理员或SA上线人员把分发的程序代码内容推送到相关测试服务器(包名如idc_test.war)然后通知开发及测试人员进行测试。如果有问题向上回退继续修改。如果IDC测试没有问题继续打好tag标记此时配置管理员根据上步的tag标记checkout出测试好的代码并配置好IDC正式环境的所有配置执行编译打包(mvn,ant)(php不需要打包)然后发布到IDC内的统一分发服务器主机准备批量发布。配置管理员或SA上线人员把分发的内容推送到相关正式服务器(包名如idc_product.war),然后通知开发及测试人员进行测试。如果有问题直接发布回滚指令。 IDC正式上线的过程对于JAVA程序可以是AB组分组上线的思路即平滑下线一半的服务器然后发布更新代码重启测试无问题后挂上更新后的服务器同时再平滑下线另一半的服务器然后发布更新代码测试(或者直接发布后重启挂上线) 1.4 php程序代码上线的具体方案 对于PHP上线方法发布代码时(也需要测试流程)可以直接发布到正式线临时目录 然后mv或更改link的方式发布到正式上线目录 不需要重启http服务。这是新朗赶集的上线方案。 1.5 Java程序代码上线的具体方案 对于java上线方法:较大公司需要分组平滑上线(如从负载均衡器上摘掉一半的服务器)发布代码后重启服务器测试没问题后挂上上好线的一半再下另外一半。如果前端有DNS智能解析上线还可以分地区上线若干服务器逐渐普及到全国的服务器这个被称为“灰度发布”在后面门户网站上线的知识里我们在讲解。 1.6 代码上线解决方案注意事项 上线的流程里办公室测试环境--IDC测试环境--正式生产环境所有环境中的所有软件均应版本统一其次尽量单一否则将后患无穷开发测试成功IDC测试就可能有问题(如:操作系统web服务器jdk,php,tomcat,resin等版本) 开发团队小组办公内部测试环境测试(该测试环境属于开发小组维护或定时自动更新代码)代码有问题返回给某开发人员重新开发。有专门的测试工程师程序有问题直接返回给开发人员(此时返回的一般为程序的BUG称为BUG库)无问题进行IDC测试IDC测试由测试人员和运维人员参与叫IDCtest,进行程序的压力测试有问题直接返回给开发人员无问题进行线上环境上线。数台服务器代码分发上线方案举例(JAVA程序) A:假设同业务服务器有6台将服务器分为A,B两组A组三台B组三台先对A组进行从负载均衡器上平滑下线B组正常提供服务避免服务器因上线影响业务。B:下线过程是通过脚本将A组服务器从RS池(LVS,NGINX,HAPROXY,F5等均有平滑方案)中踢出避免负裁均衡器将请求发送给A组服务器(此时的时间应该为网站流量少时一般为晚上)C:将代码分发到A组服务器的站点目录下对A组服务器上线并重启服务并由专业的测试人员进行访问测试测试成功后挂上A组的服务器同时下线B组服务器B组代码上线操作测试等和A组相同期间也要观察上线提供服务的服务器状况有问题及时回滚。 如果是PHP程序则上线可以简单化直接将上线代码(最好全量)发布到所有上线服务器的特定目录后分发完成后一次性mv或ln到站点目录当然测试也是少不了的。测试除了人员测试外还有各种测试脚本测试各个相关业务接口。 2、理解持续集成、持续交付、持续部署 软件开发的连续方法基于自动执行脚本以最大限度地减少在开发应用程序时引入错误的可能性。从新代码的开发到部署它们需要较少的人为干预甚至根本不需要干预。它涉及在每次小迭代中不断构建测试和部署代码更改从而减少基于有缺陷或失败的先前版本开发新代码的机会。有三种主要方法分别为持续集成、持续交付、持续部署每种方法都根据最适合您的策略进行应用。 2.1 持续集成 代码合并构建部署测试都在一起不断地执行这个过程并对结果反馈。 持续集成(英语Continuous integration缩写为 CI)一种软件工程流程将所有工程师对于软件的工作复本每天集成数次到共用主线(mainline)上。 这个名称最早由葛来迪·布区(Grady Booch)在他的布区方法中提出但是他并没有提到要每天集成数次。之后成为极限编程(extreme programming缩写为XP)的一部分。在测试驱动开发(TDD)的作法中通常还会搭配自动单元测试。 持续集成的提出主要是为了解决软件进行系统集成时面临的各项问题极限编程称这些问题为集成地狱(integration hell)。 持续集成主要是强调开发人员提交了新代码之后立刻进行构建、(单元)测试。根据测试结果我们可以确定新代码和原有代码能否正确地集成在一起。简单来讲就是频繁地(一天多次)将代码集成到主干。 持续集成的目的 及早发现集成错误且由于修订的内容较小所以易于追踪这可以节省项目的时间与成本。避免发布日期的前一分钟发生混乱当每个人都会尝试为他们所造成的那一点点不兼容的版本做检查。当单元测试失或发生错误若开发人员需要在不除错的情况下还原代码库到一个没有问题的状态只需要放弃一小部分的更改 (因为集成的次数频繁)。让 最新 的程序可保持可用的状态供测试、展示或发布用。频繁的提交代码会促使开发人员创建模块化低复杂性的代码。防止分支大幅偏离主干。如果不是经常集成主干又在不断更新会导致以后集成的难度变大甚至难以集成。 2.2 持续交付 部署到测试环境、预生产环境 持续交付(英语Continuous delivery缩写为 CD)是一种软件工程手法让软件产品的产出过程在一个短周期内完成以保证软件可以稳定、持续的保持在随时可以释出的状况。 它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间减少风险。 持续交付在持续集成的基础上将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。比如我们完成单元测试后可以把代码部署到连接数据库的Staging 环境中更多的测试。如果代码没有问题可以继续手动部署到生产环境中。 2.3 持续部署 将最终产品发布到生成环境给用户使用 持续部署(英语Continuous Deployment缩写为 CD)是持续交付的下一步指的是代码通过评审以后自动部署到生产环境。 有时候持续部署也与持续交付混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中但是出于业务考虑可以选择不部署。如果要实施持续部署必须先实施持续交付。 持续部署即在持续交付的基础上把部署到生产环境的过程自动化。 3、Maven 私服 Nexus3 3.1 Maven和Nexus3 简介 Maven是一个采用纯Java编写的开源项目管理工具 采用一种被称之为Project Object Model(POM)概念来管理项目所有的项目配置信息都被定义在一个叫做POM.xml的文件中, 通过该文件Maven可以管理项目的整个生命周期包括清除、编译测试报告、打包、部署等等。 目前Apache下绝大多数项目都已经采用Maven进行管理. 而Maven本身还支持多种插件, 可以方便更灵活的控制项目, 开发人员的主要任务应该是关注商业逻辑并去实现它, 而不是把时间浪费在学习如何在不同的环境中去依赖jar包,项目部署等。 Maven和ant都是软件构建工具(软件管理工具),Maven比Ant更加强大已经取代了ant,jar包的声明式依赖描述。Maven有jar包的仓库。 私服是架设在局域网的一种特殊的远程仓库目的是代理远程仓库及部署第三方构件。有了私服之后当 Maven 需要下载构件时直接请求私服私服上存在则下载到本地仓库否则私服请求外部的远程仓库将构件下载到私服再提供给本地仓库下载。 公司如果没有maven私服则需要用手动打jar包的方式添加依赖 3.2 安装 Maven 3.2.1 下载 maven # 下载 maven
[rootmaven ~]# wget https://mirrors.tuna.tsinghua.edu.cn/apache/maven/maven-3/3.8.8/binaries/apache-maven-3.8.8-bin.tar.gz# 解压安装
[rootmaven ~]# tar xf apache-maven-3.8.8-bin.tar.gz -C /usr/local/
[rootmaven ~]# mv /usr/local/apache-maven-3.8.8 /usr/local/maven 3.2.2 安装 java 环境 # 安装 java 环境
[rootmaven ~]# tar xf jdk-8u171-linux-x64.tar.gz -C /usr/local/
[rootmaven ~]# mv /usr/local/jdk1.8.0_171/ /usr/local/jdk 3.2.3 添加环境变量 # 添加环境变量
[rootmaven ~]# cat /etc/profile EOF
JAVA_HOME/usr/local/jdk
export MAVEN_HOME/usr/local/maven
export CLASSPATH.:$JAVA_HOME/lib:$JAVA_HOME/lib/tools.jar:$CLASSPATH
export PATH$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$MAVEN_HOME/bin:$PATH
EOF# 加载环境变量
[rootmaven ~]# source /etc/profile 3.2.4 验证版本 [rootmaven ~]# java -version
java version 1.8.0_171
Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)[rootmaven ~]# mvn -version
Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
Maven home: /usr/local/maven
Java version: 1.8.0_171, vendor: Oracle Corporation, runtime: /usr/local/jdk/jre
Default locale: zh_CN, platform encoding: UTF-8
OS name: linux, version: 3.10.0-1160.90.1.el7.x86_64, arch: amd64, family: unix 3.3 安装 nexus3 3.3.1 下载 下载开源版 Nexus OSS 3.3.2 安装nexus # 解压
[rootmaven ~]# tar xf nexus-3.58.1-02-unix.tar.gz -C /usr/local/
[rootmaven ~]# mv /usr/local/nexus-3.58.1-02 /usr/local/nexus# 启动
[rootmaven ~]# cd /usr/local/nexus/bin/
[rootmaven bin]# ./nexus start
WARNING: ************************************************************
WARNING: Detected execution as root user. This is NOT recommended!
WARNING: ************************************************************
Starting nexus 看到如图所示内容表明我们已经启动成功了游览器输入http://192.168.200.19:8081即可访问。 登录 点击右上角的sign in登录输入账户admin # 密码
[rootmaven bin]# cat /usr/local/sonatype-work/nexus3/admin.password
9807551b-fed2-46f3-b500-74c785ce0ca7 设置新密码ywb971108 禁用匿名模式 3.4 仓库介绍 点击“设置-Repositories”就可以看到仓库分三种类型 proxy是远程仓库的代理。比如说在nexus中配置了一个central repository的proxy当用户向这个proxy请求一个artifact这个proxy就会先在本地查找如果找不到的话就会从远程仓库下载然后返回给用户相当于起到一个中转的作用。 Hosted是宿主仓库用户可以把自己的一些构件deploy到hosted中也可以手工上传构件到hosted里。比如说oracle的驱动程序ojdbc6.jar在central repository是获取不到的就需要手工上传到hosted里一般用来存放公司自己的jar包Group是仓库组在maven里没有这个概念是nexus特有的。目的是将上述多个仓库聚合对用户暴露统一的地址这样用户就不需要在pom中配置多个地址只要统一配置group的地址就可以了右边那个Repository Path可以点击进去看到仓库中artifact列表。不过要注意浏览器缓存当你的项目希望在多个repository使用资源时就不需要多次引用了只需要引用一个group即可。 maven-publicmaven-central、maven-release和maven-snapshot三个库的合集。maven-release用来存放release版本的jar包。maven-snapshot用来存放snapshot版本的jar包。 关于Maven的Snapshot版本与Release版本 Snapshot版本代表不稳定、尚处于开发中的版本Release版本则代表稳定的版本什么情况下该用SNAPSHOT? 协同开发时如果A依赖构件B由于B会更新B应该使用SNAPSHOT来标识自己。这种做法的必要性可以反证如下 如果B不用SNAPSHOT而是每次更新后都使用一个稳定的版本那版本号就会升得太快每天一升e68a84e8a2ade79fa5e9819331333363396362甚至每个小时一升这就是对版本号的滥用。如果B不用SNAPSHOT, 但一直使用一个单一的Release版本号那当B更新后A可能并不会接受到更新。因为A所使用的repository一般不会频繁更新release版本的缓存(即本地repository)所以B以不换版本号的方式更新后A在拿B时发现本地已有这个版本就不会去远程Repository下载最新的B 不用Release版本在所有地方都用SNAPSHOT版本行不行 不行。正式环境中不得使用snapshot版本的库。 比如说今天你依赖某个snapshot版本的第三方库成功构建了自己的应用明天再构建时可能就会失败因为今晚第三方可能已经更新了它的snapshot库。你再次构建时Maven会去远程repository下载snapshot的最新版本你构建时用的库就是新的jar文件了这时正确性就很难保证了。 3.5 向 nexus3 私服上传 jar 包 3.5.1 准备环境 3.5.1.1 创建3rd_part库 点击左侧的repository\repositories后,在右侧点击create repository 然后选择maven2(hosted),填写如下 跳到首页后选择maven-public 将3rd_part移到member中,即将3rd_part由maven-public管理点击save 至此,创建仓库完成 3.5.1.2 创建 3rd_part 管理用户 创建用户: 用户名/密码-dev/dev123 3.5.2 直接浏览器 使用dev/dev123登陆点击upload 填写上传jar包的信息后点击upload 可以看到已经上传成功 4、常见错误 问题1上传报错误码405Failed to transfer file。 解决仔细查看报错信息就会发现是上传的url错了,原因就是repository的地址写错了。 问题2错误码401或者403 解决其实403错误就是“禁止访问”的含义所以问题的根源肯定在授权上面。Maven在默认情况下会使用deployment帐号(默认密码deploy)登录的系统但是关键的Nexus中Releases仓库默认的Deployment Policy是“Disable Redeploy”所以无法部署的问题在这个地方方法是将其修改为“Allow Redeploy”就可以了。401就是Maven settings.xml没有设置密码
