- 团队提交PR的单位为每个Issue(以保障针对每个Issue可以快速合并代码)
- 发起名义是组织发起的(维护团队会与组长沟通,PR是否是以组织名义发起的,是否已经经过组织验收并测试、是否承担PR带来的问题)
- 尽快提交PR(为了保障代码可以顺利合并到主库,维护团队可以尽快反馈问题,需要尽快提交PR)
- 持续同步最新代码(为了保障代码与主库代码保持一致,各个团队的库以及各个开发人员的库,需要持续与主库代码同步,频率越高越好)
- PR提交名字格式:组名-IssueId-功能名
为了提高PR审核和合并的效率,未来小组成员提交的PR需要满足:
- 提交的PR所触发的CI必须通过,小组成员需要自行检查CI状态,如果失败则需要自行修复。修复完成后再通知维护团队进行Review
- 没有普遍性代码问题,比如:hard-code配置内容,拼写错误,常识性编码问题
- 小组在自己的环境内测试通过(CodeReview、功能测试、集成测试、流水线测试),并在PR附上测试截图
- PR需要关联相关的 Issue
以上满足后,由小组组长发起Review,通过远程方式为维护团队演示所提交的内容的展示效果。演示通过后维护团队根据情况完成合并。 以上过程中如果有任何反馈和沟通,请及时更新PR历史记录,确保任何人都可以通过PR日志了解整个review和合并过程。
团队成员对某个功能认可,可以由任意组织级Repo、或者个人Repo提交PR到idcf主库。
1.各个组为每一个功能创建一个分支,组员开发完,往各个组的分支上PR代码,组内做验收。
# 拉取idcf最新代码
git fetch upstream
# 根据idcf主库最新代码创建功能分支
git checkout -b <feature_branch_name> upstream/master
# 推送特性分支到团队folk库
git push -u origin <feature_branch_name>
2.组内验收通过后,接受PR,合并到自己的功能分支中,组内发起某个功能分支往idcf主库的合并。
3.idcf主库验收通过并合并代码到master分支,贡献完成。
# 删除本地特定分支
git branch -d [feature_branch_name]
# 删除远程特性分支
git push origin --delete <feature_branch_name>
4.各个组需持续与idcf主库同步,保持代码为最新代码,避免冲突。
#拉取最新代码
git fetch upstream
#合并主库master代码到folk库master代码
git merge upstream/master master
#签入合并后的代码
git push origin master
由于各个团队的Jenkinsfile配置的参数以及docker-compose-template.yaml里仓库的地址与主库不一致。提交PR的时候有可能会出现把Jenkinsfile以及docker-compose-template.yaml也提交的情况。
这种情况应当避免,因为这样相当于破坏了主库。当然维护团队也会尽量避免有类似这种情况的发生,尽量把这些个人化参数都改为参数化。这样就可以保持各类配置文件一致。
由于各个团队都在各个folk库的Master上做开发,出现了一个团队同时提交多个Issue的PR,这样的PR处理起来就会较为复杂:
-
一个PR多个Issue在代码结构上看起来很乱,搞不清楚代码修改跟哪个业务关联关系。
-
一个PR多个Issue会导致维护团队在Review代码的时候比较复杂。
-
一个PR多个Issue会造成因为某个Issue Review不通过,其他Issue都无法合并的问题。
-
团队在进行工具链任务制作的过程中,不仅需要完成工程的实现,也需要有详细的描述文档,因为最终所有的流程要在idcf主库运行起来,并且保障任何其他团队也可以通过手册把整个工具链给搭建起来。
-
所有技术文档提交都需要使用Markdown格式,这样在页面上可以直接看,不需要下载
文档提交指南:点击查看
- 编译后的文件提交(编译后的文件与代码无关,不应该提交到代码库)
- 不小心改坏或本地测试的文件提交(自己在本地不小心改坏的文件不应该提交,提交前需要自己看下)
- .gitignore设置到具体的文件(.gitignore尽量忽略掉不需要的文件夹)
- 格式化的代码导致的无效变更
由于团队在搭建环境的时候可能与主库的环境不一致,导致在团队内测试的流水线任务没问题,合并到主库后出现问题。
- 代码合并问题较多(多Issue合并、某个Issue带着其他Issue的相关文件)
- 没有Code Review人员(代码很多小问题,团队内部没有Review过)
- 没有测试人员,很多功能没有开发完成(功能测试、集成测试)
- 流水线执行Break(流水线阶段被Break掉,单元测试、UI测试不通)
- 造成了新的业务缺陷(新的约束导致原来的接口变化,前端功能不好用了)
- 业务功能没有完成(不建议提交这样的PR,最小单位是Issue,如果Issue没有完成建议下一个迭代提交、或者创建技术债Issue,并合并。前提是业务代码已经完成了,只是没有做集成)