日常开发工作流实践

JIRA Flow

1、产品人员创建产品需求

产品人员创建一个完整的产品需求工单，之后附上confluence 产品需求文档。

2、开发人员创建技术需求

主要作用是对产品需求进行技术拆解，将庞大的产品需求分解为可逐步开发的小步骤。同时，在对需求进行描述时，提供清晰简明的说明，突出本次更新或修改的差异。描述中可以携带Confluence文档链接或截图，以进一步说明，第二个作用方便在必要时可以进行拆解后分步骤提交测试。

3、测试人员bug工单

开发人员开发完成之后提交代码部署到测试环境之后，将技术需求工单修改状态为closed状态，将产品需求工单状态修改为 resolved状态，指派到下一个流程中的测试人员，测试人员接收到流转的jira工单，开始测试，在测试过程中如果有bug需要修复，再回到该产品工单创建子bug工单，将该子bug工单挂到产品工单下，达到默认的关系关系。

GIT Flow

1、分支命名

分支命名要求，统一为 feature+开发人员名字+ JIRA工单id

比如： feature/developername/PMET-410

2、提交代码

提交代码后会对功能分支进行CI构建，代码规范检测、代码单元测试、CI产物上传可视化平台俩个阶段。

3、合并

创建一个merge request 合并到develop 分支，禁止develop分支直接开发提交代码。

1、代码可控，方便commit合并，当多次提交时，在mr阶段可对commit 进行合并。

2、团队内部可进行code review。

3、代码可追溯，所有提交的代码都有缘由，可对提交的目的进行追溯。

4、绑定JIRA工单，与JIRA flow 结合。每个MR 都对应一个或者多个JIRA 工单

仅功能分支CI流水线成功之后才能允许合并

4、自动部署流程

MR被合并到develop分支之后会自动进行流水线构建部署

Devops对流水线规范化之前，仅支持CI流程

workflow:
  rules:
    - if: $CI_COMMIT_BRANCH =~ /^(dev|feature|feat|bugfix|fix)/ || $CI_COMMIT_BRANCH =~ /^(develop)$/
      variables:
        APP_VERSION: ${CI_COMMIT_SHA}
    - if: $CI_COMMIT_TAG
      variables:
        APP_VERSION: ${CI_COMMIT_TAG}
    - when: never
stages:
  - lint
  - test
  - build 
# golangci-lint
lint-job:
    image: golangci/golangci-lint:v1.53.3
    tags:
      - docker
    stage: lint
    allow_failure: false
    before_script: 
      - export GO111MODULE=on
      - go mod download 
      - apt-get update && apt-get install make && chmod +x ./Makefile 
    script:
      - make lint
    artifacts:
      paths:
        - ./reports/golangci-lint-report.xml

# unit test
test-job:
  image: golang:1.20.5
  stage: test
  tags:
    - docker
  allow_failure: false
  before_script: 
    - export GO111MODULE=on
    - go mod download 
    - export SERVER_ENV=test
    - apt-get update && apt-get -y install make pkgconf libzmq3-dev && chmod +x ./Makefile 
  script:
    - make test
  artifacts:
      paths:
        - ./reports/unit-test-coverage.out
        - ./reports/unit-test-coverage.json
# sonarqube-check:
#   image: sonarsource/sonar-scanner-cli:latest
#   stage: test
#   tags:
#     - k8s
#   only:
#     - dev
#   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
#   allow_failure: false
#   dependencies:
#     - test-job
#   needs: ["test-job"]
build:
  image: docker:20-git
  stage: build
  tags:
    - docker
  only:
    - tags
    - dev
    - develop
  services:
    - docker:dind
  variables:
    DOCKER_REGISTRY_HOST: "${REGISTRY_HOST}"
    DOCKER_REGISTRY_USER: "robot$$${CI_PROJECT_NAMESPACE}+${CI_PROJECT_NAMESPACE}"
    DOCKER_REGISTRY_TOKEN: "${REGISTRY_TOKEN}"
  before_script:
    - IMAGE_NAME=${DOCKER_REGISTRY_HOST}/${CI_PROJECT_NAMESPACE}/${CI_PROJECT_NAME}:${APP_VERSION}
    - echo ${IMAGE_NAME}
  script:
    - docker -v
    - docker login ${DOCKER_REGISTRY_HOST} -u ${DOCKER_REGISTRY_USER} -p ${DOCKER_REGISTRY_TOKEN}
    - docker build -t ${IMAGE_NAME} .
    - docker push ${IMAGE_NAME}

Devops 优化后，添加模板文件，对特定属性进行自定义后，简化yaml文件的编写，支持CD流程。

include:
  - project: p-integration/gitlab-ci-templates
    ref: main
    file: Go.gitlab-ci.yml
test:
  extends: .test
  script:
    - make lint test
  artifacts:
      paths:
        - ./reports
build:
  extends: .build
  script:
    - make build

执行 CI/CD流水线，一共5个阶段，分别有lint 代码检测、单元测试（test阶段）、上传CI产物（scan阶段）、程序构建可执行文件（build阶段）、docker 镜像打包（docker-build阶段）、部署dev环境（deploy-app阶段）

跑完 test 的CI脚本后，会在本地生成代码lint检测、单元测试报告产物。

CI流程的scan阶段会将自动将test阶段产物，上传到sonarqube平台进行可视化。可以看到会有可读性检测、代码安全漏洞检查、单元测试覆盖率、代码重复率等基本代码规范可视化。

dduo518 / hexo-blog