软件开发生命周期又叫做SDLC(Software Development Life Cycle),它是集合了计划、开发、测试和部署过程的集合。
这是生命周期的第一阶段,根据项目需求,团队执行一个可行性计划的分析。项目需求可能是公司内部或者客户提出的。这阶段主要是对信息的收集,也有可能是对现有项目的改善和重新做一个新的项目。
还要分析项目的预算多长,可以从哪方面受益及布局,这也是项目创建的目标
第二阶段就是设计阶段,系统架构和满意状态(就是要做成什么样子,有什么功能),和创建一个项目计划。计划可以使用图表,布局设计或者文者的方式呈现。
第三阶段就是实现阶段,项目经理创建和分配工作给开者,开发者根据任务和在设计阶段定义的目标进行开发代码。依据项目的大小和复杂程度,可以需要数月或更长时间才能完成。
测试人员进行代码测试 ,包括功能测试、代码测试、压力测试等
最后进阶段就是对产品不断的进化改进和维护阶段,根据用户的使用情况,可能需要对某功能进行修改,bug修复,功能增加等。
瀑布模型是最著名和最常使用的软件开发模型。瀑布模型就是一系列的软件开发过程。它是由制造业繁衍出来的。一个高度化的结构流程在一个方向上流动,有点像生产线一样。在瀑布模型创建之初,没有其它开发的模型,有很多东西全靠开发人员去猜测,去开发。这样的模型仅适用于那些简单的软件开发, 但是已经不适合现在的开发了。
软件开发瀑布模型的优缺点:
优点 | 缺点 |
---|---|
简单易用和理解 | 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量 |
当前一阶段完成后,您只需要去关注后续阶段 | 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。 |
为项目提供了按阶段划分的检查节点 | 瀑布模型的突出缺点是不适应用户需求的变化。 |
敏捷开发(Agile Development) 的核心是迭代开发(Iterative Development) 与 增量开发(Incremental Development) 。
对于大型软件项目,传统的开发方式是采用一个大周期(比如一年)进行开发,整个过程就是一次"大开发"。
迭代开发的方式则不一样,它将开发过程拆分成多个小周期,即一次"大开发"变成多次"小开发",每次小开发都是同样的流程,所以看上去就好像重复在做同样的步骤。
SpaceX 公司想造一个大推力火箭,将人类送到火星。但是,它不是一开始就造大火箭,而是先造一个最简陋的小火箭 Falcon 1。结果,第一次发射就爆炸了,直到第四次发射,才成功进入轨道。然后,开发了中型火箭 Falcon 9,九年中发射了70次。最后,才开发 Falcon 重型火箭。如果SpaceX 不采用迭代开发,它可能直到现在还无法上天。
软件的每个版本,都会新增一个用户可以感知的完整功能。也就是说,按照新增功能来划分迭代。
举例来说,房产公司开发一个10栋楼的小区。如果采用增量开发的模式,该公司第一个迭代就是交付一号楼,第二个迭代交付二号楼…每个迭代都是完成一栋完整的楼。而不是第一个迭代挖好10栋楼的地基,第二个迭代建好每栋楼的骨架,第三个迭代架设屋顶。
虽然敏捷开发将软件开发分成多个迭代,但是也要求,每次迭代都是一个完整的软件开发周期,必须按照软件工程的方法论,进行正规的流程管理。
敏捷开发的第一个好处,就是早期交付,从而大大降低成本。 还是以上一节的房产公司为例,如果按照传统的"瀑布开发模式",先挖10栋楼的地基、再盖骨架、然后架设屋顶,每个阶段都等到前一个阶段完成后开始,可能需要两年才能一次性交付10栋楼。也就是说,如果不考虑预售,该项目必须等到两年后才能回款。 敏捷开发是六个月后交付一号楼,后面每两个月交付一栋楼。因此,半年就能回款10%,后面每个月都会有现金流,资金压力就大大减轻了。
敏捷开发的第二个好处是,及时了解市场需求,降低产品不适用的风险。 请想一想,哪一种情况损失比较小:10栋楼都造好以后,才发现卖不出去,还是造好第一栋楼,就发现卖不出去,从而改进或停建后面9栋楼?
持续集成( Continuous integration , 简称 CI )指的是,频繁地(一天多次)将代码集成到主干。
持续集成的目的,就是让产品可以快速迭代,同时还能保持高质量。它的核心措施是,代码集成到主干之前,必须通过自动化测试。只要有一个测试用例失败,就不能集成。
通过持续集成, 团队可以快速的从一个功能到另一个功能,简而言之,敏捷软件开发很大一部分都要归功于持续集成。
根据持续集成的设计,代码从提交到生产,整个过程有以下几步。
提交
流程的第一步,是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交(commit)。
测试(第一轮)
代码仓库对commit操作配置了钩子(hook),只要提交代码或者合并进主干,就会跑自动化测试。
构建
通过第一轮测试,代码就可以合并进主干,就算可以交付了。
交付后,就先进行构建(build),再进入第二轮测试。所谓构建,指的是将源码转换为可以运行的实际代码,比如安装依赖,配置各种资源(样式表、JS脚本、图片)等等。
测试(第二轮)
构建完成,就要进行第二轮测试。如果第一轮已经涵盖了所有测试内容,第二轮可以省略,当然,这时构建步骤也要移到第一轮测试前面。
部署
过了第二轮测试,当前代码就是一个可以直接部署的版本(artifact)。将这个版本的所有文件打包(tar filename.tar * )存档,发到生产服务器。
回滚
一旦当前版本发生问题,就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接,指向上一个版本的目录。
Jenkins 是一款流行的开源持续集成(Continuous Integration)工具,广泛用于项目开发,具有自动化构建、测试和部署等功能。可以访问官网了解更多。
Jenkins的特征:
我们介绍两种方式安装Jenkins,一种是基于Linux,另一种是基于Docker。
安装JDK
Jenkins需要依赖JDK,所以先安装JDK1.8,使用yum自动安装的目录为:/usr/lib/jvm
。
yum install java-1.8.0-openjdk* -y
获取jenkins安装包
我们可以去这个页面进行下载。
将安装包上传到Linux,并安装
# 根据自己下载的版本进行安装
rpm -ivh jenkins-2.190.3-1.1.noarch.rpm
修改Jenkins配置
JENKINS_USER="root"
JENKINS_PORT="8888"
启动Jenkins
如果不是本地的1虚拟机,是类似阿里云的云服务器,要记得开放防火墙的端口和设置安全组规则。
systemctl start jenkins
测试访问
http://192.168.66.101:8888
获取并输入admin账户密码
jenkins的图形化界面是给了一个默认的账号密码,需要我们去指定的路径进行查看。
cat /var/lib/jenkins/secrets/initialAdminPassword
**安装Jenkins前得先安装Maven!**我使用的是基于Docker安装的。
在宿主机创建一个jenkins-data的本地数据卷
我的创建目录为:/usr/soft/jenkins-data
在终端窗口输入
docker run \
-u root \
-d \
# 第一个是宿主机的端口也就是图形化管理界面的端口,第二个是Jenkins端口
-p 8080:8080 \
-p 50000:50000 \
# 这里改为你的本地数据卷
-v jenkins-data:/usr/soft/jenkins-data \
# 这里改为你的maven目录
-v /usr/soft/maven3.6:/usr/soft/maven3.6 \
-v /var/run/docker.sock:/var/run/docker.sock \
-e MAVEN_HOME=/usr/local/maven-3.6.3 \
--network=host \
jenkinsci/blueocean
下载完后界面会出现一串长长的数字
这个数字就是容器1的id,我们可以根据id查看日志是否安装成功。
# 容器id写上前四五位即可
docker logs -f 容器id
启动成功!
无论是基于Linux还是Docker安装的,接下来的步骤都是一样的1,那就是去Jenkins的图形化界面进行配置。
访问主页面
访问ip+8080(如果配置了其他端口自行去变化)访问到图形化界面的主页。
去查找初始密码
我们需要进入到容器内去查找初始密码,如果是Linux安装的就直接在本地服务器找即可。
# 查看正在允许的容器,拿到容器id
docker ps
# 进入到容器中
docker exec -it 947a /bin/bash
# 去查询初始密码
cat /var/jenkins_home/secrets/initialAdminPassword
把这一串数字复制到浏览器中即可。
继续,点击安装推荐插件
开始安装插件
自定义一个账号来进行登录,牢记
配置访问地址
重启再登录即可
完工
配置插件镜像加速
Jenkins 默认是从外网的插件仓库下载插件的,速度在国内来说就慢了很多,我们可以通过将插件地址修改为国内镜像仓库,即可提升插件的下载速度。
我们首先需要进入到刚刚配置好的本地数据卷的位置然后进入到updates目录。
# 进入到update目录
cd /usr/soft/jenkins-data/updates
# 执行
sed -i 's/http:\/\/updates.jenkins-ci.org\/download/https:\/\/mirrors.tuna.tsinghua.edu.cn\/jenkins/g' default.json && sed -i 's/http:\/\/www.google.com/https:\/\/www.baidu.com/g' default.json
再点击系统设置->插件管理,进入到插件的设置界面。
点击高级,英文版本应该为advance
往下拉找到升级站点(Update Site),把里面的1URL改为国内的网址。
https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
提交后,在浏览器输入:ip+端口/restart, 重启 jenkins。
安装插件
我们可以利用Role-based Authorization Strategy 插件来管理Jenkins用户权限。
开启权限全局安全配置
授权策略切换为"Role-Based Strategy",保存
创建角色
在系统管理页面进入 Manage and Assign Roles
点击manage roles
Jenkins提供了三种不同的角色:
Global roles(全局角色):管理员等高级用户可以创建基于全局的角色。
Project roles(项目角色):针对某个或者某些项目的角色 。
Slave roles(奴隶角色):节点相关的权限。
我们添加以下三个角色进行测试:
保存后就开始创建用户了。
创建用户
我们分别创建两个用户:ls和zs
给用户分配角色
系统管理页面进入Manage and Assign Roles,点击Assign Roles
绑定规则如下:
保存测试即可。
测试
凭据可以用来存储需要密文保护的数据库密码、Gitlab密码信息、Docker私有仓库密码等,以便Jenkins可以和这些第三方的应用进行交互。
可以添加的凭证大致有六种,常用的凭证类型有:Username with password(用户密码)和SSH Username with private key(SSH密钥)。
安装Credentials Binding插件
要在Jenkins使用凭证管理功能,需要安装Credentials Binding插件
新建任务
创建一个自由风格的软件项目
去idea中新建一个maven项目并上传到gitee备用
我们有两种拉取代码的方式,一种是基于HTTPS,另一种是基于1SSH(公钥加密,私钥解密)。
点击源码
选个Git,在URL上1填写HTPPS的地址。
添加凭证
选择我们刚刚创建的凭据
点击保存
开始构建
在这里可以看到我们的构建信息
去控制台查看构建信息。
大功告成!
SSH免密登录示意图。
和HTTPS不同的是,基于SSH的需要先去仓库里面拿到公钥和私钥。
生成公钥和私钥
# 进入容器里面
docker exec -it 5cfa0 /bin/bash
# 生成公钥和私钥
ssh-keygen -m PEM -t rsa
# 一路空格
我们可以在这个路径查看到生成的公钥和私钥。上面是私钥的,下面是公钥。
# 查看和私钥
cd /root/.ssh
# 查看公钥
cat id_rsa.pub
# 查看私钥
cat id_rsa
我们把公钥、私钥保存下来备用。
添加公钥
复制SSH地址
这里写上你的SSH地址。
添加凭证
选择SSH类型
填写私钥
添加SSH凭证
。保存后测试构建
查看结果
利用建立软连接的方式来配置环境变量,当然也可以使用传统的方式进行配置,我这里使用软连接的方式,软连接方式简单来说就是一个超链接。
# 前面是maven的路径,根据个人修改,后面是固定的,是mvn命令的地方
ln -s /usr/soft/maven3.6/bin/mvn /usr/sbin/mvn
# 输入mvn -v测试
mvn -v
修改maven下载jar的的镜像,使用国内的阿里云,可以提高速度。
# 去到maven的setting.xml目录
cd /usr/soft/maven3.6/conf
# 编辑
vim setting.xml
找到添加镜像的地址。
添加阿里云镜像。
<mirror>
<id>alimavenid>
<mirrorOf>centralmirrorOf>
<name>aliyun mavenname>
<url>http://maven.aliyun.com/nexus/content/repositories/central/url>
mirror>
集成jdk
在容器中查询1jdk的安装目录。
# 找到jdk的安装目录,复制到bin目录出来备用
find / -name java
先新增一个JDK。**把前面的√去掉,**因为我们不是自动安装,我们已经安装好了。
集成maven
往下拉找到构建,增加构建步骤,我们使用shell脚本的方式进行。
我们输入测试的shell命令。
mvn clean package
再次构建,如果可以把项目打成war包,代表maven环境配置成功啦!
看到这里,说明maven和阿里云镜像配置成功。
先在阿里云安装Tomcat,如果不会的可以参考之前的博客:阿里云Linux安装软件第三期——Tomcat我们走!
修改tomcat-users.xml
添加内容。
<tomcat-users>
<role rolename="tomcat"/>
<role rolename="role1"/>
<role rolename="manager-script"/>
<role rolename="manager-gui"/>
<role rolename="manager-status"/>
<role rolename="admin-gui"/>
<role rolename="admin-script"/>
<user username="tomcat" password="tomcat" roles="manager-gui,manager- script,tomcat,admin-gui,admin-script"/>
tomcat-users>
修改context.xml
# 进入到context.xml的目录
cd /usr/soft/tomcat9/webapps/manager/META-INF
# 修改文件
vi context.xml
#注释掉这一行
<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />
修改servel.xml
我们需要将端口修改为除8080之外的端口,我改为了80端口
启动Tomcat
# 进入bin目录
cd /usr/soft/tomcat9/bin
# 启动Tomcat
./startup.sh
弹框输入我们刚刚配置的账号密码(都是tomcat)。
大功告成!集成Tomcat。
Jenkins中自动构建项目的类型有很多,常用的有以下三种:
每种类型的构建其实都可以完成一样的构建过程与结果,只是在操作方式、灵活度等方面有所区别,在实际开发中可以根据自己的需求和习惯来选择。但是总的来说还是流水线项目使用居多,因为他更灵活。
创建一个任务
配置源码管理
构建打包
echo "开始编译和打包"
mvn clean package
echo "编译和打包结束"
立即构建测试
安装Deploy to container Plugin插件
Jenkins本身无法实现远程部署到Tomcat的功能,需要安装Deploy to container Plugin插件实现。
添加Tomcat凭证
添加构建步骤
按照上面的自由风格项目的构建,我们添加构建步骤。
echo "开始编译和打包"
mvn clean package
echo "编译和打包结束"
添加构建后操作
配置好后
开始测试
使用IP+端口访问发现可以访问到页面。
安装Maven Integration插件
Jenkins 专门为 Maven 类型项目提供了一种构建方式,不过需要先下载一个 maven integration
的插件,即可在创建构建项目时选择 Maven 项目,可以比较快捷的完成项目的构建操作。
创建Maven项目
配置项目
拉取代码和远程部署的过程和自由风格项目一样,只是"构建"部分不同
构建测试
Pipeline,简单来说,就是一套运行在 Jenkins 上的工作流框架,将原来独立运行于单个或者多个节点的任务连接起来,实现单个任务难以完成的复杂流程编排和可视化的工作。
安装Pipeline插件
按照我上面的步骤去按照Jenkins,默认是装好Pipeline 插件的。
创建一个流水线项目
Pipeline语法书写
我们有两种方式书写Pipeline的语法:
对于生成的模板的解析:
我们书写一个简单的来进行测试。
pipeline {
agent any
stages {
stage('pull code') {
steps {
echo 'pull code'
}
}
stage('build project') {
steps {
echo 'build project'
}
}
stage('publish project') {
steps {
echo 'publish project'
}
}
}
}
点击构建进行测试。
刚才我们都是直接在Jenkins的UI界面编写Pipeline代码,这样不方便脚本维护,建议把Pipeline脚本放在项目中(一起进行版本控制),这是企业中常用的方式。
很多的步骤都是Jenkins为我们写好的,我们只需要引入进来稍加修改即可使用。点击流水线语法即可看到官方写好的模板。
选择checkout选项,这个是从Gitee上拉取代码的模板。
点击生成流水线脚本。我们先生成拉取代码的脚本。
再生成部署代码的脚本。在刚刚的生成器中,选择deploy这个是生成部署的代码。
将所有1生成好的脚本复制下来备用。然后在根目录创建一个名为Jenkinsfile的文件(必须叫这个名字),在原来的模板的1基础上添加真正的业务逻辑代码,在这里再添加一个打包的命令。
pipeline {
agent any
stages {
stage('拉取代码') {
steps {
checkout([$class: 'GitSCM', branches: [[name: '*/master']], extensions: [], userRemoteConfigs: [[credentialsId: 'xiaolin_demo1', url: 'https://gitee.com/XiaoLin_Java/xiaolin_demo1.git']]])
}
}
stage('编译构建') {
steps {
sh label: '', script: 'mvn clean package'
}
}
stage('deploy') {
steps {
deploy adapters: [tomcat9(credentialsId: 'tomcat', path: '', url: 'http://101.200.146.2:80')], contextPath: '/', war: 'target/*.war'
}
}
}
}
我们在流水线的配置中1告诉Jenkins我们的Jenkinsfile脚本文件在哪里?
我们的流水线定义就不再使用原来的在线输入的方式,因为我们的脚本文件已经上传到Gitee中,所以我们使用Gite的方式,让Jenkins去1我们的远程仓库读取即可。
构建然后访问测试即可。
下载Publish Over SSH插件
构建触发器就是可以配置一些规则,当这些规则被触发时则自动的进行项目的构建操作,Jenkins内置4种构建触发器:
实际上就是通过 url + token 的方式来进行远程触发构建,你可以在构建触发器处选择 “触发远程构建”,并且设置对应的token 即完成配置了,然后通过提示的 url 地址再加上刚刚配置的 token 请求一次,即触发一次构建。
在配置完以后,下方会显示网址,你一旦访问就会触发构建,要把网址变量中的JENKINS_URL和TOKEN_NAME切换成自己的Jenkins的地址(http://ip:端口)以及token。
访问测试发现会自动构建。
有些项目之间可能存在着一些依赖关系,需要先启动依赖项目再启动自身,那么此时就可以在项目中配置其他项目构建后触发,当依赖项目构建完成后会立即构建该项目。
我们去构建xiaolin_demo7之后会发现该工程(xiaolin_demo8)被构建了。
通过配置定时任务,可以指定项目在指定的时间周期性的进行部署,他有一些常用的定时表达式。
# 在构建触发器中选择定时构建,并在日程表中配置定时规则:分 时 日 月 周
# 表达式例子:
# 每30分钟构建一次:H代表形参
H/30 * * * *
# 每2小时构建一次:
H H/2 * * *
# 每天的8点,12点,22点各构建一次
0 8,12,22 * * *
# 每天中午12点定时构建一次
H 12 * * *
# 每天下午18点定时构建一次
H 18 * * *
# 每个小时的前半个小时内的每10分钟各构建一次
H(0-29)/10 * * * *
# 每两小时一次,每个工作日上午9点到下午5点(也许是上午10:38,下午12:38,下午4:38)
H H(9-16)/2 * * 1-5
定时的检查代码仓库是否有新的提交,如果有就立刻进行构建。直接在构建触发器中选择 “轮询 SCM” 并在日程表中设置定时规则,定时任务表达式与定时构建表达式语法一致 。
轮询SCM的构建方式,Jenkins会定时扫描本地整个项目的代码,增大系统的开销,不建议使用。