刚刚打得不见马的

第一次在板上发文，看板规应该是可以发

如果有问题请告知删文谢谢


本身有相当多的鬼故事，不过我想先解决问题


1.多程式版控

我们有一个版本库，里面包含了很多程式

而且是互相关联的，也就是A程式要B程式先Build过，A程式才能compile

C程式也有可能跟B关联，然后又多关联一个D and so on

变成说，CI CD没办法去compile，因为没有意义，也不会过

版本库内又塞了一火车的exe跟dll

有趣的是，这些dll要手动放到主程式内才有功能，主程式又另外有一个版本库

所以....这个版本库的版控，跟主程式有可能不一样...

而且主程式做的版控，根本看不出来dll有什么差异

你根本不知道谁更新了什么东西


我现在在想，是否可以用pipeline，去放到指定的路径做更新

这样就变成我不用去手动放，尤其主程式dll又没办法分辨差异

只是编译就是由地端去做



鬼故事是，这个主程式其实有三个

然后根据前辈所言，这三个的dll其实都有差异....


2.自动化部属

我们目前主程式的部属方法，是使用一个部属清单.txt

要上线前，工程师们会更新此上线清单，并且写入相对应位置

pipeline会去抓取该清单，然后将相对应的程式放进去更新



问题来了，如果没写进清单的程式，就不会部属

也就是说，版本库跟在线上跑的程式，有可能是不同东西

有可能下次上线，你会把别人更新的未知程式丢上去....

我尝试使用git diff跟当前上线origin/master做差异比对

分支使用该pipeline，可以把有做变更的程式给部属上去

会这样做的原因，是因为咱版控老大，说我不能全部程式更新

鬼故事来了，因为上线程式跟我们的版控可能有差异

所以我做了这样的尝试，这样操作会有什么额外问题要注意的?



额外的鬼故事，我们平常的测试环境

我用了这种方式去部属，然后被人靠腰后才发现我把别人程式盖掉

因为他们会去server端把程式拿出来做比对，再把程式手动放进去

所以我用测试分支搭配此pipeline去部属我的程式，会抓不到别人更新的内容而盖掉....

前辈说我不能这样破坏别人的程式，每一次要放进测试环境都要比对

我哪来那鬼功夫每次做这种事情



然后我真的觉得写部属清单实在有够白痴，真的白痴到个无极限

因为工程师有可能忘记放进去自己的更新

但是我前辈却坚持一定要用这个，不然会部属错程式zzzz

我说你这样不是会让没有上线的程式，进入上线程式的版控吗?

他说部属清单没有，没事

所以我甚至还写一只Powershell程式，来把该次上线变更内容条列出来

我实在无法接受使用部属清单上线..


3.平行上线分支的开发方式

我们只有一个准备上线环境，搭配QA测试会有时间差

这周QA测试上线一版，下周上线另一版，可是第三周才会把第一周的把程式上线

也就是说，这个环境同时会有两个上线分支


但是，因为测试会搭配BUG修正

两个分支会互相干涉，尤其同支程式

搭配上我们同仁们，还会用复制资料夹的方式来备份

并来并去并成鬼样，可以怎么改善?



以上

来聊一点鬼故事

我们的dll版本库，总共有3个主程式，然后据说3个版本皆不相同


程式部属一定要使用部属清单，不然会怕部错程式，可是没部属到的可以手动丢进去

无法退版，尤其多人同时开发一支程式更困难，所以我们会有上线失败问题
(目前发生会采装死赶快bug fix的方式)

我的想法是，开发给QA的测试分支DEV，跟实质上线分支应该要分开

确认开发完成，工程师再分别并入上线分支

任何一人的有问题，则revert该次合并commit即可

但是我前辈一直保证会有人开发不该上线的程式，所以不能自动部属

即使我说了，工程师怎么会放进不该上线的程式，PR的人怎么会让他并进去

还是被要求一定要去写一支永远都会有冲突的部属清单

而且每一次上线负责人都要去一个一个人问，因为部属清单无法辨别负责人



某些层面上，我真的觉得我们的程式还能动是奇蹟

我们单位上，100%的前辈不懂git

我是转行过来的，本来也不懂，所以我花了点时间学

程式写得好不好再说，这种基本功....

然后进来大公司后.....

是我的问题，还是我该逃命，我很努力跟主管提需求跟修改计画...

实在力不从心



感谢你各位看这么多

找下间 你领多少帮公司操心这个

同意楼上，然后第二点看起来你们实际上只有一个测试环境，所以你不应该使用自动化部署盖掉别人的改动。

你也在金融业吗？

dimension版控系统？你要在既有设计的系统与版控下去透过其他方式解决，有可能增加其他人不能接受的复杂度。根解就是系统跟版控重构解耦或是快逃（认真）

真的想解决这个问题的话就要思考怎么把你希望的解决方法带进开发流程，都是老实讲你有这个想要改善的想法把他带去更好的公司应该对你更有帮助

不能合并?

满有意思的~不过真的推不动也只能找下间+1

也太乱了吧.....要解决1就是重新拆分程式组件化可以轻松很多妳所有难题都是从1来的git 有sub module 整理完程式之后好好规划这部分起码可以解决过度相依的问题...DLL要变更就是他自己的板控，这样就不会有版本问题前面这块确定，这样后面布署也不会是问题CICD可以指定档案复制去任一资料夹就只是看要选哪套自动化的组合而已

没有主管支持就是快逃

傻眼耶 原来真的有公司的CI/CD是这样搞的 难以想像 你们是用Jenkins吗

有想朝devops发展可以试试，没有的话别碰，到时候有问题都算你的，没问题还是你的这种永远都不是技术问题，每次都是人的问题，一些垃圾方法提解决方案还被说干嘛那么麻烦就很想给他巴下去==

有逃命的选项也是可以直接逃啦

其实这不一定是用哪种tool的问题 是release flow的问题flow没先大家谈好 科技帮不了你们 就是你们是每分每秒都想上patch/code change, 也只能谈好update pipeline的时间点跟各个lib的版本 没有那么简单也不是用某某tool就OK

主管都没差你帮他们操什么心，省点力找下一间比较实际

版控不是只有程式码版控，建置产出的程式也要版控啊A依赖B没问题啊，A建置时去拉指定版本的B产出的程式exe和dll也一样，全部进到同一个产出程式的版控里啊你们问题看起来就是程式码到执行环境间少了一个repository

找下家 改了你也不会加分 改差了黑锅就是你 说得动主管才是重点 没人挺你妄想改变公司什么太难了 我懂 台湾一堆毒瘤技术前辈只是因为老不是因为技术好 又在公司时间跟三叶虫一样久 久了就越来越没动力帮公司优化什么上版流程 优化自己履历还差不多“这只有你会用”你要呛回去啊 你们不会吗？不会要学啊 这有很难吗？现在99%工程师都在用的东西不学？公司让你来工作是来说“我不会”的吗？然后隔天跟主管说要离职XD

我开始怀疑你跟我同公司，你家系统应该历史很古老，超过三十年，中间接手过很多人，现在负责人已经是n手也改不动，你家cicd不会是azure吧XD

这是政治问题 你是新人吗？是的话 嗯 不是的话，等你有权有势再做

这是政治问题 不是你问到什么比较好的做法去讲讲课他们就会听你的 大家出来都混口饭吃而已 忧国忧民不如管好你自己

听起来很像应该要有套件管理，但是变成手动在做？不是很确定贵公司用的框架，以Java来说，各自的程式库jar会有独立repo,也有自己独立的release cycle。反正就各自build ，放到nexus server就好，主程式或是有相依的程式库，需要就更新自己的pom档，类似的逻辑应该很多框架都会有吧？

mono repo然后全部cicd重新compile 不然就快逃

软件只要能动就不要去改它，旧架构再烂也不要去乱动它，公司要的是软件继续改版卖钱，不会在意技术上改的多好或多烂

这是人的问题，没救，等你位置比他高才有可能改变，我上一间也87%像手动部署、版控乱七八糟，所以我逃了

全力改好也没人懂，改后出的所有 bug 全算在你头上，谁扛的起？

maybe monorepo + bazel，common libs 可以写一个 buildrule，只是大家版本要先一致

另外这种职场有毒，新人进去阵痛期很长受不了的、看不下去、有能力的都会早早走了留下来的多半是走不动、或变成这形状的人有点劣币驱逐良币了，劝你快逃

这么不爽还不跳一定是给的钱太多了 XD

不知道是你家量体太大还怎样 我怎么觉得听起来正常...那些相依的proj 其实跟你用开源套件 甚至语言及平台本身支援的版本是一个概念 只是不是你在控 所以你不觉得有异因为通常只要保证向下相容就好 大部分情况皆会啦也没必要每次build就从相依根源开始 所以拆成主体+dll各有各的repo的形式也可以理解 全看上层proj的owner决定有没有必要随时跟进 所以说起来这还真不是单一RD能解的毕竟要做mono repo 还得看什么角度下去切分layer/domain/BU...what ever感觉只能找人一起向上提 让各leader关一间后 2也会解决XD通常这种问题要说服不能用开发角度 要用管理成本才讲得通但你有多硬 以及领的钱值不值得花这个effort 就看你啦我是觉得你家东西看来明显需要decouple跟加一些中间规则就算用了你的做法还是会整天进进退退 跑这就饱了所以你跑比较快 嗯

真的要推就自己搞一套独立环境跟其他人分开跟上头说是备援用的 等到哪天原本的爆炸就可以拿出来邀功了 但等于是要多花心力做这事

这个制度已经运行多年，很难以一己之力去撼动。

赶快去找下一间比较实在==

整个看下来 就是快逃阿

主管不支持==没戏唱，我也懂你整天被逼着吃屎的心情，只能说快逃，不要让自己习惯吃屎除非他钱给得够多

我自己现在就是在搞独立环境 从Git-SVN开始 甚至想搞本地CI/CD 因为我也知道开发习惯这件事真的很难改==但是我公司都还没到你公司那么大便就是了 顶多甲方有改东西不跟我们讲 自己长出东西部署又有问题 公司还要想办法甩锅

金融业+1

你就管好你自己负责的就可以了 自己负责的东西有要上线再丢清单就好顺带调低自己开发的步调半养老

你不用操心 你操心就会是你处理 然后不会有人感谢你

只要没有其它痛点是可遇不可求的职位可以有多的时间去沉淀去思考其它的东西以逸待劳 以静制动什么都要你主动的那才叫恐怖 累死你有多主管很不尽责的 讲少少要你自己去厘清一堆东西那有没有主管有差吗

真恐怖XD

有些还会紧急时含糊其词拖你进度 当然慢下来可以 但

资深的不会想学新东西啦，不会用也不想会用

没出事就不要多事,感觉你们也算维护现有服务为主的单位只是为了看不顺眼版控去更动结果服务爆掉 上面怎么看这单位? pip人头可能给你们多塞几个版控最主要目的还是众人协作的共识,不是非业界普遍操作或是你看不顺眼的操作就是需要推翻的,主要是部门内共识我自己去支援别部门开发产品也是尊重他们原有开发共识就算看不顺眼也不会去做什么更改

以前我在软件公司当RD,SD,SE,..每次要推这些都很难后来在营业单位当IT,全都没权限下,还是有办法弄离线省下自己的时间,反正系统全外包,有事没事都当我的事反正待业务单位,完全失去资讯/情报/执行/等等能力一个销售单位只能玩玩简单的excel,完全搞不懂为何卖得好为何卖的差,也难搞行销专案,光法遵就无力应付

看起来你很心在公司持续发展，但要听一个新人的老一辈不会服的，这是人性

八成是金融业

其他的点还好说，第一点…..

啥啦 你很闲是不是…

你该跳槽了

在这种比较政治的委由顾问第三方来做也是可以考虑的

这种东西感觉也在敝司里发生…

请你去煮一盘大便，然后问你大便怎么煮的这么难吃+1明明是上面说要做的,然后再来问你怎么做这么烂...

如果你的职等比别人低 不要想太多 如果一样 可以力求表现 不是技术导向的文化 很难改变

git很好。但不是所有环境都"必须"要用git。而且这篇的问题看起来不在版本控制工具，而是在沟通或流程本来就不顺。流程顺了用不用git没差。流程不顺，你用git也没意义。

我也觉得不必为了用而用 如果现在开发流程 大家都觉得很棒你说服不了别人 只有你觉得不棒那这种情况 是你不适合这个团队 你应该找个适合你的地方如果你很在意技术 很在意软件工程 你应该去重视这些的团队继续在这里 只是消耗自己 迟早忧郁症 我过来人 供你参考

逃

都还是新人,什么公司的流程架构简单到还是新人就能熟悉透然后自以为可以去修改整个架构?每个新人进来都说XXX好用,多的是导一半离职或直接失败的,在还没真正深入了解之前,先跟随团队既有的模式去熟悉了解,再来谈改善架构吧当你觉得老人都顽固不想改变的时候,也要想一下老人是不是也

听起来有些人连基础的commit都有问题，所以不用太操心，该跑就跑

认真回 感觉很简单就可以完成

这就是为什么很多公司想做DevOps做不起来或很不顺的原因

关于dll的部分，可以考虑始自建nuget server

流程本来就是公司有power话语权的人在推 这没什么 你去别家有话语权后人家也是听你的盖别人code是职场大忌 所以上传完我都会再检查一次工作不是自己做好就好 团队也是一部份 不舒服就离开这样而已

我不知道你怎检盖查code的，但只要善用git --git-dir和git --work-tree，连没有git的专案我都能生版本管理出来然后比没有git更惨烈的状况是两个用git的各自坚持merge看到新的就fetch，没冲突就merge有冲突就rebase爽爽

这是flow的问题flow的问题就是政治问题

我还是看不太懂这跟有没有用git有什么关系。大家code不同版本可以搞到不兼容，盖掉就不能用，首先我会想到的是：没人订整合的规格与流程吗？ 没人订，你用了git，也是到处冲突，还要不断的改冲突，不断的看别人改什么，真的并没有比较好。有人订了软件规格与流程，用不用got没差，反正模组间的接口规定订好都兼容就好。git认同版本要控制与管理，但真的不一定用git就能解决问题。流程比git重要太多了。程式码内容大家有版本差异也是，流程不改，持续用git到处比对，根本不能解决问题。订个流程与规格才能解决。用不用git跟本不是问题。git工具很好，没否认。但流程与规格更重要

提出问题，拿出解决方案，推销你的方案，落地。你写的太乱了，所以没有细看，但我猜你应该是有发现问题，但没办法拿出一个适合你们公司的解决方案

我以前遇过每次上版把所有人的code覆蓋掉的臭老头后来他先不爽我们自己跑掉了 南无阿弥陀佛

推流程比较重要+1~虽然新人可能不太能改这个...

年青都会觉得能抗，掌权很孬，都这样过来的，但其实能扛什么，能扛就不会不能做主。准备好完整方案，持续沟通，连这种信心度爆棚的都难沟通，之后信心度不高的怎么沟通。离职或跟随也选项。

你可以有情绪推动不了就换公司呀，也可以排除所有障碍去达成，没有哪一个比较好，但陷在情绪里面对你自己没有帮助

拜托不要再花时间脑力去把这坨大便改善了 准备履历优先照前辈的流程走 不要有意见 但做好不久留的心理准备

建议你，找到好方法去检查或处理你自己认为大便的事情，节省自己花在维护上的时间，其他人就别管了

这陀大便变成今天这样老员工都有责任，你也别想改变了，只会碰一鼻子灰

快逃

你这个问题看起来很多 不要想一次到位 这个要一点一点改善版本库里面不该放 exe DLL 这些 build出来的档案然后应该要有一个档案 来记录每个环境是使用哪个版本号部署阶段就去拉那一些档案主程式里面应该要维护一份 每个子程式的版本号相依关系