1. Home
  2. Devops
  3. SonarQube和GitLab使用

SonarQube和GitLab使用

CICD介绍

什么是CI/CD ？

概念 CI 即 Continuous Integration 的缩写，中文即持续集成。持续集成（CI） 是在源代码变更后自动检测、拉取、构建和进行单元测试的过程。 CD 有两层意思，一层是 Continuous Delivery 持续交付，另一层是 Continuous Deployment 持续布署。 CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一种面向开发和运维团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题。

什么是 CI 持续集成？

持续集成（CI）可以帮助开发人员更加频繁地（有时甚至每天）将代码更改合并到共享分支或“主干”中。一旦开发人员对应用所做的更改被合并，系统就会通过自动构建应用并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应用造成破坏。这就要求测试内容涵盖了从类和函数到构成整个应用的不同模块。如果自动化测试发现新代码和现有代码之间存在冲突，CI 可以更加轻松地快速修复这些错误。

什么是 CD 持续交付？ 持续交付（Continuous Delivery，简称CD）是一种软件工程方法，旨在通过自动化的软件开发、测试和准备发布流程，确保软件可以随时被准确、快速地部署到生产环境中。持续交付强调的是自动化测试和构建的过程，使得每次提交后的软件版本都能够通过自动化流程达到可以发布的状态，但最终的发布决策可以是自动的也可以是手动的。

什么是 CD 持续部署？ CD，即持续部署（Continuous Deployment），是一种软件发布方法论，是cicd流程中最后的阶段，它指的是软件开发流程中的一种实践，其目标是通过自动化的测试和部署流程，确保软件可以在任何时候被安全、快速地部署到生产环境中。持续部署是持续交付（Continuous Delivery）的进一步延伸，不仅包括自动化测试，还包括自动化部署步骤，使得每次代码提交后，只要通过所有测试，就会自动部署到生产环境，而无需人工干预。

为什么团队需要cicd？ ● 提高开发效率 通过自动化编译、测试和部署过程，团队成员可以减少手动操作的时间和出错的机会，从而将更多精力集中在核心开发任务上。

● 缩短反馈周期 自动化测试和部署意味着代码改动后立即进行验证，这样可以快速发现和修复问题，提高软件质量。

● 增强代码质量 持续集成要求开发人员频繁地将代码变更合并到主分支，这促使团队采用更严格的代码审查和测试标准，从而提高代码质量。

● 加快产品上市时间 自动化流程减少了从代码编写到产品部署所需的时间，使团队能够更快地发布新功能和修复，加快产品上市速度。

● 促进团队协作 CI/CD流程鼓励团队成员频繁地交流和合作，通过共享的工具和实践，促进了团队的协作和沟通。

● 更容易管理大型项目 对于大型项目，CI/CD可以帮助管理复杂性，通过自动化测试和部署，确保所有组件和服务的整合和兼容性。

● 实现敏捷开发和DevOps CI/CD是实现敏捷开发和DevOps文化的关键组成部分，它支持快速迭代和持续改进的理念，帮助团队更好地响应市场和用户需求。

● 降低风险 通过持续、自动化的测试和部署，可以及时发现并修复安全漏洞和其他问题，从而降低系统出现严重故障的风险。

● 提升用户满意度 快速迭代和持续的改进意味着用户可以更快地看到新功能和改进，从而提高用户满意度和忠诚度。

cicd流程

部署 GitLab

GitLab介绍 GitLab: 是一个基于Web的Git仓库管理工具，用于版本控制和协作开发。它提供了代码仓库、问题跟踪、持续集成等功能，使团队能够更好地协作开发。 特性： ● 开源免费

● 可以作为 Git 代码仓库

● 提供了方便易用的 Web 管理界面

● 支持离线提交

● 安全性高, 可以对不同的用户设置不同的权限,并且支持不同用户只能访问特定的代码,实现代码部分可见

Pipeline介绍 pipeline 是 Gitlab CICD 的功能组件，主要包含Stage和Job2个组件，通过定义一系列的任务（称为“作业”），这些任务可以被组织成不同的阶段并自动执行，从而实现代码从开发到部署的整个流程的自动化。 Stage ： Stage 是 Pipeline 的一个阶段，用于组织和控制多个作业的执行顺序。一个 Pipeline 可以有多个 Stage，每个 Stage 包含一个或多个 Job。同一 Stage 中的 Job 默认并行执行，而不同 Stage 的执行则是串行的，前一个 Stage 的所有 Job 完成后，下一个 Stage 才会开始。 Job ： Job 是 Pipeline 中的基本执行单元，它定义了一个需要执行的具体任务，比如编译代码、运行测试或部署应用。

工作流程 ● 定义 .gitlab-ci.yml 文件： 在项目根目录下创建一个 .gitlab-ci.yml 文件，该文件用于定义 Pipeline 的配置，包括作业、阶段、脚本和变量等。

● 触发 Pipeline： 当代码被推送到 GitLab 仓库，或者满足其他触发条件时，GitLab 会自动根据 .gitlab-ci.yml 文件中的定义执行 Pipeline。

● 执行作业： GitLab Runner会根据配置执行 Pipeline 中的作业，这些作业可以在不同的环境中运行，比如 Docker 容器、虚拟机或物理机。

● 查看结果： 在 GitLab 的 UI 中，可以查看每次 Pipeline 的执行结果、日志和历史，方便快速定位问题。

Gitlab安装 ● 测试环境：内存4G以上

● 生产环境：建议CPU2C以上，内存8G以上，磁盘10G以上配置，和用户数有关

● 从GitLab 12.1 开始不再支持MySQL,只支持PostgreSQL

为了开始我们的设置，需要确保以下组件已经准备就绪：

  1. GitLab 账户和一个项目。
  2. gitlab官网安装指南： https://about.gitlab.com/install/#centos-7

添加gitlab的yum源仓库：

[root@gitlab ~]# curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash

安装gitlab

[root@gitlab ~]#  yum  -y  install  gitlab-ce

配置gitlab，设置配置文件/etc/gitlab/gitlab.rb 中的 external_url 修改成本机ip+端口

重载配置生效，然后重启服务

[root@gitlab ~]# gitlab-ctl reconfigure
[root@gitlab ~]# gitlab-ctl restart

1.5 访问ip+端口

用户名root，首次登陆需设定密码

GitlabRunner安装

GitLab Runner是GitLab CI/CD（持续集成/持续交付）工具中的一部分，用于在GitLab上运行自动化构建和部署任务。GitLab Runner提供了执行器（executor）来处理各种类型的任务，如编译、测试、构建镜像等。

不同环境下的安装：

Linux x86-64
sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
Linux x86
sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-386
Linux arm
sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-arm

下载对应平台的二进制运行文件，并保存命名到/usr/local/bin/gitlab-runner 权限设置：

chmod +x /usr/local/bin/gitlab-runner

安装和启动

gitlab-runner install  --working-directory=/home/gitlab-runner
gitlab-runner start

设置runner环境，需要在gitlab项目中进行注册,进入项目后，在设置、cicd里面，点击Runner

部署SonarQube

SonarQube介绍

SonarQube是一个开源的代码质量管理平台，用于进行代码静态分析、检测代码缺陷、漏洞等。SonarQube提供了丰富的代码分析规则和报告，可以帮助团队提高代码质量并减少技术债务。 sonar安装 sonar下载地址： https://www.sonarsource.com/products/sonarqube/downloads/

Sonar-scanner-cli介绍 Sonar Scanner CLI: 是SonarQube的命令行工具，用于将代码提交到SonarQube服务器进行代码质量检查和分析。它会扫描代码，并生成有关代码质量、安全性和性能的报告。Sonar Scanner CLI可以与GitLab Runner等CI/CD工具集成，实现自动化的代码质量检查。

Sonar-scanner-cli安装 Sonar-scanner-cli下载：https://docs.sonarsource.com/sonarqube/latest/analyzing-source-code/scanners/sonarscanner/ 汉化 省略......

前置条件： 已安装 JDK1.8 环境 启动方式

进入到

/usr/local/sonarqube-10/bin/linux-x86-64/

执行sonar.sh start 注意：sonar服务依赖于elasticsearch，不能使用root用户启动 ，新建sonar用户并赋予权限 默认的访问地址是：ip+端口9000,默认用户是admin+admin

和gitlab集成

  1. 设置gitlab访问令牌：

  2. 添加sonar配置认证

结合实际项目集成

配置 SonarQube

先准备2个项目，php项目和golang项目

首先，需要在 SonarQube 中为你的项目创建一个新的项目。创建后，SonarQube 会提供项目的 key 和 token，这些信息将在后续步骤中用到。 a. 创建项目 本地创建（代码在本机） 通过gitlab导入

b. 选择分析方式 使用 GitLab CI 使用Jenkins

复制并保留SonarQube命令到gitlab-ci.yml中，后续会用到

设置 GitLab CI/CD 在 GitLab 项目的设置中，找到 CI / CD 配置，并添加环境变量： ● SONARQUBE_URL：设置为你的 SonarQube 服务器地址。 ● SONARQUBE_TOKEN：使用刚才在 SonarQube 中生成的 Token。

配置 GitLab Runner GitLab Runner是用于运行你的CI/CD作业并将结果发送回给GitLab。它是一个独立的应用程序，与GitLab CI/CD一起使用，GitLab CI/CD是GitLab内置的持续集成、部署和交付的服务。 setting>cicd>Runner：

编写.gitlab-ci.yml文件 创建或更新你项目中的 .gitlab-ci.yml 文件，添加以下内容：

php项目

stages:
    - sonarqube-check
    - sonarqube-vulnerability-report

sonarqube-check:
  stage: sonarqube-check
  image: 
    name: sonarsource/sonar-scanner-cli:5.0
    entrypoint: [""]
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"  # Defines the location of the analysis task cache
    GIT_DEPTH: "0"  # Tells git to fetch all the branches of the project, required by the analysis task1
  cache:
    key: "${CI_JOB_NAME}"
    paths:
      - .sonar/cache
  script: 
    - sonar-scanner -D"sonar.login=user"  -D"sonar.password=user"
  allow_failure: true
  only:
    - merge_requests
    - master
    - main
    - develop

sonarqube-vulnerability-report:
  stage: sonarqube-vulnerability-report
  script:
    - 'curl -u "${SONAR_TOKEN}:" "${SONAR_HOST_URL}/api/issues/gitlab_sast_export?projectKey=root_gitmind-php_AY2wv-m6fqqalvx6bhQa&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json'
  allow_failure: true
  only:
    - merge_requests
    - master
    - main
    - develop
  artifacts:
    expire_in: 1 day
    reports:
      sast: gl-sast-sonar-report.json
  dependencies:
    - sonarqube-check

golang项目

stages: 
  - build
  - sonarqube-check
  - test
  - deploy
  
# build 编译构建
build-job: 
  stage: build
  script:
    - chmod +x deploy/gitlab-ci/1-build.sh
    - sh deploy/gitlab-ci/1-build.sh

# SonarQube 校验
sonarqube-check:
  stage: sonarqube-check
  image:
    name: sonarsource/sonar-scanner-cli:latest
    entrypoint: [""]
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"  # Defines the location of the analysis task cache
    GIT_DEPTH: "0"  # Tells git to fetch all the branches of the project, required by the analysis task
  cache:
    key: "${CI_JOB_NAME}"
    paths:
      - .sonar/cache
  script:
    - sonar-scanner -Dsonar.projectKey=xxxKey -Dsonar.host.url=xxxurl -Dsonar.token=sqp_1xxxx
  allow_failure: true
  only:
    - merge_requests
    - master # or the name of your main branch
    - develop
    - main
    
# test 测试
lint-test-job: 
  stage: test 
  script:
    - chmod +x deploy/gitlab-ci/2-test.sh
    - sh deploy/gitlab-ci/2-test.sh
    
# deploy 部署 
deploy-job: 
  stage: deploy 
  script:
    - chmod +x deploy/gitlab-ci/3-deploy.sh
    - sh deploy/gitlab-ci/3-deploy.sh

请确保替换 your_project_key 为你的 SonarQube 项目密钥，./src 为你的源代码目录。

测试和验证 提交 .gitlab-ci.yml 文件到 GitLab 项目，将触发 CI/CD 流程。流程结束后，你可以在 SonarQube 的仪表板上看到一个全面的代码质量报告。

Sonar指标解读

  1. Bugs 定义：可能会导致程序出错的明确错误。 重要性：高。Bug数目是衡量代码质量的直接指标之一。减少Bug数可以直接提高软件的稳定性。
  2. Vulnerabilities 定义：潜在的安全漏洞，可能会被攻击者利用。 重要性：非常高。安全漏洞会直接影响到软件的安全性和用户数据的安全，因此应当优先解决。
  3. Code Smells 定义：代码异味是指代码中的任何可能表明深层次问题的特征。它们不一定是错误，但可能会降低代码的可维护性。 重要性：中到高。虽然代码异味可能不会直接导致程序出错，但它们会增加代码的复杂性，降低可读性和可维护性。
  4. Coverage 定义：代码覆盖率指的是自动化测试覆盖了多少百分比的代码。高覆盖率可以增加代码修改的信心。 重要性：中到高。覆盖率是衡量测试质量的一个重要指标，高覆盖率有助于减少Bug和漏洞。
  5. Duplications 定义：代码中重复的部分。代码重复会增加维护成本，因为一处代码的更改可能需要在多处重复代码中手动复制。 重要性：中。减少代码重复可以提高代码的可维护性。
  6. Technical Debt 定义：为了达到短期目标而采用的非理想解决方案积累的成本。它是将来修正这些非理想解决方案所需的时间的估计。 重要性：中到高。技术债务可以通过增加项目的未来工作量来间接影响项目的交付速度和稳定性。
  7. Complexity 定义：衡量代码结构复杂度的指标，例如方法或类的复杂度。 重要性：中。高复杂度可能导致代码难以理解和维护，增加引入Bug的风险。
  8. Lines of Code (LOC) 定义：项目中的代码行数。 重要性：低到中。虽然LOC本身并不直接影响代码质量，但它可以用作项目规模的一个参考指标。

BUG 评级计算方法（可靠性）

  • A：表示代码无 Bug，最高级别
  • B：代码有一个 次要 Bug，等级评估为 B
  • C：代码有一个 重要 Bug，等级评估为 C
  • D：代码有一个 严重 Bug，等级评估为 D
  • E：代码有一个 阻断 Bug，等级评估为 E，最低级别

.....

  • step1：新建gitlab仓库，push代码
  • step2：sonarque导入项目，设置gitlab-cli
  • step2：配置和注册Runner，变量 SONAR_TOKEN 和 SONAR_HOST_URL

配合Jenkins使用（待完善）

如果您喜欢我的文章，请点击下面按钮随意打赏，您的支持是我最大的动力。

打 赏