We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
产品人员创建一个完整的产品需求工单,之后附上confluence 产品需求文档。
主要作用是对产品需求进行技术拆解,将庞大的产品需求分解为可逐步开发的小步骤。同时,在对需求进行描述时,提供清晰简明的说明,突出本次更新或修改的差异。描述中可以携带Confluence文档链接或截图,以进一步说明,第二个作用方便在必要时可以进行拆解后分步骤提交测试。
开发人员开发完成之后提交代码部署到测试环境之后,将技术需求工单修改状态为closed状态,将产品需求工单状态修改为 resolved状态,指派到下一个流程中的测试人员,测试人员接收到流转的jira工单,开始测试,在测试过程中如果有bug需要修复,再回到该产品工单创建子bug工单,将该子bug工单挂到产品工单下,达到默认的关系关系。
分支命名要求,统一为 feature+开发人员名字+ JIRA工单id
比如: feature/developername/PMET-410
提交代码后会对功能分支进行CI构建,代码规范检测、代码单元测试、CI产物上传可视化平台俩个阶段。
创建一个merge request 合并到develop 分支,禁止develop分支直接开发提交代码。
1、代码可控,方便commit合并,当多次提交时,在mr阶段可对commit 进行合并。
2、团队内部可进行code review。
3、代码可追溯,所有提交的代码都有缘由,可对提交的目的进行追溯。
4、绑定JIRA工单,与JIRA flow 结合。每个MR 都对应一个或者多个JIRA 工单
仅功能分支CI流水线成功之后才能允许合并
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平台进行可视化。可以看到会有可读性检测、代码安全漏洞检查、单元测试覆盖率、代码重复率等基本代码规范可视化。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
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流程
Devops 优化后,添加模板文件,对特定属性进行自定义后,简化yaml文件的编写,支持CD流程。
执行 CI/CD流水线,一共5个阶段,分别有lint 代码检测、单元测试(test阶段)、上传CI产物(scan阶段)、程序构建可执行文件(build阶段)、docker 镜像打包(docker-build阶段)、部署dev环境(deploy-app阶段)
跑完 test 的CI脚本后,会在本地生成代码lint检测 、单元测试报告产物。
CI流程的scan阶段会将自动将test阶段产物,上传到sonarqube平台进行可视化。可以看到会有可读性检测、代码安全漏洞检查、单元测试覆盖率、代码重复率等基本代码规范可视化。
The text was updated successfully, but these errors were encountered: