博客

使用 Bamboo 构建项目的 CICD 过程文档

  • Post author:
  • Post category:其他




一、CI/CD 介绍



CI/CD 是什么？

说明一下：实际上这个应该叫 CI/CD/CD ，才是真正的 持续集成/持续交付/持续部署，这里只讲 CI/CD 是针对特定的项目而言，因为没有生产环境，直接是 开发 -> 测试，所以后面两个 CD 就合并了

CI/CD 中文叫：持续集成，持续交付/部署，是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署，“ 持续 ” 并不意味着 “ 一直在运行 ” ，而是“随时可运行”。


持续集成

：Continuous integration，CI

持续集成（CI）旨在通过对每次提交的代码进行自动化的代码检查，单元测试，编译构建，甚至自动部署与发布，可以有力的避免 “ 集成地狱 ” 问题

在这里插入图片描述


持续交付

：Continuous delivery，CD

在一次集成的基础上，将集成后的代码部署到更贴近真实运行环境中，持续交付并不是指软件的每一个改动都要尽快的部署到生产环境，它是指任何的修改都已证明可以在任何时候实施部署，这就是为什么持续交付是手动部署的，比如：一种业务场需要等待另外的功能特征出才能上线，这时候就没必要上生产环境

在这里插入图片描述


持续部署

：Continuous Deployment，CD

在一次交付的基础上，把最新的代码部署到生产环境

在这里插入图片描述


集成地狱

：交付团队的成员集成一些未合并的代码，也就是一大堆的提交到一个指定的时间点来合并，这种集成的过程很少是流畅和无缝的，经常会出现各种合并的BUG，导致数小时甚至数天来修复代码，以便它能够最终集成



使用了 CI/CD 之后会怎么样



传统开发模式存在的问题

  • 开发完成之后才向测试/生产环境部署

    因为部署工作是由专人手动的，因为觉得繁琐，所以不会对代码的每一次提交都进行一次 审核->测试->发布 的流程，一般都是某个模块或者某个大功能完成之后进行一次

  • 部署到生产环境完全手动

    人为的做一些重复性的动作，难免会出现操作失误，甚至操作错误而导致的一些生产环境上的故障，影响了生产环境的运行，特别是客户的好感度

  • 生产环境的手工配置管理

    手动的对项目的配置进行更改，再手动部署到该运行环境，这些其实都是繁琐，重复又容易出错的一些操作



CI/CD 给我们带来的好处

在这里插入图片描述

  • 提高整体代码质量

    能够及时发现我们的编码规范，BUG，将对测试，生产环境的影响降到最低

  • 自动化代码合并流程

    一些代码检查，单元测试，编译构建甚至部署都是自动的

  • 节省开发成本

    上面说到的一般软件部署是由专人负责的，开发集成了 CI/CD 之后就不需要了

  • 提高了开发效率

    开发人员可以更注重代码的业务逻辑，性能方面，省去了一些其他的麻烦



二、Atlassian – Bamboo 介绍

Atlassian 全称是 Atlassian Open DevOps Utils，它包括 Jira、Confluence、Bitbucket、Bamboo、Crowd



简介

Atlassian Bamboo 是一款持续集成和持续部署工具，可以将自动化构建、测试和发布整合在单个工作流中



Bamboo 的安装



下载


Atlassian 官网

下载 Bamboo 就好了【注意是免费试用 30 天的】



配置



Bamboo 的目录结构

在这里插入图片描述



配置 Bamboo 的 home 目录

# 修改下面文件中的 bamboo.home=随便一个有权限的目录就行
atlassian-bamboo-8.0.2/atlassian-bamboo/WEB-INF/classes/bamboo-init.properties



运行 Bamboo

# 启动 shell 脚本就好了，运行端口在 8085
# 访问：http://localhost:8085/
/atlassian-bamboo-8.0.2/bin/startup.sh

进去之后就会初始化一些东西，跟着页面操作就好了，这里提的一点是选择 Bamboo 的数据源是 MySQL 的话，需要将 MySQL 的连接驱动放在 Bamboo 的依赖库里面，eg：将

mysql-connector-java-8.0.22.jar

放在

/atlassian-bamboo-8.0.2/lib

目录下



配置 Agent

前面步骤配置好了其实还差一步，因为 Bamboo 的每个 Stage(后面会讲) 运行的 Job 需要在一个代理执行器里面执行，这里我使用了 bamboo 推荐的

atlassian-bamboo-agent-installer-8.0.2.jar

,下载之后使用 Bamboo 提供的

java -jar atlassian-bamboo-agent-installer-8.0.2.jar http://127.0.0.1:8085/agentServer/

运行起来，然后看到控制台打印如下信息：

在这里插入图片描述

说 Agent 需要你手动审核通过才能通过，直接复制他给出的地址访问就可以审核了，到这里 Bamboo 算是安装成功了吧。



Bamboo 的特点

1、简单的用户界面，容易安装

2、自动检测你的设置-如果你的 Server 上使用了 Maven、Ant 或者 Java 设置，Bamboo 会自动检测出来

3、连续的日志，检测你的 build 的 Colour Coded 日志，容易显示出所有项目和最后一次 build 的结果摘要列表

4、当 build 被触发时，会显示触发 build 的源代码变更



Bamboo 的工作原理

实际上就是 CI/CD 的工作机理，简单点讲就是开发者提交完代码之后自动触发编译、单元测试、集成测试、打包和部署至服务器的一系列过程，由以下的图片简单描述

在这里插入图片描述

​ CI/CD 工作机理



Bamboo 的使用

在这里插入图片描述

​ 自动构建计划


解释说明：

1、Project 是一个项目的构建计划的集合，管理某个项目的所有 Plan

2、计划（Plan）则是 Stage、Task 和 Job 的集合，一个构建计划。当创建一项计划的时候，会为它赋予一个唯一主键，说明从哪个库中（或者哪些库中）提取代码，然后选择它的触发器如使用每次发布定期构建，等等。也有将几个管理选项设置成全局缺省值并在计划层次调整。这些选项包括权限、通知、日志和构建清除、提升构建标准、以及变量。

3、阶段（Stage）代表一个阶段，按规定次序进行，并行的处理 Job（用多个 Agent ），只有所有的 Job 成功，才会进入下一个 Stage，用来控制工作流的执行，例如可以将构建分为编译，测试开发。阶段之前可以定义前后级关系从而控制执行。可能会产生 Artifact（项目打包之后的产物），供后续的 Stage 使用

4、由多个 Task 可以组成一个 Job，在同一个 Job 的代理服务器上，顺序执行多个 Task。

5、Task 是进行自动化构建的基本块，这些任务可以检查源代码，运行脚本，构建引擎的调用，如 Ant，Maven以及生成报表等，Task 是顺序执行的。



三、项目从创建到自动部署实战

首先看下测试应用之前的运行效果：

在这里插入图片描述



CI 配置



创建 Project

Build Plan 需要基于 Project 创建，所以需要先创建一个 Project

在这里插入图片描述



创建并配置 Build Plan



创建 Build Plan

在这里插入图片描述



配置 Build Plan

在这里插入图片描述



配置 Stage



配置 Job

不添加 Job 直接点击 Save and continue 继续下一步，如果需要添加 Job，则点击 Create

在这里插入图片描述



配置 Stage

这里配置两个阶段：Test Stage 和 Package Stage，测试和打包阶段

1、Test stage 是进行测试的阶段，测试任务都放在这个阶段中进行, 创建 Build plan 后会存在一个 Default Stage，可以直接将其名称改为 Test Stage，同时也可以将默认的 Default Job 更名为 Test Job

在这里插入图片描述

2、Package Stage 是进行项目打包阶段，测试阶段完成之后，所有的项目打包工作都在这里进行

在这里插入图片描述



Task 类型

点击 Add Task，弹出各种 Task 类型，这里我们主要使用了 Maven3.X（Maven 的构建操作） 、SSH Task （SSH 命令操作）以及 SCP Task（文件上传，拷贝操作）

在这里插入图片描述



配置 Task 注意事项

值得注意的是：拉取代码的操作一定要存在，以及 Task 的执行顺序

在这里插入图片描述



给 Test Stage 的 Test Job 添加 Maven 测试 Task

在这里插入图片描述

在这里插入图片描述 

clean test

同样的操作，给 Package Stage 配置一个 Package Job 之后，再给它配置一个 Package Task，这里就不列出图片，只需更改如下设置就行 **

在这里插入图片描述 

clean package



配置 Artifact


Artifact: 是项目编译打包之后的产物，Bamboo 这里需要配置所需要的产物文件，以供后续的阶段可以使用，需要提供哪几个 artifact 是根据后续部署/交付任务所需的资源决定的，例如，对于后续开发环境的持续交付，这里需要 Dockerfile、docker-compose-{部署环境}.yml、Application（可执行 jar）


在这里插入图片描述


构建好之后：


在这里插入图片描述


到这里，我们 CI（持续集成）配置完毕！



CD 配置



创建 Deployment project

在这里插入图片描述



配置 Deployment Project



创建部署环境

添加一个部署环境

在这里插入图片描述

这一步很重要，主要设置两步，Set up tasks 和 添加一个触发整个构建流程的动作

在这里插入图片描述



完成部署的 Task 配置

当点击了 Set up tasks 之后，出现如下配置，这里主要添加如下 Task：

  • SSH Task：在部署服务器上的项目根目录
  • SCP Task：将 artifact 上下载的文件上传到项目目录
  • SSH Task：构建 Docker 镜像，停止之前运行的容器，重新跑新镜像

    在这里插入图片描述


以上 3 个 Task 的详细配置


在这里插入图片描述 

TEMP_PATH="/tmp/build-xh-test-qiukm/xh-test-qiukm"
if [ ! -d $TEMP_PATH ];
    then mkdir $TEMP_PATH
fi

在这里插入图片描述

在这里插入图片描述 

TEMP_PATH="/tmp/build-xh-test-qiukm/xh-test-qiukm/"
NAME="whalex-ms-test-dev"
YAML="docker-compose-dev.yml"
PROJECT_NAME="whalex-cluster-test-dev"
TAG="release-"${bamboo.buildNumber}
cd $TEMP_PATH
if [[ -a ".env" ]];
then rm -rf .env
fi
echo IMG_TAG=$TAG >> .env
docker build -t $NAME:$TAG .
docker-compose -f $YAML -p $PROJECT_NAME stop;
docker-compose -f $YAML -p $PROJECT_NAME up -d



配置触发构建 Trigger

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述


到此我们的 CD（持续交付/部署）配置也完成！



执行流程



代码更改

在这里插入图片描述



代码提交

将代码提交到仓库，触发构建流程



构建日志



CI（持续集成）日志

在这里插入图片描述



CD（持续部署）日志

在这里插入图片描述



访问接口

在这里插入图片描述


版权声明：本文为qq_42378797原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。