RT. 在下自己打算写一个发布系统,大概思路是通过打 tag 和线上版本进行对比,团队确认没有问题就通过 rsync 同步代码。但是现在有个问题,是假设 A 同事打了一个 tag1 , tag1 和线上版本对比,只有 a 文件有修改。 但这个时候同事 b 也提交了一个 b 文件, b 同事也打了个 tag2 ,和线上版本对比,只有 b 文件有修改。这时候 b 同事先发布。 那么!问题来了,这个时候如果 a 同事进行发布(假设 a 延迟发布了),那么就会把 tag1 发出去,此时将 b 文件给覆盖了。要如何解决呢?我的思路是创建一个发布流程前就加锁,但是这样死感觉很有点 low 。
各位有好的办法吗?
1
zhuyao 2017-03-10 17:21:38 +08:00
设定权限?
|
3
skydiver 2017-03-10 17:50:06 +08:00
后打的 tag 必须包含前一个的 tag 的内容。
或者直接规定只能在某一个分支上打 tag 。 |
4
VeryCB 2017-03-10 17:54:27 +08:00 via iPhone
感觉不是发布流程的问题,是开发流程的问题...可以看看 git flow
|
5
SpicyCat 2017-03-10 18:05:06 +08:00
按照 git commit 的思路,每个 commit 只记录变更。
同事 A 只改了文件 a ,那么上传的时候,系统只执行文件 a 的更改,其他不变。同理,同事 B 改了文件 b ,也只执行文件 b 的更改。 这样,不管同事 A 和同事 B 的发布顺序如何,都不会彼此覆盖。 除非同事 A 和同事 B 更改了同一文件的同一个地方,那么会有冲突。这时候,后提交的人就会被提示有冲突。 |
6
domty 2017-03-10 18:55:50 +08:00
没用过 git 吗
我们这里的方式是借用 git 的分支进行发布。只允许发布 master 分支。 平时的开发使用自建的开发分支,上线前将开发分支的代码合并到 master 。 这样像你这种情况下 a 如果等到 b 提交代码后进行发布的话会把 a 和 b 的代码一起发布。 |
7
hxsf 2017-03-10 19:28:33 +08:00
发布走队列,同一个项目只能同时发布一个版本。
|
8
Felldeadbird 2017-03-10 23:01:41 +08:00 via iPhone
为什么不基于版本库进行更新啊。
|
9
kmahyyg 2017-03-11 00:32:17 +08:00 via Android
git + code review
|
10
cxbig 2017-03-11 00:37:12 +08:00
一般小的提交+RP 用不着 Tag
不同的程序员接到不同的任务,怎么会有相同的 Tag 呢?这是管理问题吧? |
11
AccIdent 2017-03-11 00:38:41 +08:00
噗莫名想到 false sharing
加锁可以(悲观),或者用版本号做检查(乐观) |
12
SoloCompany 2017-03-11 04:21:58 +08:00
你这是拿 tag 当分支来用?
正常系统的 tag 必须从指定分支抓取(比如 master ) 即使你不走 review 流程,起码可以保证没人可以 force push 从而覆盖别人的变更 |
13
guoqiao 2017-03-11 05:54:50 +08:00 via iPhone
似乎是对 git 的使用不够了解才会引出这样的问题
|
14
murmur 2017-03-11 07:09:31 +08:00
上线之前还有仿真环境 仿真环境的代码才会推到生产服务器上
|
15
paulagent 2017-03-11 08:22:06 +08:00
目前一个项目,就是只有 master 才能发布到生产环境,开发人员在 branch 上开发,然后提交 merge , 别的同事 review 万事,同意的话就 merge 到 master 上然后直接跑测试,通过后自动发布。谁先谁后不重要
|
16
nicevar 2017-03-11 09:09:50 +08:00 via iPhone 1
master 用来发布, tag 用于发版之后,开发在分支上并分配权限,搭个 gitlab 之类,分支上开发完成后发起 merge request ,有权限的人 review 后决定是否 merge
|
17
lyao 2017-03-11 10:13:05 +08:00 via Android
git town
|
19
pizida OP @domty 用过 git ,但是目前公司全都是用 svn 管理的。那这样是不是也可以用 svn 的 branch 各自开发,开发完毕后提交到 master ,然后 master 跟上一个发布版本对比一下,没问题就进行发布呢?
|
20
pizida OP @Felldeadbird 不太了解,基于版本库更新是什么意思。目前用的是 svn ,每次都会先 svn up 的
|
21
pizida OP @SoloCompany 你好,我用的是 svn 管理项目。是不是应该新建分支开发( svn branch ),然后测试 ok 就 merge 到 master 。然后发布 master 。
|
22
pizida OP @paulagent 如果 merge 到 master 之后,发现有点问题,这个时候没有回滚,但是其他同事就发布出去了呢?
|
25
Infernalzero 2017-03-11 19:13:32 +08:00
基于 svn 的这种蛋疼发布系统我之前也有搞过,无非就是仅同步想要发布的文件, php 之类的可能还好些, java 的话一旦有人漏提交就会导致 build 失败,而且还得去发布系统填个发布请求,填上对应的文件,特别蛋疼,只会降低工作效率。讲道理,发布系统就不应该管版本控制的事,做些静态检查倒是可以的,版本控制用 git 或者 hg 完全足够了
|
26
Felldeadbird 2017-03-11 22:31:35 +08:00 via iPhone
svn 的话我没解决的方案。
我在的公司内部是用 git 的。每个人都通过分支开发,然后我进行合并到 master 分支。最后通过发布系统推送到对应的服务器。 |
27
akira 2017-03-12 01:23:02 +08:00
svn 的话 你要看看分支代码的合并那一块怎么处理的
|