| 编辑推荐: |
本文主要介绍了产品如何编写backlog、怎么准备sprint计划、如何做回顾、如何做测试、如何管理scrum团队等基础的一些敏捷知识。
本文来自于csdn，由火龙果软件Alice编辑推荐。 |
|
前言：
感谢之前带领过我的leader，让我能够知道什么是好的开发方法。
在很早之前就接触过敏捷开发。什么是敏捷开发，简单来说就是让软件可靠地，快速地发布出来的一种开发方法和技巧。
而敏捷开发中有许多的实践，可能并不是每一种实践都适合于你的团队，但是总有一种能帮助你们的团队快速地将软件可靠地，高可用地发布出来。
如果在读这篇文章之前，还没有接触过敏捷开发，那么推荐一门敏捷开发入门的书籍：《硝烟中的scrum和xp》，这本书是一本敏捷开发的入门入籍，介绍了诸如：产品如何编写backlog、怎么准备sprint计划、如何做回顾、如何做测试、如何管理scrum团队等基础的一些敏捷知识。这本书帮助了很多人了解了敏捷开发，是一本很经典的敏捷入门引导书。
至于关于持续交付的入门入籍，附上链接，欢迎下载持续交付-发布可靠软件的系统方法
chapter 1: 为什么要使用持续交付
在我们的开发部署工作中，有一些典型的反人类发布软件模式：
1.手工部署软件
无论是自己编写的系统，还是系统所需的一些软件：mysql、redis、git等，统统都是用手动部署的方式，每次需要发布、更新，都要连接到服务器上，手动地部署其新版本(例如：先将本地的war包上传到服务器的tomcat中，然后服务器上kill
-9 xxx，重新启动tomcat这样)，23333。。且不说这样部署的人力成本很大，不知道部署的软件是否有bug。并且还有一定的出错机率，在互联网竞争如此激烈的今天，这样的部署，肯定是不行的。
试想，如果有一种方法，当你本地Push代码之后，只需要在网页上点击一个按钮，或者点击按钮这一步都省略掉，再倒上一杯咖啡，你的系统已经部署到线上环境了，这样的自动化，不是更人性化吗
2.开发完成后才向类生产环境部署
很多团队表示，我们一定要把系统全部coding完成，才向(类)生产环境部署系统，这样有一个好处，就是大家更加专注于coding。不被打扰。但是也有一个坏处，就是无法及时反馈出系统中的问题，你的boss也无法知道系统究竟开发到什么程度，boss也无法向客户/他的boss展示项目的进程。
及时反馈在软件开发中是非常重要的，反馈得及时，能帮助软件能快速发现并解决掉软件中很多典型的问题：
(1)开发出的功能和boss想要的功能不一样
(2)软件开发中没被发现的bug
(3)页面实现和UI设计不一致等等。。。
那么有的人就会说，每部署一次都非常麻烦，需要打包、上传、部署配置、部署系统，而且容易出错。一旦部署失败，还要去看日志，找到bug并且修复后，重复以上的全部操作。
今天我们要讲解的jenkins就是解决这个问题的，只需要点击一个按钮就可以部署git上的代码，是不是特别方便。
3.生产环境纯手工配置管理
将配置文件、变量都通过手工的方式去部署是非常不科学的，这不仅需要一个部署专家，若是哪天这个专家请假或者离职，那么你们的团队便无法部署了。而且手工部署还极其容易出错，多台服务器，需要多次重复部署。
自动化是必然的趋势，那么典型的解决方案就是使用某个配置管理软件，或者将配置放在某个具体的脚本中，这样会使软件发布轻松很多
chapter 2: jenkins介绍
jenkins是一个开源软件项目，基于java开发的一款持续集成（Continuous Integration）工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。
一切的目的都是快速反馈。
喏，下面就是这货的图标
猥琐中带着一丝优雅，23333。
jenkins的标语:
“Build great things at any scale”
“以任何规模建造伟大的事情”Jenkins，之前叫做Hudson，所以如果你在jenkins的很多地方，看到hudson这个单词，一定要知道他是jenkins的旧名字。
Jenkins是基于Java开发的一种持续集成工具，用于监控秩序重复的工作，包括：
1)、持续的软件版本发布/测试项目。
2)、监控外部调用执行的工作。
下面是一个官网的简单图形介绍：
chapter 3: jenkins安装和配置
上面介绍了那么多，估计你也没看，我们关心的只有软件的使用方法(23333)。那么我们下面就进入jenkins的安装和配置
环境准备：
首先，你的机器上面，需要安装jdk、git、maven相关的运行环境，我这里使用的jdk1.8、maven3.3.9、git2.16.2
jenkins安装:
下载地址https://jenkins.io/download/，仅下载war包。这个下载就不需要截图了吧。
得到war包后，有两种运行jenkins的方式
1.将war包放在tomcat的webapps目录下，启动tomcat
2.命令启动 java -jar 下载的war包名.war --httpPort=9004
第二种方式启动后，会在/home/xxxxx/.jenkins文件夹下构建jenkins的目录。
你想知道第一种在哪构建这个目录？我也不知道，自己试试咯，启动后日志中有显示位置
用浏览器访问http://localhost:9004 (tomcat启动，访问http://lcoalhost:9004/jenkins)，得到以下页面
然后输入密码就可以了。。
密码，你不知道什么密码？图片中红色的部分不是已经说了密码在哪里了吗。打开文件，copy，paste就行了。
接下来就到了插件配置页面，建议翻墙进行安装所需要的插件，或者现在直接选择skip plugin installations跳过
设置成功之后，就跳转到用户名密码配置页面，这个用户名和密码用于以后的jenkins登录
这是你之后用来登录的用户名密码，最好记住哦~
当当当当~~到这里，你的Jenkins已经配置成功了，成功进入jenkins的主页了！恭喜恭喜
那么接下来，我们就要开始搭建自动化部署的pipeline了。
什么，你说什么是Pipeline？好吧，简单讲解一下
喏，就是上面这货，三个模块，第一个模块是构建模块，用来执行单元测试+build项目形成二进制文件，由于我使用的是Springboot，所以得到的是一个jar包。第二个模块是部署模块，当第一个模块构建成功（变绿），才会触发第二个模块，如果第一个模块单元测试或者运行失败，当前模块就会变红，那么就不会运行第二个模块，当然，这个触发是自己配置的。第三个模块，就是线上环境了，第二个模块运行成功后，就开始运行第三个模块。
当你push了代码之后，只需要点击上面的Run那个按钮，你的系统就已经部署到线上了，是不是很神奇。
你想要搭建这个玩意，首先，你需要给Jenkins安装几个插件，点击这里安装插件
进去了之后，根据下图进行安装插件哦
你需要安装的插件有：
Build pipeline Plugin：没有这个，就没有PipeLine视图
Build Time Out：构建超时插件
Deploy to Container Plugin：部署容器插件
Email Extension Plugin：发送邮件插件
Git
JDK Tool Plugin
PipeLine
Publish over ssh
Timestamper
Workspace Cleanup Plugin
安装好以上插件后，进入上图的installed，勾选上以上的这些插件，使其开启使用。
配置好上述插件，接下来我们就要来配置JDK，Maven，git环境了
注意：这些环境必须配置。
(这里有一个小小的插曲，当初我并没有配置这些环境，以为Jenkins默认带有的这些插件环境可以生效，傻傻地运行等待了两个小时。然而事实证明，并没有什么卵用，必须要配置这些东西。)
在上上张图中，点击
进行配置
你需要配置以下的东东，首先是JDK
将JDK配置到相应的bin目录上级，也就是你的$JAVA_HOME位置
然后配置Git
注意：这个git有点日怪，他不是配置到bin目录上级，需要配置到具体的可执行文件位置！看上图中的文字Path
to git executable。如果换成Java的话，就应该配置$JAVA_HOME/bin/javac
这个级别的，可执行文件~
最后配置Maven
这里也是配置MAVEN_HOME哦。到bin目录上级就可以了
在配置maven的setting.xml时，建议加上阿里的mirror，这样运行时，下载依赖的速度可以快几倍
在setting.xml中的<mirrors>标签中添加以下代码即可
</mirror> 上述的Maven、JDK、Git软件安装就不再赘述。自行百度。
一切配置成功后，最好重启下jenkins使上面的插件和环境生效，接下来开始构建Pipeline
回到首页，点击new Item 先创建个文件夹，方便以后多个项目分组方便
添加文件夹后，你的首页上就会多出一个文件夹
其中outer是我文件夹的名字，名字随意就好
点击outer进入文件夹
再点击左侧的New Item ，然后创建Maven项目
点击OK后进入配置页面、这里有几个地方需要配置
先配置你的源代码所在git位置，branch specifier可以选择你代码的分支
general中配置，显示几天的几个版本的以前的构建信息，方便查看错误日志
Build Triggers中。勾选Poll SCM中的Schedule，这里需要配置一个五位数的表达式
分别代表：分钟，小时，天，月，星期几
例如配置: 5 * * * * 代表每个小时的第五分钟构建
0 0 10 * * 代表每个月10号构建
这个表达式有点像Spring task中的schedule表达式，不清楚的可以去百度了解一下
配置maven的位置以及运行maven的命令，有机智的小伙伴就发现，为什么要使用Maven的package命令，而不是直接spring-boot:run运行呢。呵呵，我试过，运行后会直接阻塞，PipeLine压根看不到结果是否成功，也没法结束。所以只能先打包再运行，运行脚本在第二个模块中
勾选这玩意儿，用于删除以前的项目
最后重点来了，就是下面这货。这个等下再讲，先配置上就行了。
第一步的Maven Project已经构建成功。接下来回到outer文件夹中，选择New
Item ，创建一个freestyle project
build中填写：
BUILD_ID=dontKillMe nohup java -jar /Users/xiangnan/.jenkins/workspace/outer/test_project/target/BootRedis-0.0.1-SNAPSHOT.jar
&
BUILD_ID=dontKillMe nohup + &
的意思是让其springboot运行成功后，到后台去运行，不阻塞当前的pipeline。
当然，这里的脚本只是一个最简单的命令运行脚本，你也可以将脚本放在git中，或者放在服务器上，每次构建就拉取新的脚本并且运行。这是一种思路，脚本的使用可以非常灵活，不一定需要直接运行jar包。
到这里，我们的两个项目就已经构建成功了。但是到现在还没有PipeLine的展示
回到outer文件夹中，点击+按钮，选择build Pipeline View，并输入pipeline的名字
接下来进入pipeline的配置页面，在这个页面中，在pipeline
flow的upstream项，选择之前的maven项目，我的是test_project
最后点击OK。大功告成，你将看到如下页面
这就是我们前文中提到的Build PipeLine。点击Run即可从git上拉代码并运行项目到当前机器中了哦。
先运行第一个test_project，当第一个模块运行单元测试、打包成功后，才会触发运行第二个模块--即部署springboot.jar
那么是怎么触发的呢
我们回到之前没有讲解的一张图
在途中我们配置了几个地方，
Projects to build：当项目构建完成，生成war包后，出发哪个项目
Trigger when build is : stable -- 只有当前项目构建成功后，才开始构建下一个freestyle
project
除了stable还有其他的几个选项
根据需要进行选择需要什么条件去触发下一个模块。例如：Failed，当失败时构建下一个项目
Predefined parameters: 预定义变量，必配
只有配置了预定义变量，才能根据${BUILD_NUMBER} -- 构建号，${GIT_COMMIT}--git提交的版本号，根据这两个变量去触发下一个模块，没有这个配置，就无法触发下一个模块.
总结：
以上。整个Pipeline就部署完成了。但是其实这只是部署的一个入门，提供了一个思路，Jenkins还有很多其他的功能，例如构建失败时发送邮件，自定义脚本，git代码Push完成后立即触发Run等等，Jenkins非常的灵活，功能也非常多，等待你自己去探索。
|
