协同开发的Git服务器增加备份服务器功能

当前活字格支持协同开发，采用Git源码管理的方式。例如使用Gitee码云服务，或者自建的局域网Git服务器等进行源码管理，很是方便。遵循代码风险控制的一般原则，一般不把鸡蛋放在同一篮子里，万一篮子坏了，宝贵的源码就全丢失了。（如果采用git模式协同开发后，代码物理安全风险会全部转化在代码托管的服务器的风险控制上）。
所以，建议增加一个可选的备份git服务器地址,在每次提交代码的时候，也同时自动向备份服务器地址提交代码。
以我们为例：我们在内网服务器构建了GitLab，将活字格的代码提交在上面

同时也可以在gitee上注册服务，作为备份服务器地址，如果活字格可支持一键同时提交主服务器和备份服务器，相当于自动做了异地容灾备份：


PS：当然，比如Gitee企业收费板等，自然会有企业级的备份计划，那岂不是直接用这个不就好了。的确如此，但是这还是把鸡蛋放在gitee一个篮子里面，万一gitee员工如前段时间的XXX事件一样删库跑路，这损失也大了。所以自动化的容灾备份从来都是不嫌麻烦的。

我想这玩意不是同文件备份一个道理吗？

Simon.hu 发表于 2020-5-14 09:36
我想这玩意不是同文件备份一个道理吗？

是一个道理。只是小白化与否以及是否可以更傻瓜化设置的问题。
例如可以要求定时手动将协同项目保存成本地文件，然后备份到特定的服务器也是一个办法，但是要么需要增加一个人工来额外做这事情（还得看他是否记得住，就要拟操作规范啥的），要么要写个程序自动执行这个操作，那就是DIY自力更生了~
例如也可以在gitlab设置自动文件备份，因为gitlab多配置在linux下，配置起来还是需要一些玩过的专业人士，要不然半吊子配个有问题，等到出问题了发现文件没备份上，就惨绝人寰了。
所以，如我所说，容灾备份做过一些也不为过，能集成在一个平台上，傻瓜化操作就能更普及，更安全，对大部分快速平台的使用用户来说总是好事，也更符合咱们活字格的用户定位：专注于业务，懂得少量程序知识即可。

我理解的您的意思，但是我自己写的代码也是的直接放到Git上的，似乎也没有备份的机制，这样，我先问问他们的代码是怎么搞的哈~

Simon.hu 发表于 2020-5-14 10:46
我理解的您的意思，但是我自己写的代码也是的直接放到Git上的，似乎也没有备份的机制，这样，我先问问他们 ...

  这玩意儿，就像是和买保险一样，可能99.99%的情况下是没问题的，一旦出问题了，就会发现人人都开始甩责任了   如果是个人自己的代码，丢了大不了叹气一声，闷声吃亏也就吃了。如果是企业用，领导开始追责，有的人员就开始帅锅了：开发的甩给运维的，运维的甩给选型平台采购的，采购的甩给平台本身~
这也是某些体系的重要性，但是实施体系本身又太束缚生产力了，所以应该要有这样那样更智能的做法，能自动化匹配安全体系，就完美了

O了~

我们的CI/CD可以搞定这个~