运维自动化基础建设|代码托管服务平台选型和规范
不知道大家有木有经历过
svn的年代，我是面对这个有点犯愁，犯愁的原因不是不好维护，而是使用过程中出了问题干瞪眼帮不上大忙。当下用这个的应该很少了，应该都切到git上来吧，在接下来的文档中我们来聊聊当前云上或本地私有化的git代码管理都有那些，以及如何仓库名称命名方式的定义应该注意些什么。
git代码托管服务平台有哪些
云上
•github•支持public和private•gitlab•支持public和private•bitbucket•没有用过云端的•码云•支持public和private
可本地私有化部署的
•gitlab•bitbucket•gitea•gogs
我们简单说下几个的优缺点
评论的出发点是我用过的几个，没用过的不做评价，以下观点仅供参考
bitbucket
bitbucket站点[1]
bitbucket是Atlassian公司出的，和我们日常所见的Jira, Confulunce是一家公司的，特点是各组件之间可以无缝集成， 比如提一个issue和对应的commit进行关联的操作。直接点击对应的链接可以在多个系统之间进行跳转操作，不过这是一款收费产品，功能十分强大。
gitea
gitea站点[2]
gitea是十分轻量级的代码管理平台，我曾经为一个小型团队搭建过，一键启动，耗用资源少，短平快。
gitlab本地部署
gitlab站点[3]
gitlab是用的最多的一个，功能齐全，更新迭代快，完善的API接口可以和CMDB以及CI/CD快速集成。个人是比较推荐的。如上文提到，gitlab本身也支持包管理(集成在pipeline里)
gitlab云上
gitea站点[4]
在早期的时候，国内码云是支持个人私有仓库的，后来可能是资源消耗过于严重把，针对个人私有仓库的个数进行了限制，与此同时，Github还没有被微软收购，所以这个时候我选择了云上gitlab作为个人私有仓库的存储方案，这样只有有网络，代码pull下来我就能进行工作。
github
这个相信不用多说，大家都知道，Github是全球最大的代码托管服务平台,早起的时候并不支持个人私有仓库，对外只有public， 后来慢慢开放了限制个数的private， 直到今年4月份，宣布针对团队的private也免费，这真的是一大利好。
github-is-now-free-for-teams[5]
码云
码云站点[6]
这是开源中国出品，相信大家也会看到不少文档，如何加速github代码克隆，其中很多文章都是借用码云做中转来进行加速的，我是用过码云的个人版和企业版，企业版倒也不贵，如下图所示
权限的管控
基于角色的账号体系管控，账号体系对接LDAP, 然后每个业务线建立对应的group, 然后给到team leader的权限为master, 这个时候他就拥有这个group的完全控制权限，拉人进组分配权限、创建project等等一系列操作都可以自助，不用OPS参与进来去做额外的工作。
代码仓库命名的讲究
问题
•你是否经历过代码仓库名称命名的五花八门•你是否经历过代码仓库命名中横线和下划线混用的•你是否经历过代码仓库命名大小写混用的•你是否经历过分不清服务到底是对内的还是对外的
基于业务分层来命名
web前端或h5
通常这些是暴露在公网的服务，命名的时候多以web或h5作为后缀，这样见字知意，便于后续的CI/CD和CMDB以及监控体系的对接。我个人是比较倾向于而且习惯用代码仓库名称作为CI/CD对应的job名称的。
example:
代码语言：javascript复制{公司关键字缩写}-{项目名称}-[{web}|{h5}]接入层
原则上这一层是承接上面我们说的web或h5的，自然而然的也要暴露在公网，大部分场景下这一层的服务是不允许和DB层的资源互通的，确保安全，所有数据资源的获取都是从service层的接口聚合而来。
example:
代码语言：javascript复制{公司关键字缩写}-{项目名称}-[{api}|{gateway}]服务层
这一层是要和DB层进行交互，但是不对外(不会暴露在公网)，这一层的服务的命名多半以service为后缀
example:
代码语言：javascript复制{公司关键字缩写}-{项目名称}-[{service}]other
其他的还有很多周边配套项目的，比如工具类的，比如定时任务类的，这个时候如果不想细分的话，可以采用tools或plugins作为后缀，具体看公司具体的场景来设定。
example:
代码语言：javascript复制{公司关键字缩写}-{项目名称}-[{tools}|{plugins}]如何选择
从安全角度出发
很多时候我们代码中会包含核心的算法以及加密方式的代码,这个时候老板们肯定是希望越少的人接触到这些东西越好，放在云端是不是意味着你所有的东西会被扫描这个我们不能百分之百确认，所以大多数场景下可能会考虑放在自建的机器或托管的IDC里，这个点仁者见仁，智者见智吧。
站在敏捷开发的角度出发
多数情况下RD相对来说是比较频繁拉取提交代码的，在保障安全的前提下，追求的是效率，那么我们代码托管平台应该放在哪里比较合适呢？用云上资源，那我办公室带宽不好怎么办，写三行代码提交等待1分钟？如果自建，建立到哪里？在办公网自建？这样的话生产环境的部署咋办？多数情况下生产环境的网络是隔离的，等等因素，大家可以评论区讨论哈，至于我使用的场景，我就不跟大家描述了～
TIPS
当前GITHUP和Gitlab也已经具备了工件库的功能，相信这块在大厂的参与下未来会更好，为企业的NoOPS赋能～
再次重申约定大于配置，很多时候大家提到的自动化运维并不是一触而就的，这中间需要经过很漫长的一段时间的修正，迭代才能符合规范和标准。
总结
代码仓库的命名规范和权限管理，更多的是能为我们后续的CMDB的元数据规范和工程化建设(code review)等等一系列工作提供一个良好的基石。敬请期待后文
引用链接
[1] bitbucket站点: https://bitbucket.org/product/zh/features/pipelines
[2] gitea站点: https://gitea.io/en-us/
[3] gitlab站点: https://about.gitlab.com/
[4] gitea站点: https://gitea.io/en-us/
[5] github-is-now-free-for-teams: https://github.blog/2020-04-14-github-is-now-free-for-teams/
[6] 码云站点: https://gitee.com/
