git仓库结构化流程及存储库目录结构设计

Question

git仓库结构化流程及存储库目录结构设计

Closed this issue 3 years ago · 23 comments

liminany commented 4 years ago

@smallidea @ups216

拆库已经完成，详见：https://github.com/idcf-boat-house/boat-house

TODO：后端单体架构流水线，可选方案：

将sprint boot application maven project 合并成一个Pom文件进行编译打包成一个jar
一个容器里面跑两个应用，需调整dockerfile,目前未完工，详见这里：https://github.com/idcf-boat-house/boat-house-backend/blob/master/src/Dockerfile

Answer 1 · 2020-06-09T05:06:14.000Z

存储库目录结构初步规划

文档库

boat-house-docs：主库，文档库,对应现有的存储库： boat-house。主要存放基于Boat-house代码库的种实践文档，整个boat-house的共创运作基于此库展开。

文档图片放至每个md文件所在目录的Images目录中。

boat-house-docs:

docs
- images
- quickstart,快速指导文档
  - jenkins-quickstart.md
  - sonarqube-code-analysis-quickstart.md
- practice，实践文档
  - tools
    - jenkins
      - deploy
      - system-config
      - pipline-config
      - scenario
    - sonarqube
      - deploy
      - system-config
      - pipline-config
        
        index.md
        
        jenkins-pipline-config.md
        
        tfs-pipline-config.md
      - scenario
  - traning
    - Boat-House DevOps
      - 1
      - 2
      - 3
- group：是否需要给每个小组创建一个目录？
  - group1
    - ?
  - group2
  - group3
readme.md

单体架构代码库

新建git仓库，将前端和后端代码放一个库中： client+management+product-service,后端采用java.注意：目前因某些原因现所有Service代码都存放在 product-service 中。
问题：还是分三个端？还是三端都合并成一个端(前端放一起可能会有冲突)？还是两个端(management-product-service + client)？

微服务架构代码库

新建仓库，将原主库代码部分内容移过来，并进行微服务改造？

Answer 2 · 2020-06-09T07:38:37.000Z

@liminany 主库结构请参考https://github.com/idcf-docs/idcf-devops-roadmap 这个说明，也就是一个文档是一个单独的文件夹，文字和图片都统一放在这个文件夹中。

单体代码库：

前端一个 boathouse-frontend
后端一个 boathouse-backend-monolith

微服务代码库：

前端的直接而用 boathouse-frontend
后端分服务单独放置
- boathouse-backend-account-service
- boathouse-backend-product-service
- boathouse-backend-xxx-service

devops代码库：

boathouse-devops: 里面放流水线，工具配置文件等

Answer 3 · 2020-06-09T09:49:07.000Z

单体代码库 BoatHouse-SingleApllication

frontend 前端
- andriod
  - app
  - gradle
- ios
- web
  - js
  - css
  - html
  - imgs
  - index.html
backend-monolith 后端
- java
  - com
    - controller
    - core
    - entity
    - mapper
    - service
  - resources
  - test
- core
  - controller
  - viewmodel
  - lib
  - test
- php
read.md

微服务代码库 BoatHouse-Microservice

前端代码直接使用 BoatHouse-SingleApllication/frontend

目录结构

account-service
- java
  - com
    - controller
    - core
    - entity
    - mapper
    - service
  - resources
  - test
- core
  - controller
  - viewmodel
  - lib
  - test
- php
product-service
pay-service
statistics-service
order-service
readme.md

devops代码库 BoatHouse-Devops

里面放流水线，工具配置文件等

jenkins
docker
- dockerfiles
- dockercompose
test
- junit
- jmeter
k8s
- monitor 监控
- kompose 集群
azure-devops
chatops
- mattermost
jira
github-action

分析

现有代码库中实操类的文档还是有的，只是没有提炼显得不通用，其实也可以放到文档库，因为baot-house已经是个品牌，作为示例也未尝不可。
三大代码库在参与项目的过程中，操作会比较多，而文档库是一个经验的分享，“吃瓜群众”看得会比较多。
作为主库（文档库），应该有链接到代码库，让"吃瓜群众"有变成参与者的可能。
三个代码库之间也要重点维护好根目录下的readme.md，用尽可能使用git动画、简练的语言、良好的排版指引用户找到对应的代码及脚本，让参与者可以对项目有把控感。
现有的idcf.org.cn、boat-house.cn 在搜索引擎上的搜录量几乎为0，这个不是一件好事。

Answer 4 · 2020-06-09T10:45:08.000Z

文档库见结构见：

https://github.com/idcf-boat-house/boat-house/tree/boat-house-docs

Answer 5 · 2020-06-10T04:02:29.000Z

代码库列表

boathouse-frontend：web前端（包括用户端和管理端）
boathouse-mobile-android：移动端
boathouse-backend：后端服务库，提供两种打包方式
- 单体架构打包方式，使用一个POM/Dockerfile文件做所有services的编译打包，打成一个jar/war/docker image
- 微服务架构的打包方式，每个服务有自己独立的POM文件和Dockerfile，每个服务单独打包成一个jar/war/docker image

文件目录结构

boathouse-frontend
- src
  - client
    - POM+Dockerfile: client端独立编译打包
  - management
    - POM+Dockerfile: management端独立编译打包
- test: 测试用例相关代码（自动化）：junit+selenium+jmeter
  - unittest
    - client-test
    - management-test
  - selenium
  - jmeter
  - postman
- devops 当前项目相关的配置文件/描述文件
  - jenkins
  - azure-devops
  - github-action
boathouse-mobile-android
boathouse-backend
- src
  - acount-service
    - POM+Dockerfile: account-service端独立编译打包
  - product-service
    - POM+Dockerfile: product-service端独立编译打包
  - xxx-service
  - POM + Dockerfile: 单体架构下的统一编译，打包
- test: 测试用例相关代码（自动化）：junit+selenium+jmeter
  - unittest
    - account-service-test
    - product-service-test
  - selenium
  - jmeter
  - postman
- devops 当前项目相关的配置文件/描述文件
  - jenkins
  - azure-devops
  - github-action
boathouse-infrastructure
- quick-start (end-to-end)
- devops-tools
  - jenkins-server
  - sonaqube-server
  - nexus-server
  - jira-server
  - azure-devops-server
  - gitlab-server
  - github-enterprise-server
- environments
  - test (vm)
  - production (kubernetes)

Answer 6 · 2020-06-10T04:36:53.000Z

代码库迁移计划

将boat-house库改名为boathouse-backend
将前端和移动端代码迁移出来分别单独建库
把boat-house-devops库改名为boat-house作为主库（实践库）
原来wiki的内容移动到主库中

主库结构（整个主库是一个docsity站点）

README.md 主库入口
index.html docsity入口
docs
- quick-start: 原wiki的内容
- lean
- agile-team
- agile-scaled
- devops-e2e-5p
- devops-hackathon
  - workshop
- devops-case-studies

文档组织方式

根目录下的README.md作为整个主库的索引
每个docs子文件夹需要一个README.md作为本子文件内容的索引
二级目录（docs/quick-start）下按照每篇文档一个独立目录的方式保存文档（docs/quick-start/01-team-setup)，每个文档目录内至少包括images文件夹和README.md，文档内容写入README.md，所有当前文档相关的图片都放在当前的images文件夹内，如果有其他相关文件，也放置在同一个目录中
暂时不对二级目录下的文档目录再进行进一步的目录分类，未来采用标签的方式标识每个文档所相关的实践，以便对应到人才地图的具体实践点。

主库的自动化发布

发布到https://idcf.org.cn/boat-house/#
boat-house主库发布成一个独立的docsity站点

Answer 7 · 2020-06-10T10:02:59.000Z

单体架构代码库

代码库迁移计划

将boat-house库改名为boathouse-backend

将前端和移动端代码迁移出来分别单独建库

把boat-house-devops库改名为boat-house作为主库（实践库）

原来wiki的内容移动到主库中

主库结构（整个主库是一个docsity站点）

README.md 主库入口

index.html docsity入口

docs

quick-start: 原wiki的内容

lean

agile-team

agile-scaled

devops-e2e-5p

devops-hackathon

workshop

devops-case-studies

文档组织方式

根目录下的README.md作为整个主库的索引

每个docs子文件夹需要一个README.md作为本子文件内容的索引

二级目录（docs/quick-start）下按照每篇文档一个独立目录的方式保存文档（docs/quick-start/01-team-setup)，每个文档目录内至少包括images文件夹和README.md，文档内容写入README.md，所有当前文档相关的图片都放在当前的images文件夹内，如果有其他相关文件，也放置在同一个目录中

暂时不对二级目录下的文档目录再进行进一步的目录分类，未来采用标签的方式标识每个文档所相关的实践，以便对应到人才地图的具体实践点。

主库的自动化发布

发布到https://idcf.org.cn/boat-house/#

boat-house主库发布成一个独立的docsity站点

目前已经把文档整体在一起了，见分支. @ups216 看一下结构.

接下来配置github action部署。仓库重命名，可以等整理完后在进行。

另原WIKI中的内容并未按我们预想的方式来整理，只是把内容复制过来了，能查看。如果要把文档在拆成一个md文件一个目录传统比较花时间，而且图片也要拆离，得花些时间，所以我想要不就先保持原样。后面新加的文档再按约定的方式组织。

Answer 8 · 2020-06-10T12:14:13.000Z

现有的文档可以保持原结构，确保发布到docsify以后可以正常使用即可。

Answer 9 · 2020-06-10T15:00:29.000Z

三个代码库的基本结构已经有了，接下来的粗略计划是

前端库，可以build、test；计划耗时1d
android库，可以build、test；计划耗时2d
后端库，参考之前的方法单体和微服务可以跑起来；计划耗时3d

Answer 10 · 2020-06-11T09:00:10.000Z

现有的文档可以保持原结构，确保发布到docsify以后可以正常使用即可。

已经部署上去，但是中文文件名有乱码，目前看那个ftp 部署任务没有考虑编码的问题，看来是要更改一下文件名了？

https://idcf.org.cn/boat-house/#/docs/quick-start/operation/%E9%8D%A5%E3%88%A4%E6%A7%A6%E6%B6%93%E5%A9%83%E5%A2%9C%E9%8E%B8%E5%9B%A7%E5%B4%A1.md

Answer 11 · 2020-06-11T09:36:16.000Z

@ups216 @liminany

前端库，可以build、test；计划耗时1d

目前前端库已经整理，链接如下：
https://github.com/idcf-boat-house/boat-house/tree/boat-house-frontend

工作内容
- 解决编译过程中的问题
- 整理根目录readme.md（调整文档结构、增加目录、完善环境搭建、完善调试方法）
待完善
测试、DevOps 的指引内容，因需要熟悉时间，暂未更新
问题
目前根目录依然包含了images文件夹，因为代码库中markdown文件一定会有存储图片的需求。

Answer 12 · 2020-06-12T03:05:02.000Z

现有的文档可以保持原结构，确保发布到docsify以后可以正常使用即可。

已经部署上去，但是中文文件名有乱码，目前看那个ftp 部署任务没有考虑编码的问题，看来是要更改一下文件名了？

https://idcf.org.cn/boat-house/#/docs/quick-start/operation/%E9%8D%A5%E3%88%A4%E6%A7%A6%E6%B6%93%E5%A9%83%E5%A2%9C%E9%8E%B8%E5%9B%A7%E5%B4%A1.md

文件名已经更新为英文，文档中的链接也修复了 http://idcf.org.cn/boat-house/#/

Answer 13 · 2020-06-15T03:28:34.000Z

安卓端代码库和文档调整完毕：

https://github.com/idcf-boat-house/boat-house/tree/boat-house-mobile-android

目前发现此app 只是一个单机应用，里面的功能也非常有限，界面比较乱。

@jijiechen @ups216
app-debug.zip

Answer 14 · 2020-06-15T03:38:11.000Z

没关系，重点在CI/CD

安卓端代码库和文档调整完毕：

https://github.com/idcf-boat-house/boat-house/tree/boat-house-mobile-android

目前发现此app 只是一个单机应用，里面的功能也非常有限，界面比较乱。

@jijiechen @ups216
app-debug.zip

Answer 15 · 2020-06-15T07:24:48.000Z

没关系，重点在CI/CD

安卓端代码库和文档调整完毕：
https://github.com/idcf-boat-house/boat-house/tree/boat-house-mobile-android
目前发现此app 只是一个单机应用，里面的功能也非常有限，界面比较乱。
@jijiechen @ups216
app-debug.zip

这个客户端app原来没有弄 ci/cd

Answer 16 · 2020-06-15T07:30:20.000Z

这个客户端app原来没有弄 ci/cd

有的，第一期共创团队的姚胜伟最后一次的分享就是移动端的CI/CD。但是内容并没有提交到主库中。

这是我们这次整理需要解决的另外一个问题，有很多一期团队的成果并没有被收集上来。你和 @zhouwenyang 一起看一下，需要整理一下梳理一下看看有哪些内容没有收集上来，要一起收集上来放入新的主库（对应的代码，脚本要放到正确的代码库）。

Answer 17 · 2020-06-15T10:13:32.000Z

boathouse-infrastructure

quick-start (end-to-end)

devops-tools

jenkins-server

sonaqube-server

nexus-server

jira-server

azure-devops-server

gitlab-server

github-enterprise-server

environments

test (vm)

production (kubernetes)

建好了，见仓库：https://github.com/idcf-boat-house/boat-house-infrastructure/blob/master/README.md

目前还有两个问题：

如图
端到端文档部分有些缺失或不够完整

@ups216 @smallidea 看一下是否让大家提供一下？

Answer 18 · 2020-06-22T04:30:48.000Z

这个客户端app原来没有弄 ci/cd

有的，第一期共创团队的姚胜伟最后一次的分享就是移动端的CI/CD。但是内容并没有提交到主库中。

经了解，姚胜伟的方式是通过jenkins界面配置的流水线，而且是在jenkins slave上配置了编译运行环境，在这台机器上执行的编译打包，考虑到环境及sdK的复杂起，找了一个已经集成好相关环境的docker image，通过这个容器进行打包，目前已经实现github action 和jenkinsfile两种方式，具体见：https://github.com/idcf-boat-house/boat-house-mobile-android

@ups216

Answer 19 · 2020-07-08T04:25:22.000Z

k8s换成AKS，同时输出文档 @liminany , 文档
k8s重复pod节点问题需要解决 @liminany
前端加载太慢，可能是外部CDN资源被墙的问题 @smallidea
jenkins build里面有报错信息 @smallidea
docker image换到azure container registry @liminany
jira内无法创建项目 @smallidea
把nexus用起来，上游的包的包都拉过来，修改POM文件中包源头 @smallidea
Jenkins WorkSpace 中的文件因为权限问题无法删除，导致Jenkins流水线报错

Answer 20 · 2020-07-13T01:06:08.000Z

前端加载太慢，可能是外部CDN资源被墙的问题 @smallidea

已资源本地话，并压缩了几张大的图片

jira内无法创建项目 @smallidea

jira 的站点地址需要与域名相同，因为使用了nginx

把nexus用起来，上游的包的包都拉过来，修改POM文件中包源头 @smallidea

npm、maven均使用了nexus（代理模式）

Jenkins WorkSpace 中的文件因为权限问题无法删除，导致Jenkins流水线报错

git clean 的时候没有权限，在流水线结束的时候使用sudo git clean

Answer 21 · 2020-07-13T01:30:53.000Z

前端加载太慢，可能是外部CDN资源被墙的问题 @smallidea

已资源本地话，并压缩了几张大的图片

jira内无法创建项目 @smallidea

jira 的站点地址需要与域名相同，因为使用了nginx

把nexus用起来，上游的包的包都拉过来，修改POM文件中包源头 @smallidea

npm、maven均使用了nexus（代理模式）

Jenkins WorkSpace 中的文件因为权限问题无法删除，导致Jenkins流水线报错

git clean 的时候没有权限，在流水线结束的时候使用sudo git clean

@smallidea 资源本地化，Nginix配置和nexus的代理配置，这些内容都需要有文档。请补齐并发布到boat-house文档库中

Answer 22 · 2020-07-13T04:17:43.000Z

@smallidea 资源本地化，Nginix配置和nexus的代理配置，这些内容都需要有文档。请补齐并发布到boat-house文档库中

资源本地化，操作很简单，所以只是在前端库根目录的readme.md中做了说明，并没有单独开一个markdown
文档
nginx 文档
nexus 文档

Answer 23 · 2020-07-14T01:06:07.000Z

jenkins build里面有报错信息 @smallidea

这个是spring boot编译过程中的debug信息，比如

Did not match:
@ConditionalOnClass did not find required classes 'com.github.benmanes.caffeine.cache.Caffeine', 'org.springframework.cache.caffeine.CaffeineCacheManager' (OnClassCondition)

都是 “Negative matches” 的一部分，并不影响运行。

Positive matches：@conditional条件为真，配置类被Spring容器加载。
Negative matches: @conditional条件为假，配置类未被Spring容器加载。
Exclusions：应用端明确排除加载配置
Unconditional classes：自动配置类不包含任何类级别的条件，也就是说，类始终会被自动加载。

@ups216 @liminany