CI/CD自动化【核心：①流水线：将开发之后的测试、部署等所有过程定义为流水线；②自动化：将流水线中每个过程编为脚本，可以自动执行】【持续集成（CI）、持续交付/持续部署（CD）】
CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。
CI指持续集成（Continuous Integration），代码的更新会定期构建、测试并合并到主分支；CD可以指持续交付（Continuous Delivery），开发人员对应用的更改会自动进行测试，然后由运维团队部署到生产环境；CD也可以指持续部署（Continuous Deployment），自动将开发人员的更改从存储库发布到生产环境，以供客户使用；
关于CI和CD的具体定义，尚有争议，比如有的定义里，CI包含了CD的内容
实际工作中，整个CI/CD流水线均在硬件配置较高的机器上运行、并且与公司内部的gitlab深度绑定
CI / CD的采用改变了开发人员和测试人员如何发布软件。
最初是瀑布模型，后来是敏捷开发，现在是DevOps，这是现代开发人员构建出色的产品的技术路线。随着DevOps的兴起，出现了持续集成（Continuous Integration）、持续交付（Continuous Delivery） 、持续部署（Continuous Deployment） 的新方法。传统的软件开发和交付方法正在迅速变得过时。从历史上看，在敏捷时代，大多数公司会每月，每季度，每两年甚至每年发布部署/发布软件。然而，现在，在DevOps时代，每周，每天，甚至每天多次是常态。当SaaS正在占领世界时，尤其如此，您可以轻松地动态更新应用程序，而无需强迫客户下载新组件。很多时候，他们甚至都不会意识到正在发生变化。开发团队通过软件交付流水线（Pipeline）实现自动化，以缩短交付周期，大多数团队都有自动化流程来检查代码并部署到新环境。今天，我们将介绍什么是CI / CD / CD，以及现代软件公司如何使用工具将部署代码的流程自动化。
持续集成的重点是将各个开发人员的工作集合到一个代码仓库中。通常，每天都要进行几次，主要目的是尽早发现集成错误，使团队更加紧密结合，更好地协作。持续交付的目的是最小化部署或释放过程中固有的摩擦。它的实现通常能够将构建部署的每个步骤自动化，以便任何时刻能够安全地完成代码发布（理想情况下）。持续部署是一种更高程度的自动化，无论何时对代码进行重大更改，都会自动进行构建/部署。
CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题（亦称：“集成地狱”）。
具体而言，CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期（从集成和测试阶段，到交付和部署）。这些关联的事务通常被统称为"CI/CD 管道"，由开发和运维团队以敏捷方式协同支持。
一、概念 1、CI 持续集成（Continuous Integration）现代应用开发的目标是让多位开发人员同时处理同一应用的不同功能。但是，如果企业安排在一天内将所有分支源代码合并在一起（称为"合并日"），最终可能造成工作繁琐、耗时，而且需要手动完成。这是因为当一位独立工作的开发人员对应用进行更改时，有可能会与其他开发人员同时进行的更改发生冲突。如果每个开发人员都自定义自己的本地集成开发环境（IDE），而不是让团队就一个基于云的 IDE 达成一致，那么就会让问题更加雪上加霜。
持续集成（CI）可以帮助开发人员更加频繁地（有时甚至每天）将代码更改合并到共享分支或"主干"中。一旦开发人员对应用所做的更改被合并，系统就会通过自动构建应用并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应用造成破坏。这意味着测试内容涵盖了从类和函数到构成整个应用的不同模块。如果自动化测试发现新代码和现有代码之间存在冲突，CI 可以更加轻松地快速修复这些错误。
2、CD 持续交付（Continuous Delivery）完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。
在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中。
3、CD 持续部署（Continuous Deployment）对于一个成熟的 CI/CD 管道来说，最后的阶段是持续部署。作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸，持续部署可以自动将应用发布到生产环境。由于在生产之前的管道阶段没有手动门控，因此持续部署在很大程度上都得依赖精心设计的测试自动化。
实际上，持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效（假设它通过了自动化测试）。这更加便于持续接收和整合用户反馈。总而言之，所有这些 CI/CD 的关联步骤都有助于降低应用的部署风险，因此更便于以小件的方式（而非一次性）发布对应用的更改。不过，由于还需要编写自动化测试以适应 CI/CD 管道中的各种测试和发布阶段，因此前期投资还是会很大。
二、CI/CD工具JenkinsGitLab CI/CD
Gitlab CI/CD优势： 与代码托管平台Gitlab的无缝集成；
三、CI/CD核心（流水线、自动化）①流水线：将开发之后的单元测试、构建Docker镜像、接口测试、部署、压测等所有过程定义为流水线；
②自动化：将流水线中每个过程编为脚本，可以自动执行
1、流水线将开发之后的测试、部署等所有过程定义为流水线
常见的一个pipeline：单元测试、构建镜像、接口测试、部署测试环境、压力测试；
Gitlab：
将每个过程编写为脚本，可以自动执行
四、CI/CD脚本编写.gitlab-ci.yml文件，配置CI/CD流水线
每个stage都对应其bash脚本实际工作中，整个CI/CD流水线均在硬件配置较高的机器上运行、并且与公司内部的gitlab深度绑定
# 每个stage都对应其bash脚本
stages:
- unit_test
- build_image
- api_test
- deploy_beta
variables:
PROJECT_REPO_NAME: api-segment # 项目名称
before_script:
- export ROOT_PATH=$(pwd)
- echo 'root path:' $ROOT_PATH
- docker login -u $DOCKER_USER -p $DOCKER_PWD http://xxxx.dockerhub.com # 登陆公司私有的dockerhub仓库
- git config --global advice.detachedHead false
- git config --global user.email "${GITLAB_USER_EMAIL}" && git config --global user.name "${GITLAB_USER_NAME}"
- git clone --single-branch -b $CI_COMMIT_REF_NAME http://$GITLAB_USER:$GITLAB_PWD@gitlab.xxxxx.com/$PROJECT_REPO_NAME.git # 克隆/下载代码
- cd $PROJECT_REPO_NAME
- git checkout $CI_COMMIT_SHA # 选择代码版本
- echo 'commit id:' $CI_COMMIT_SHA
- echo 'commit user:' $GITLAB_USER_NAME
- echo 'commit e-mail:' $GITLAB_USER_EMAIL
- export COMMIT_MESSAGE=$(git log -p -1 --pretty=format:"%s"|head -1) # 打印信息
- echo 'commit message:' $COMMIT_MESSAGE
- export DATE=$(git log --pretty=format:"%cd %H" --date=format:'%Y%m%d' | grep ${CI_COMMIT_SHA} | awk '{print $1}')
- echo 'date:' $DATE
- export IMAGE_TAG=$DATE"_"${CI_COMMIT_SHA:0:8}
- echo 'docker image tag:' $IMAGE_TAG
unit_test_stage:
stage: unit_test
script:
- sh tests/unit_tests/env/run_unit_tests.sh
# 测试报告
artifacts:
when: always
name: "${PROJECT_REPO_NAME}_${CI_COMMIT_SHA:0:8}"
expire_in: 1 week
paths:
- TestReport.html
when: manual
allow_failure: false
build_image_stage:
stage: build_image
script:
- sh docker/build.sh $IMAGE_TAG
when: manual
allow_failure: false
api_test_stage:
stage: api_test
script:
- sh tests/api_tests/env/run_api_tests.sh $IMAGE_TAG
allow_failure: false
deploy_beta_stage:
stage: deploy_beta
script:
- xxx # 对接k8s集群
when: manual
allow_failure: false
only:
- master
单元测试脚本：testsunit_testsenvrun_unit_tests.sh
# 构建测试镜像
sh docker/build_dev.sh
build_status=$?
if [ $build_status -ne 0 ]
then
echo "build dev image fail!"
exit 1
fi
# 在测试镜像运行单元测试
container_name=api-segment
image_name=api-segment:dev
echo "run unit test"
docker stop $container_name && docker rm $container_name
docker run --name $container_name $image_name
test_status=$?
docker cp $container_name:/data/app/TestReport.html ../TestReport.html
docker stop $container_name && docker rm $container_name
# 测试成功，push测试镜像；测试失败，退出
if [ ${test_status} -eq 0 ]; then
echo "unit test success, push dev image"
docker push $image_name
else
echo "unit test fail, exit"
exit 1
fi
接口测试脚本：testsapi_testsenvrun_api_tests.sh
img_tag=$1
# 用新镜像启动服务
container_name=api-segment
image_name=api-segment:$img_tag
docker stop $container_name && docker rm $container_name
docker run --name $container_name -d $image_name
docker ps | grep $container_name
# 在容器内进行api测试
sleep 60 # 等待服务启动
docker exec $container_name bash -c "cd /data/app && python -u tests/api_tests/test_api.py"
# 如果api测试通过，push镜像；否则，打印server日志
test_status=$?
if [ $test_status -eq 0 ]; then
echo "api test success, push image"
docker push $image_name
docker stop $container_name && docker rm $container_name
else
echo "api test fail, show logs"
docker logs $container_name --tail 100
docker stop $container_name && docker rm $container_name
exit 1
fi
Gitlab的console输出：每个stage都会有控制台输出，方便查看过程
CI/CD自动化需要运维部门的同学搭建好gitlab、gitlab-runner（用来执行CI/CD的pipeline）；
参考资料：
什么是CICD
CI/CD是什么？如何理解持续集成、持续交付和持续部署
CI/CD 工具选型：Jenkins 还是 GitLab CI/CD？
CI/CD之工具选择 - Jenkins vs GitLab
