扫码订阅《 》或入驻星球,即可阅读文章!

GOLANG ROADMAP

阅读模式

  • 沉浸
  • 自动
  • 日常
首页
Go学习
  • Go学院

    • Go小课
    • Go小考
    • Go实战
    • 精品课
  • Go宝典

    • 在线宝典
    • B站精选
    • 推荐图书
    • 精品博文
  • Go开源

    • Go仓库
    • Go月刊
  • Go下载

    • 视频资源
    • 文档资源
Go求职
  • 求职服务

    • 内推互助
    • 求职助力
  • 求职刷题

    • 企业题库
    • 面试宝典
    • 求职面经
Go友会
  • 城市
  • 校园
推广返利 🤑
实验区
  • Go周边
消息
更多
  • 用户中心

    • 我的信息
    • 推广返利
  • 玩转星球

    • 星球介绍
    • 角色体系
    • 星主权益
  • 支持与服务

    • 联系星主
    • 成长记录
    • 常见问题
    • 吐槽专区
  • 合作交流

    • 渠道合作
    • 课程入驻
    • 友情链接
author-avatar

GOLANG ROADMAP


首页
Go学习
  • Go学院

    • Go小课
    • Go小考
    • Go实战
    • 精品课
  • Go宝典

    • 在线宝典
    • B站精选
    • 推荐图书
    • 精品博文
  • Go开源

    • Go仓库
    • Go月刊
  • Go下载

    • 视频资源
    • 文档资源
Go求职
  • 求职服务

    • 内推互助
    • 求职助力
  • 求职刷题

    • 企业题库
    • 面试宝典
    • 求职面经
Go友会
  • 城市
  • 校园
推广返利 🤑
实验区
  • Go周边
消息
更多
  • 用户中心

    • 我的信息
    • 推广返利
  • 玩转星球

    • 星球介绍
    • 角色体系
    • 星主权益
  • 支持与服务

    • 联系星主
    • 成长记录
    • 常见问题
    • 吐槽专区
  • 合作交流

    • 渠道合作
    • 课程入驻
    • 友情链接
  • Go工程化规范设计

    • 前言
    • 开源规范
    • 文档规范
    • 版本规范
    • Git规范
    • 目录结构
    • 编码规范
    • 代码测试
    • 性能分析
    • API 设计
    • 项目管理
    • 研发流程
    • 参考资料
  • Go工程化标准实践

    • 前言
    • 项目结构
    • API 设计
    • 配置管理
    • 模块管理
    • 测试
    • 参考资料

扫码订阅《 》或入驻星球,即可阅读文章!

研发流程


Kyle

演进维度:研发模式(瀑布模式,迭代模式,敏捷模式) -> CI/CD -> DevOps。

软件生命周期:

角色分工:

# 需求阶段

参与产品讨论,详细了解需求,为后续开发打下基础。

通过需求评审后,输出详细的需求文档。

# 设计阶段

包括产品设计、交互设计、视觉设计、技术设计、技术评审、需求排期。

开发人员需要做好调研、设计领先的技术架构,技术方案获得团队一致通过。

# 开发阶段

根据项目规模和协作模式,选择采用 Git Flow 工作流。

代码开发阶段基本流程包括:创建 feature 分支 -> 完成开发工作 -> 生成代码 -> 版权检查 -> 代码格式化 -> 静态检查 -> 单元测试 -> 构建二进制文件(可执行 make 命令一键完成)。

首先在 master 分支上创建常驻的 develop 分支,并基于 develop 分支 新建 feature 分支:

git checkout -b feature/helloworld develop
1

分支名称需符合 Git Flow 命名规范,否则 githooks 会导致 commit 失败(参考 iam/pre-commit (opens new window)):

master
develop
feature + "/" + x.y.z-a
release
hotfix
1
2
3
4
5

git 不会提交 .git/hooks 下的 githooks 脚本,需要通过以下手段确保开发者 clone 仓库后,仍然能安装指定的 githooks 脚本到 .git/hooks 目录(参考 iam/common.mk (opens new window)):

# Copy githook scripts when execute makefile    
COPY_GITHOOK:=$(shell cp -f githooks/* .git/hooks/) 
1
2

在 feature 分支 完成开发工作:

# 通过 iamctl new helloworld 命令创建 helloworld 命令模板
iamctl new helloworld -d internal/iamctl/cmd/helloworld
# Command file generated: internal/iamctl/cmd/helloworld/helloworld.go

# 编辑 internal/iamctl/cmd/cmd.go 文件,在源码文件中添加helloworld.NewCmdHelloworld(f, ioStreams),,加载 helloworld 命令。
# import (
#     "github.com/marmotedu/iam/internal/iamctl/cmd/helloworld"
# )
#         ...
#         {
#             Message: "Troubleshooting and Debugging Commands:",
#             Commands: []*cobra.Command{
#                 validate.NewCmdValidate(f, ioStreams),
#                 helloworld.NewCmdHelloworld(f, ioStreams),
#             },
#         },
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

使用 make 生成代码(比如清理先前的文件再重新生成),要求操作具有幂等性:

make gen    # gen.run: gen.clean gen.errcode gen.docgo.doc
1

针对开源软件需进行 版权检查,检查新文件是否添加版权头信息:

make verify-copyright  
# 如果检查失败,可只需 make add-copyright 自动添加。
1
2

如果 Makefile 的 command 需要某个命令,可以使该目标依赖类似 tools.verify.addlicense 的目标,可检查该工具是否已安装,没有就先安装。

.PHONY: copyright.verify    
copyright.verify: tools.verify.addlicense 
  ...
tools.verify.%:          
  @if ! which $* &>/dev/null; then $(MAKE) tools.install.$*; fi
.PHONY: install.addlicense                              
install.addlicense:        
  @$(GO) get -u github.com/marmotedu/addlicense
1
2
3
4
5
6
7
8

代码格式化:依次执行 gofmt、goimports(自动增删依赖的包,并将依赖包按字母序排序并分类)、golines(超过 120 行的代码按规则折行处理)等,并使用 go mod edit -fmt 格式化 go.mod 文件。

make format
1

静态检查:

make lint
1

单元测试:注意检查测试覆盖率,达不到预期阈值就需要补充测试用例,否则禁止合并到 develop 和 master 分支(也可由 GitHub Actions CI 等自动化流水线工具检查)。

make test
# 排除不需要单元测试的包。
# go test `go list ./...|egrep -v $(subst $(SPACE),'|',$(sort $(EXCLUDE_TESTS)))`
# 把 mock_.* .go 文件中的函数单元测试信息从 coverage.out 中删除。
# sed -i '/mock_.*.go/d' $(OUTPUT_DIR)/coverage.out

make cover COVERAGE=90
# test coverage is 62.1%
# test coverage does not meet expectations: 90%, please add test cases!
# make[1]: *** [go.test.cover] Error 1
# make: *** [cover] Error 2
1
2
3
4
5
6
7
8
9
10
11

构建二进制文件:自动构建 cmd/ 目录下的所有组件,也可以构建其中一或多个组件。

make build
# make build BINS="iam-apiserver iamctl"
1
2

以上步骤可随时根据需要执行,发现问题及时改正。

Makefile 技巧:

随着项目的扩展 Makefile 会加入大量管理功能,其中 help 命令可实现自动解析:

## help: Show this help info.    
.PHONY: help           
help: Makefile               
  @echo -e "\nUsage: make <TARGETS> <OPTIONS> ...\n\nTargets:"
  # 自动解析 Makefile 中 ## 开头的注释行,从而自动生成 make help 输出。
  @sed -n 's/^##//p' $< | column -t -s ':' | sed -e 's/^/ /'
  @echo "$$USAGE_OPTIONS"  
1
2
3
4
5
6
7

变量可以在 Makefile options 中被指定:

ifeq ($(origin COVERAGE),undefined)    
COVERAGE := 60    
endif
# make COVERAGE=90
1
2
3
4

其中版本号可使用 gsemver 生成,参考 iam/ensure_tag.sh (opens new window)。


以下步骤则为提交阶段,将代码 提交到 feature 分支(建议只添加与 feature/helloworld 相关的改动,明确一个 commit 所做的变更,方便以后追溯),并 push 到远端仓库。

git add internal/iamctl/cmd/helloworld internal/iamctl/cmd/cmd.go
git commit -m "feat: add new iamctl command 'helloworld'"
git push origin feature/helloworld
1
2
3

提交时 githooks 会检查 commit message 是否符合规范(利用 go-gitlint,参考 iam/commit-msg (opens new window),也可以自行执行命令检查 go-gitlint)。

配置 GitHub Actions,当有代码被 Push 时会 触发 CI 流水线。由于保证了线上 CI 流程和本地 CI 流程完全一致。如果 CI 不通过,则需要修改代码直到通过为止。

name: IamCI
on: 
  push:
    branchs:
    - '*'
  pull_request:
    types: [opened, reopened]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    # 拉取代码
    - uses: actions/checkout@v2
    # 设置 Go 编译环境
    - name: Set up Go
      uses: actions/setup-go@v2
      with:
        go-version: 1.16
    # 执行 make 命令
    - name: all
      run: make
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

提交 pull request:在 GitHub 上基于 feature 创建 PR,并指定 reviewers 进行 CR,此时也会触发 CI 流水线。

code viewer:可选择 Comment、Approve、Request Changes。

  • 不通过:直接在 feature/helloworld 分支修正代码,并 push 到远端的 feature/helloworld 分支,再通知 reviewers 再次 review。push 事件发生会再触发 GitHub Actions CI 流水线。
  • 通过:maintainer 将新的代码合并到 develop 分支。如选择 Create a merge commit 方式,将 PR 合并到 develop 分支(git merge --no-ff,好处是所有的 commit 都会追加到 develop 分支,并生成 merge commit,便于回溯历史)。

合并到 develop 分支后触发 CI 流程。

使用 CHANGELOG 可展示每个版本之间的变更内容,作为 Release Note 的一部分。可以借助 git-chglog 工具来自动生成,配置文件参考:iam/commit-msg (opens new window)

git-chglog v1.0.0 CHANGELOG/CHANGELOG-1.0.0.md
1

# 测试阶段

对于开发人员,需要基于 develop 分支 创建 release 分支:

git checkout -b release/1.0.0 develop
make
1
2

将 release/1.0.0 分支代码 提交测试,如测试失败可直接在 release/1.0.0 修复、本地构建并提交:

make
git add internal/iamctl/cmd/helloworld/
git commit -m "fix: fix helloworld print bug"
git push origin release/1.0.0
1
2
3
4

push 到 release/1.0.0 后,GitHub Actions 会执行 CI 流水线,要求修改直到流水线执行成功为止。由测试人员完成功能测试、性能测试、集成测试、系统测试等。

测试人员根据需求文档创建测试计划、编写测试用例,并与开发人员一起评审测试计划和用例。通过后测试人员根据测试计划和测试用例对服务进行测试(测试计划的创建和测试用例的编写可与开发阶段并行)。

在此阶段为了不阻塞测试,确保项目按时发布,开发人员应优先解决测试同学的 Bug(至少是阻塞类的 Bug)。为减少不必要的沟通和排障,安装部署文档要尽可能详尽和准确,并及时地跟进测试。

测试通过后将 release/1.0.0 分支 合并到 master 分支和 develop 分支:

git checkout develop
git merge --no-ff release/1.0.0
git checkout master
git merge --no-ff release/1.0.0
git tag -a v1.0.0 -m "add print hello world" # master分支打tag
1
2
3
4
5

删除 feature 和 release 分支:

git branch -d feature/helloworld
git branch -d release/1.0.0
1
2

# 发布阶段

遵循发布规范,谨慎发布到现网,并做好现网验证。

# 运营阶段

协助运维快速定位并恢复系统,协助运营开发运营类功能接口。

  • 需求阶段
  • 设计阶段
  • 开发阶段
  • 测试阶段
  • 发布阶段
  • 运营阶段