事情是这样的对接项目,刚开始对接的 A ,版本号是 1.0-snapshot ,然后对接 B ,版本号升级 1.1 ,后来又有新业务对接 A 的时候,A 说“这干嘛加版本号”,“每次你改我还得在改一下我的 pom 文件”,“上一次 XX 就是这样搞的 我的生产线上代码直接报错了”,“这东西最好不要改 要不然 每次都得沟通一下”,于是我作为一个实习生,就没有争辩,就把版本号改回去了,改成了 1.0-snapshot (之前他引用的版本),然后新业务对接 B ,给 B 说版本号是 1.0-snapshot ,B 说之前都升到 1.1 了怎么又改回去了,然后叨叨了一大堆。A, B 是一组的,B 是那个组的组长,还说什么版本号达成共识就行,自己一个组的人都没达成共识。
问题:
我为啥一直是实习生,本科大四的时候在一家几百人的公司实习,后来觉得没劲就考研了,再后来就在这家公司实习,这家公司是国企,开发大概 50 人左右
1
gexyuzz 2022-03-19 14:34:08 +08:00
|
2
mineralsalt 2022-03-19 14:34:44 +08:00 7
首先, 每次发版本, 版本号必须累加, 这是铁律. A 的问题让他自己去解决
|
3
dayeye2006199 2022-03-19 15:11:12 +08:00 via Android 1
这个公司没有 artifacts repository 的吗?
多版本号共存应该也不影响使用才对,各个项目依赖不同版本是可以的。 |
4
cppc 2022-03-19 18:35:57 +08:00 via iPhone
A 的想法也正常,你维护的 lib 升级了新版,应该有一种机制让使用方知道改动了什么,升还是降自己看着办。从你的描述看应该是 B 有新需求导致升级,那这跟应该没关系才对,所以没理由让别人跟着升级
|
5
passer9527 2022-03-19 19:49:19 +08:00 via iPhone
我们所有服务都是 1.0-snapshot ,全部统一。就为了避免楼主这种问题
|
6
buliugu 2022-03-19 23:30:08 +08:00
开发用 SNAPSHOT,生产用 RELEASE ,RELEASE 必须升版本
|
7
Lighfer 2022-03-19 23:30:20 +08:00
我们的解决方案是使用远程依赖加载,开发环境下,非 API 层面的变动,依赖的提供方直接替换远程的版本即可,正式发布前则要求引用方必须更新版本号。
|
8
Buges 2022-03-19 23:52:01 +08:00 via Android
要看具体引用的方式。如果是引用某个固定的版本,发新版本自然按正常流程升级。如果是引用 git/devel/master 滚动版本,那才是每次都拉取最新 /主线版本。
|
9
alexmy 2022-03-20 00:48:42 +08:00
A 用 1.0 ,B 用 1.1 。应该都有 maven 私库,都是共存的吧。
|
10
ikas 2022-03-20 00:54:58 +08:00
快照版本开发模式
开发过程中使用 snapshot 版本,但是正式版本禁止使用 snapshot 版本 比如你们需要开发 1.0 版本,那么开发过程选择 快照版本开发模式,那么版本就是选择 1.0-snapshot ,然后一直开发提交,中间也可以将 1.0-snapshot 推到自己的 maven 中央库,别人的项目也会拉取你这个最新的版本 当你开发完成后,那么这时候就是将此时的 1.0-snapshot ,定为 1.1 或者 2.0 等等... 当开始下一个版本时,就是 1.1-snapshot,2.0-snapshot,等等 |
11
Niphor 2022-03-20 11:49:30 +08:00
我觉得这是人际关系的问题,和升不升一点关系都没有
|
12
DinnyXu 2022-03-20 11:55:28 +08:00
我们现在一个项目有几十个微服务,关于版本相互依赖这件事,最好是有个私服仓库进行管理,一楼的是最标准的答案,也是我们目前实施的方案。
A 的想法就是个错误的想法,你既然微服务 A 产生了代码变动,如果是小迭代升版本是应该的,而不是为了“偷懒”或者说改了要沟通什么的... 你升级版本,别人需要依赖你的微服务,自然就要把版本写成跟你一样的,我认为这是理所应当的,还有就是你 A 升级为 1.1 后,正常来说会有个 relase 版本在私服管理着的,这样 B 就不需要改动。 最根本的原因还是你们没有私服管理....还有就是 A 太懒了.... |
13
ldyisbest OP @dayeye2006199 #3 artifacts repository 是什么,我们有 maven 的私服,微服务的 api 会打包部署到私服
@cppc #4 都是微服务,我们的微服务有 api 和 service ,api 是打成 jar 提供给别人引用的,因为要新增加接口,于是就升级 api 的 jar 包的版本,但是 A 不愿意升级 jar 版本 @passer9527 #5 我觉得不改 jar 版本是很混乱的,毕竟 maven 仓库设计的时候就带有版本号,比如要删除某些 API , 有些人还没迁移,那么那些人打包的时候就会报错 @buliugu #6 我们没有区分,都是一个 maven 仓库,snapshot 和 release 也是混用 @Lighfer #7 我修改的就是微服务的 API 层,新业务新增加了个接口,打 jar 包升级了版本号,所以我认为他应该引用新的版本号 @Buges #8 是微服务的接口层, @alexmy #9 是的,新增加功能 A 也不愿意升版本,这样的话 每次增加需求 除了正常升级版本打一个包,还要打一个 1.0 的包(给 A 用,暂时是这样) @ikas #10 是的,但是 A 不愿意改他的 pom ,我觉得他认为这样需要沟通成本,并且可能会出错,代价比较高。 @Niphor #11 是滴,说的太对了,我想问的就是这样该怎么处理, 我的情况是我是实习生(差不多可以算 2 年开发经验吧) 国企 几十人开发,所以我就无所谓他们怎么搞,他们说啥就是啥 @DinnyXu #12 有私服仓库,但是没有规范约束如果使用,个人也觉得是 A 的问题。不过我没有计较,人家是好几年开发经验的正式工,而我只是实习生 |
14
Lighfer 2022-03-20 17:14:11 +08:00
@ldyisbest 如果是生产环境中已经在使用的 API ,不建议直接发生变化,有 BUG 内部处理,新功能必须改接口就新增一个,或者按版本号划分。生产环境中其他服务正在稳定使用的任何接口非必要不要动。
即使是在开发环境,频繁发生 API 变更也会大幅降低团队的工作效率的。 |
15
Lighfer 2022-03-20 17:16:12 +08:00
这个问题无论用 snapshot 版还是远程加载或者其他的,你 API 一旦变了,别人的代码中如果有用到,就不得不跟着改,这对引用方来说就不是只改个版本号这么简单了
|
16
ldyisbest OP @Lighfer #14 是的,我同意你的看法,我的做法就是新增了一个接口,并且本身就是新业务 新增接口,并且增加了 api 层的 jar 的版本号。在这个情况下 A 也不愿意改他的 pom 文件
|
18
Niphor 2022-03-20 17:33:28 +08:00 1
这种还是得看里面每个人的人际关系有没有摸清了,谁强硬、谁说话好使。然后动态都发部门群里...先当缩头乌龟。
转正了你管他是谁,只要领导觉得你行就行了 |
19
ldyisbest OP @Niphor #18 国企要钱没钱,要技术没技术。不打算转正,6 月份准备跑路了,不找事还好说,现在谁刚我我刚谁。研究生全职实习月薪 3.5k ,干的活跟正式员工一样,前段时间还算绩效,连 3.5k 都发不到玩个毛
|
20
ldyisbest OP @Niphor #18 在多说一个事,A 之前私自改线上数据库( A 有线上权限,数据库的权限管理也很乱),几百万的表,增加一个字段,把线上应用卡崩溃了十来分钟。没过多久又私自改库,把线上应用卡崩溃了十来分钟。 实在是没眼看
|
21
Niphor 2022-03-20 17:44:25 +08:00
所以其实 OP 心理其实早就想清楚了 🙃
|
23
yoloMiss 2022-03-20 21:48:30 +08:00
这 还是开发流程有问题吧,snapshot 是作为开发版本或者测试版本发布的,既然两个系统对接那就不应该用这个版本号了。
|
24
bthulu 2022-03-21 08:35:54 +08:00
不是有 maven 私服么, A 用他的 1.0-snapshot, B 用他的 1.1 不就好了
|
25
ldyisbest OP |
26
zzfer 2022-03-21 10:26:08 +08:00
你的包应该像其他 maven 依赖一样,两个包的版本并存再你们的 maven 私库里
|
27
bthulu 2022-03-21 15:10:08 +08:00
@ldyisbest 为啥新加功能要打两个版本的包? 1.0-snapshot 打包放到仓库里就不用管了, 后面加新功能, 只打 1.1 的就好了. 谁需要新功能, 谁自己去升级到新版本. 不需要新功能的就不用强制升级.
|
28
ldyisbest OP |
29
zzfer 2022-03-22 09:56:17 +08:00
@ldyisbest 你没描述清楚,大家都以为是 A 不需要新功能,并且原来的 1.0 版本没有了。如果是 A 也需要新功能,你直接抽出身来,让 A 和 B 谈就行了,
|