1 项目考虑维度

Dev：怎么开发
Ops：怎么运维
⾼并发：怎么承担⾼并发
⾼可⽤：怎么做到⾼可⽤

2什么是DevOps

微服务、服务⾃治
DevOps：Develoment和Operations的组合
DevOps：看作开发（软件⼯程）、技术运营和质量保证（QA）三者的交集。
突出重视软件开发⼈员和运维⼈员的沟通和合作，通过⾃动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠
DevOps希望做到的是软件产品交付过程中IT⼯具链的打通，使得各个团队减少时间损耗，更加⾼效的协同⼯作，专家们总结了下⾯这个DevOps能⼒图，良好的闭环可以⼤⼤的增加整体的产出。

3 什么是CI&CD

3.1 持续集成

持续集成是指软件个⼈研发的部分向软件整体部分交付，频繁的进⾏集成以便更快的发现其中的错误。
“持续集成”源⾃极限编程（XP）是XP最初的12中实践之⼀。
CI需要具备这些：
全⾯的⾃动化测试：实践持续集成&持续部署的基础，同时，选择合适的⾃动化测试⼯具也极其重要
灵活的基础设施，容器，虚拟机的存在让开发⼈员和QA⼈员不必再⼤费周折
版本控制⼯具。如Git,CVS,SVN等。
⾃动化的构件和软件发布流程⼯具，如Jenkins
反馈机制。如构建、测试失败，可以快速的反馈到相关的负责⼈，以尽快的解决达到⼀个更稳定的版本

3.2 持续交付

持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实的运⾏环境（类⽣成环境）中，持续交付优先于整个产品⽣命周期的软件部署，建⽴⾼⽔平⾃动化持续集成之上
灰度发布
持续交付和持续集成的优点⾮常相似
快速发布，能够应对业务需求，并更快的实现软件的价值
编码->测试->上线->交付的频繁迭代周期缩短，同时获得迅速的反馈
⾼质量的软件发布标准。整个交付过程标准化，可重复，可靠
整个交付过程进度可视化，⽅便团队⼈员了解项⽬成熟度
更先进的团队协作⽅式。从需求分析，产品的⽤户体验到交互，设计，开发，测试，运维等⻆⾊密切协作，相⽐于传统的瀑布式软件团队，更少浪费

3.3持续部署

持续部署是指交付的代码通过评审之后，⾃动部署到⽣成环境，持续部署是持续交付的最⾼阶段，这意味着，所有通过了⼀些列⾃动化测试的改动都将⾃动部署到⽣成环境，他可以被称为"Continuous Release"

开发⼈员提交代码，持续集成服务器获得代码，执⾏单元测试，根据测试结果决定是否部署到预演环境，如果成功部署到预演环境，进⾏整体的验收测试，如果测试通过，⾃动部署到产品环境，全⾃动化⾼效运转

持续部署的主要好处是，可以相对独⽴的部署新的功能，并能快速的收集真实⽤户的反馈

“youbuild it , you run it”, 这时Amazon ⼀年可以完成5000万次部署，平均每个⼯程师每天部署超过50次的核⼼秘籍

4 使用Jenkinsfile创建流水线

Jenkinsfile 是⼀个⽂本⽂件，它包含了 Jenkins 流⽔线的定义并被检⼊源代码控制仓库。由于将整个⼯作流存储为代码，因此它是代码审查和流⽔线迭代过程的基础。有关更多信息，请参阅 Jenkins官⽅⽂档

演示如何基于 GitHub 仓库中的 Jenkinsfile 创建流⽔线。 使⽤流⽔线，您可以将示例应⽤程序分别部署到可从外部访问的开发环境和⽣产环境。

备注

在 KubeSphere 中可以创建两种类型的流⽔线： 可以使⽤基于 SCM 中的 Jenkinsfile 创建的流⽔线或者通过图形编辑⾯板创建的流⽔线。Jenkinsfile in SCM 意为将 Jenkinsfile ⽂件本身作为源代码管理(Source Control Management) 的⼀部分，KubeSphere 根据该⽂件内的流⽔线配置信息快速构建⼯程内的 CI/CD 功能模块，⽐如阶段 (Stage)，步骤 (Step) 和任务 (Job)。因此，在代码仓库中应包含Jenkinsfile。

先决条件

1. 您需要有⼀个 Docker Hub 帐户和⼀个 GitHub帐户。

注册docker hub 账户
(动作：本地程序 快照 push 到docker hub里，再把镜像拉下来进行开发环境的测试)
2. 您需要启⽤ KubeSphere DevOps 系统。
3. 您需要创建⼀个企业空间和⼀个具有项⽬管理 ( project-admin )
权限的帐户，该账户必须是被赋予企业空间普通⽤户⻆⾊。如果还没准备好，请参考创建企业空间、项⽬、帐户和⻆⾊ 。（之前我们已经创建好了admin角色的账户）
4. 您需要为运⾏流⽔线设置 CI 专⽤节点。请参阅为缓存依赖项设置 CI 节点.
5. 您需要安装和配置 SonarQube。 请参阅将 SonarQube 集成到流⽔线。
如果您跳过这⼀部分，则下⾯没有SonarQube分析。(它是一个代码质量分析的工具)

流⽔线概览

在此示例流⽔线中，共有⼋个阶段，下⾯的流程图简单说明了流⽔线完整的⼯作过程：

备注
阶段 1. Checkout SCM: 拉取 GitHub 仓库代码。（springboot输出一句hello world）
阶段 2. Unit test: 单元测试，如果测试通过了才继续下⾯的任务。
阶段 3. SonarQube 质量检测: sonarQube 代码质量检测。
阶段 4. Build & push snapshot image: 根据⾏为策略中所选择分⽀来构建镜像，并将 tag 为SNAPSHOT-$BRANC{H}_{N}AME-$BUILD_NUMBER 推送⾄ Harbor (其中 $BUILD_NUMBER 为pipeline 活动列表的运⾏序号)。
阶段 5. Push the latest image: 将 master 分⽀打上 tag 为 latest ，并推送⾄ DockerHub。
阶段 6. Deploy to dev: 将 master 分⽀部署到 Dev 环境，此阶段需要审核。
阶段 7. Push with tag: ⽣成 tag 并 release 到 GitHub，并推送到 DockerHub。
阶段 8. Deploy to production: 将发布的 tag 部署到 Production 环境。

动⼿实验

步骤 1: 创建凭证

1. ⽤项⽬普通⽤户 ( project-regular ) 登陆 KubeSphere 控制台。转到您的 DevOps 项⽬，然后在⼯程管理下的凭证中创建以下凭据。 有关如何创建凭证的更多信息，请参阅凭证管理.
   
   

备注
如果您的帐户或密码中包含任何特殊字符，例如 @ 和 $ ，它们可能会在流⽔线运⾏时导致错误，因为它们可能⽆法识别。 在这种情况下，您需要先在某些第三⽅⽹站（例如 urlencoder ） 上对帐户或密码进⾏编码。 之后，复制并粘贴输出以获取您的凭证信息。

(下面这步骤先不做了，不做代码质量分析)
2. 您需要为 SonarQube 创建⼀个附加的凭证 ID（ sonar-token ），该 ID 在上述第3阶段（SonarQube 分析）中使⽤。 请参阅为新项⽬创建 SonarQube Token，以将Token 填⼊以下token/ 密码 字段。 单击确定完成。

3. 列表中总共有四个凭证。
GitHub 网速有点慢，这里就用Gitee的账户了。
创建kubeconfig账户

这里我们有三个凭证。

步骤 2: 在 GitHub 仓库库中修改 Jenkinsfile

1. 登录GitHub。 从 GitHub 仓库中将 devops-java-sample fork 到您⾃⼰的 GitHub 帐户。

https://github.com/kubesphere/devops-java-sample.git

如果上述官网链接比较慢的话可以fork我的Gitee地址
https://gitee.com/lybbbb/devops-java-sample

然后修改这个文件：

备注
Jenkinsfile 中 mvn 命令的参数 -o，表示开启离线模式。本教程中已经下载了相关的依存关系，以节省时间并适应某些环境中的⽹络⼲扰。 离线模式默认情况下处于启⽤状态。

步骤 3: 创建项⽬

您需要创建两个项⽬，例如 kubesphere-sample-dev 和 kubesphere-sample-prod ，分别代表开发环境和⽣产环境。 ⼀旦流⽔线成功运⾏，将在这两个项⽬中⾃动创建应⽤程序的相关部署和服务.
备注
帐户 project-admin 需要提前创建，因为它是 CI/CD 流⽔线的审核者。 有关更多信息，请参⻅创建⼯作区，项⽬，帐户和⻆⾊。

1. 使⽤ project-admin 帐户登录KubeSphere。 在相同的企业空间 (workspace) 创建下两个DevOps 项⽬。确保 project-regular 账户以 项⽬维护者 ⻆⾊被邀请到该项⽬。
   
2. 检查项⽬列表。 您有两个项⽬和⼀个DevOps项⽬，如下所示：
   

步骤 4: 创建流⽔线

1. 注销登陆 KubeSphere，然后⽤ project-regular 账户重新登录，跳转到 DevOps ⼯程 demodevops ，然后单击创建构建新流⽔线。
   

2. 在出现的对话框中填⼊基本信息。 将其命名为 jenkinsfile-in-scm 并选择⼀个代码存储库。
   
   注意以下步骤为GitHub的操作，而我们的操作是基于Gitee来进行的。所以直接跳过Gitee进行部署操作

3. 如果您没有 GitHub Token ,在 GitHub 选项卡中，单击 Get Token ⽣成⼀个新的 GitHubToken。 将 Token 粘贴到框中，然后单击确认。
   
   

4. 选择您的 GitHub 帐户。 与该 token 相关的所有仓库将在右侧列出。 选择 devops-java-sample并单击 Select this repo。 单击下⼀步继续。
   
   Gitee操作
   
   
   

5. 在⾼级设置中，选中丢弃旧的分⽀旁边的⽅框。 在本教程中，参数值保留分⽀的天数和保留分⽀的最⼤个数可以使⽤默认。

丢弃旧分⽀意味着您将⼀起丢弃分⽀记录。 分⽀记录包括控制台输出，已归档⼯件以及特定分⽀的其他相关元数据。 更少的分⽀意味着您可以节省 Jenkins 正在使⽤的磁盘空间。 KubeSphere 提供了两个选项来确定何时丢弃旧分⽀：
保留分⽀的天数：在⼀定天数之后，分⽀将被丢弃。
保留分⽀的最⼤个数：分⽀达到⼀定数量后，最旧的分⽀将被丢弃。

备注
值保留分⽀的天数和保留分⽀的最⼤个数 可以同时应⽤于分⽀。 只要某个分⽀的保留天数和个数不满⾜任何⼀个设置的条件，则将丢弃该分⽀。假设设置的保留天数和个数为 2 和 3，则分⽀的保留天数⼀旦超过 2 或者保留个数超过 3，则将丢弃该分⽀。默认两个值为 -1，表示将会丢弃已经被
删除的分⽀。

——————————————————
6. 在⾏为策略中，默认情况下，KubeSphere 提供三种策略。 由于本示例还未⽤到 从 Fork 仓库中发现 PR 这条策略，此处可以删除该策略，点击右侧删除按钮删除即可。

在 Jenkins 流⽔线被触发时，开发者提交的 PR（Pull Request）也将被视为⼀个单独的分⽀。
发现分⽀

排除也作为 PR 提交的分⽀. 选择此项表示 CI 将不会扫描源分⽀ (⽐如 Origin 的 master
branch)，也就是需要被 merge 的分⽀。
只有被提交为 PR 的分⽀. 仅扫描 PR 分⽀。
所有分⽀ 拉取的仓库 (origin) 中所有的分⽀。

从原仓库中发现 PR

• PR 与⽬标分⽀合并后的源代码版本. PR 合并到⽬标分⽀后，将基于源代码创建并运⾏流⽔线。
• PR 本身的源代码版本. 根据 PR 本身的源代码创建并运⾏流⽔线。
• 发现PR时会创建两个流⽔线. KubeSphere 创建两个流⽔线，⼀个基于 PR 合并到⽬标分⽀后的源代码，另⼀个基于 PR
  ————————————————————————————

上面这几个步骤也是GItHub中的。Gitee里没有

本身的源代码。
7. 向下滚动到脚本路径。 该字段指定代码仓库中的 Jenkinsfile 路径。 它指示存储库的根⽬录。 如果⽂件位置更改，则脚本路径也需要更改。 请将其更改为 Jenkinsfile-online，这是位于根⽬录中的
示例仓库中 Jenkinsfile 的⽂件名。

8. 在 扫描 Repo Trigger, 单击 如果没有扫描触发，则定期扫描间隔 设置为 5 分钟。 单击创建完成配置。

备注
您可以设置特定的时间间隔以允许流⽔线周期性地扫描远程仓库，这样就可以根据您在⾏为策略中设置的策略检测仓库有没有代码更新或新的 PR。
如果刷新没有同步过来的话说明是同步有点慢，等一会就行，我以为我配置错了，于是解决配置文件找了一大堆问题，最后过了很久刷新页面发现是同步的时间有点长。

步骤 5: 运⾏流⽔线

1. 创建流⽔线后，它将显示在下⾯的列表中。 单击它转到其详细信息⻚⾯。
   

2. 在活动选项卡下, 三个分⽀正在扫描中。 单击右侧的运⾏，流⽔线将根据您设置的⾏为策略运⾏。
   从下拉列表中选择 sonarqube，然后添加标签号，例如 v0.0.2。 单击确定触发新活动。
   （ sonarqube我们没有配置，所以这里不做测试了。）

备注
如果确实需要在此⻚⾯上看到任何活动，则需要⼿动刷新浏览器或从下拉菜单中单击扫描仓库（更多操作按钮）。
标签名称⽤于在 GitHub 和 Docker Hub 中使⽤标签⽣成发布和镜像。 现有标签名称不能再次⽤于字段 TAG_NAME。 否则，流⽔线将⽆法成功运⾏。

3. 请稍等⽚刻，您会看到⼀些活动停⽌⽽某些失败。 单击第⼀个以查看详细信息。
   
   

备注
队列失败可能是由不同的因素引起的。 在此示例中，在上述步骤中编辑分⽀环境变量时，仅更改了sonarqube 分⽀的 Jenkinsfile。 相反，依赖项和 master 分⽀中的这些变量保持不变（即，错误的GitHub 和 Docker Hub 帐户），从⽽导致失败。 您可以单击它并检查其⽇志以查看详细信息。 失
败的其他原因可能是⽹络问题、Jenkinsfile 中的编码不正确等等。

运行的实际很长的，需要稍微等待一会。运行完成以后是会出现图形化界面的，在运行状态里面可以查看到

4. 流⽔线在 deploy to dev 阶段暂停,您需要⼿动单击继续。请注意，在 Jenkinsfile 中分别定义了三个阶段 deploy to dev 、 push with tag 和 deploy to production ，因此将对流⽔线进⾏三次审核。

在实际开发或⽣产场景中，可能需要具有更⾼权限的管理员（例如版本管理员）来审核流⽔线、镜像以及代码分析结果， 他们有权决定流⽔线是否能进⼊下⼀阶段。在 Jenkinsfile 中， input 步骤可以指定⽤户审核流⽔线。如果您想指定⼀个⽤户(例如 project-admin ) 来审核，您可以在Jenkinsfile 的 input 函数中添加⼀个字段。如果是多个⽤户则通过逗号分隔，如下所示：

···
input(id: 'release-image-with-tag', message: 'release image with tag?',
submitter: 'project-admin,project-admin1')
···

步骤 6: 检查流⽔线状态

1. 在运⾏状态中，您可以查看流⽔线的运⾏⽅式。 请注意，流⽔线在刚创建后将继续初始化⼏分钟。
   示例流⽔线有⼋个阶段，它们已在 Jenkinsfile-online 中单独定义。

2. 通过单击右上⻆的查看⽇志来检查流⽔线运⾏⽇志。 您可以看到流⽔线的动态⽇志输出，包括任何可能导致流⽔线⽆法运⾏的错误。对于每个阶段，您都可以单击它检查⽇志，⽽且可以将其下载到本地计算机以进⾏进⼀步分析。

步骤 7: 验证结果

1. 成功完成流⽔线后，单击代码质量通过 SonarQube 检查结果，如下所示。
2. 正如在 Jenkinsfile 中定义的那样，通过流⽔线构建的 Docker 镜像也已成功推送到 Docker Hub。
   在 Docker Hub 中，您会找到带有标签 v0.0.2 的镜像，该镜像是在流⽔线运⾏之前指定的。
3. 同时，在 GitHub 中⽣成了⼀个新标签和⼀个新版本。
4. 示例应⽤程序将部署到 kubesphere-sample-dev 和 kubesphere-sample-prod ，并创建相应的 Deployments 和 Services。 转到这两个项⽬，这是预期的结果：
   

备注
您可能需要打开安全组中的端⼝，以便通过 URL 访问应⽤程序。

步骤 8: 访问示例服务

1. 请以管理员（ admin ）身份登录 KubeSphere 并使⽤⼯具箱（Toolbox）中的 web kubectl 访问服务。转到项⽬ kubesphere-sample-dev ，然后在应⽤负载下的服务中选择 ks-sample-dev 。
   Endpoint 可⽤于访问服务。

2. 从右下⻆的⼯具箱（Toolbox） 中使⽤ web kubectl 执⾏以下命令：

3. 预期的输出:

备注
使⽤ curl 访问 endpoints 或者 {KaTeX parse error: Expected 'EOF', got '}' at position 11: Virtual IP}̲:{Port} 再或者 {KaTeX parse error: Expected 'EOF', got '}' at position 8: Node IP}̲:{NodePort}

4. 同样，您可以在项⽬ kubesphere-sample-prod 中测试服务，您将看到相同的结果。