PTT職涯區 / Soft_Job (軟體人)

[討論] 公司內部版控

看板Soft_Job (軟體人)作者 (我阿肥拉)時間1月前 (2024/12/29 00:03), 1月前編輯推噓42(43推 1噓 174→)
留言218則, 62人參與, 1年前最新討論串1/3 (看更多)
剛剛打得不見馬的 第一次在板上發文，看板規應該是可以發 如果有問題請告知刪文謝謝 本身有相當多的鬼故事，不過我想先解決問題 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 我是轉行過來的，本來也不懂，所以我花了點時間學 程式寫得好不好再說，這種基本功.... 然後進來大公司後..... 是我的問題，還是我該逃命，我很努力跟主管提需求跟修改計畫... 實在力不從心 感謝你各位看這麼多 -- 戒除少女漫畫有甚麼難的? 我就成功過好幾次 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.225.179.239 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1735401791.A.892.html
推
12/29 00:15, 1月前 , 1F
找下間 你領多少幫公司操心這個
12/29 00:15, 1F
→
12/29 00:25, 1月前 , 2F
同意樓上，然後第二點看起來你們實際上只有一個測試環
12/29 00:25, 2F
→
12/29 00:25, 1月前 , 3F
境，所以你不應該使用自動化部署蓋掉別人的改動。
12/29 00:25, 3F
我們有一個測試環境跟一個準上線環境 測試環境給工程師用，準上線環境會給QA測試使用 我是聽從說測試環境就給我們隨便丟程式塞，結果剛好該次有同事也開發同一隻 被蓋掉後還high light 我只想說，是因為我做自動化測試 不然你根本不知道是誰蓋你的(因為平常所有人都是手動處理) 雖然我確實不應該蓋掉別人程式，對你是對的 不過目的上是希望可以自動化部屬準上線程式跟正式上線程式 我只好先從測試環境測試
推
12/29 00:26, 1月前 , 4F
你也在金融業嗎？
12/29 00:26, 4F
沒辦法透漏太多欸QQ
→
12/29 00:30, 1月前 , 5F
dimension版控系統？你要在既有設計的系統與版控下去
12/29 00:30, 5F
→
12/29 00:30, 1月前 , 6F
透過其他方式解決，有可能增加其他人不能接受的複雜度
12/29 00:30, 6F
→
12/29 00:30, 1月前 , 7F
。根解就是系統跟版控重構解耦或是快逃（認真）
12/29 00:30, 7F
我現在就是想要解構重弄 新進的都能接受，但是掌權的在老人手裡，他們完全無法接受 我提出討論跟解決方案嘗試，被懟說這只有你會用 真的沒塌掉是奇蹟
→
12/29 00:37, 1月前 , 8F
真的想解決這個問題的話就要思考怎麼把你希望的解決方
12/29 00:37, 8F
→
12/29 00:37, 1月前 , 9F
法帶進開發流程，都是老實講你有這個想要改善的想法把
12/29 00:37, 9F
→
12/29 00:37, 1月前 , 10F
他帶去更好的公司應該對你更有幫助
12/29 00:37, 10F
我剛進來的時候，看到commit history長這樣 2024xxxx 程式更新 我差點把胃吐出來
→
12/29 00:38, 1月前 , 11F
不能合併?
12/29 00:38, 11F
你是說平行分支合併嗎? 這部分被搞得很複雜 有人要退版，結果會變成兩支分支一起退版 然後又因為開發分支合併多次，導致很容易出問題 又有同事會用手動退版，自己把寫的內容挑出來刪掉 退來併去的，我常常覺得公司錢真的很多，浪費時間在這種瑣事上 而且居然還沒垮掉
推
12/29 00:40, 1月前 , 12F
滿有意思的~不過真的推不動也只能找下間+1
12/29 00:40, 12F
我真的是打從心底沒辦法接受部屬清單這件事情 題外話，我前公司用SVN，但是當時面我的主管說會用git 直到我去學git才發現根本就沒人會用 總共六個工程師，3個人的開發project我推不動git 我老闆覺得浪費時間，新的主管工程師說不要這麼麻煩 然後老屁股工程師說，SVN太多commit很難看，不要一直commit 即使我用git去併svn，我都沒管別人了還會被老屁股靠邀 現在公司更大，根本變成天方夜譚
推
12/29 00:55, 1月前 , 13F
也太亂了吧.....
12/29 00:55, 13F
→
12/29 00:56, 1月前 , 14F
要解決1就是重新拆分程式組件化可以輕鬆很多
12/29 00:56, 14F
→
12/29 00:57, 1月前 , 15F
妳所有難題都是從1來的
12/29 00:57, 15F
→
12/29 00:58, 1月前 , 16F
git 有sub module 整理完程式之後好好規劃這部分
12/29 00:58, 16F
我有想過sub module 但是要把所有DLL 程式庫個別拆分出來 他們現在全部包成一包 然後部署清單這個是另一個故事…
→
12/29 00:59, 1月前 , 17F
起碼可以解決過度相依的問題...
12/29 00:59, 17F
→
12/29 00:59, 1月前 , 18F
DLL要變更就是他自己的板控，這樣就不會有版本問題
12/29 00:59, 18F
→
12/29 01:00, 1月前 , 19F
前面這塊確定，這樣後面佈署也不會是問題CICD可以指定檔
12/29 01:00, 19F
→
12/29 01:01, 1月前 , 20F
案複製去任一資料夾就只是看要選哪套自動化的組合而已
12/29 01:01, 20F
那就跟我的想法相同 CICD時去指定
推
12/29 01:12, 1月前 , 21F
沒有主管支持就是快逃
12/29 01:12, 21F
推
12/29 01:18, 1月前 , 22F
傻眼耶 原來真的有公司的CI/CD是這樣搞的 難以想像 你們是用
12/29 01:18, 22F
→
12/29 01:18, 1月前 , 23F
Jenkins嗎
12/29 01:18, 23F
推
12/29 01:57, 1月前 , 24F
有想朝devops發展可以試試，沒有的話別碰，到時候有問
12/29 01:57, 24F
→
12/29 01:57, 1月前 , 25F
題都算你的，沒問題還是你的
12/29 01:57, 25F
我還直接表明沒關係問題算我的 但是你真的不要太期待 複製資料夾當備份…
→
12/29 01:58, 1月前 , 26F
這種永遠都不是技術問題，每次都是人的問題，一些垃圾
12/29 01:58, 26F
→
12/29 01:58, 1月前 , 27F
方法提解決方案還被說幹嘛那麼麻煩就很想給他巴下去==
12/29 01:58, 27F
這點是我別的憤怒原因就別提了 我到職的時候就跟主管提過這會出事的 接著搭配著我各種拐彎抹角分享技術的形式 教同事怎麼使用 然後，主管還是只聽前輩講的 改善流程計劃也是參考前輩的意見 我都用各種形式去讓他知道我會這工具 但是前輩在這位子資深 所以我的意見麻，不是很重要 我被問過，為什麼我要照三餐Commit 呵呵呵…
推
12/29 02:09, 1月前 , 28F
有逃命的選項也是可以直接逃啦
12/29 02:09, 28F
→
12/29 02:37, 1月前 , 29F
其實這不一定是用哪種tool的問題 是release flow的問題
12/29 02:37, 29F
還有 152 則推文
還有 21 段內文
→
12/31 08:11, 1月前 , 182F
突，還要不斷的改衝突，不斷的看別人改什麼，真的並沒有比
12/31 08:11, 182F
→
12/31 08:11, 1月前 , 183F
較好。
12/31 08:11, 183F
→
12/31 08:13, 1月前 , 184F
有人訂了軟體規格與流程，用不用got沒差，反正模組間的介
12/31 08:13, 184F
→
12/31 08:13, 1月前 , 185F
面規定訂好都兼容就好。
12/31 08:13, 185F
→
12/31 08:13, 1月前 , 186F
git
12/31 08:13, 186F
→
12/31 08:15, 1月前 , 187F
認同版本要控制與管理，但真的不一定用git就能解決問題。
12/31 08:15, 187F
→
12/31 08:15, 1月前 , 188F
流程比git重要太多了。
12/31 08:15, 188F
→
12/31 08:25, 1月前 , 189F
程式碼內容大家有版本差異也是，流程不改，持續用git到處
12/31 08:25, 189F
→
12/31 08:25, 1月前 , 190F
比對，根本不能解決問題。訂個流程與規格才能解決。用不用
12/31 08:25, 190F
→
12/31 08:25, 1月前 , 191F
git跟本不是問題。
12/31 08:25, 191F
→
12/31 08:26, 1月前 , 192F
git工具很好，沒否認。但流程與規格更重要
12/31 08:26, 192F
沒錯你答對了 跟上面說的一樣，flow 屬於政治問題 整個流程就是很弔詭 我們開發的跟上線的不是同一個東西 還有同個版本庫同時套用三個程式 但是三個程式卻又獨立修改！？ 再者還有奇怪的上版流程 導致工程師可以把不是線上的程式進入版本庫 不是一定要用git，我只是用它嘗試解決問題 但你好說好歹，大家都改一樣的程式可以嗎 對了忘記說 因為百家爭鳴，我才嘗試使用git diff去建pipeline 把分支有變更的差異部署進去 本身就是下下策了
→
12/31 11:03, 1月前 , 193F
提出問題，拿出解決方案，推銷你的方案，落地。
12/31 11:03, 193F
→
12/31 11:05, 1月前 , 194F
你寫的太亂了，所以沒有細看，但我猜你應該是有發現問
12/31 11:05, 194F
→
12/31 11:05, 1月前 , 195F
題，但沒辦法拿出一個適合你們公司的解決方案
12/31 11:05, 195F
適不適合不知道 但是提出討論被懟大絕 只有你要改只有你要用
推
12/31 14:09, 1月前 , 196F
我以前遇過每次上版把所有人的code覆蓋掉的臭老頭
12/31 14:09, 196F
→
12/31 14:09, 1月前 , 197F
後來他先不爽我們自己跑掉了 南無阿彌陀佛
12/31 14:09, 197F
推
01/01 00:38, 1年前 , 198F
推流程比較重要+1~雖然新人可能不太能改這個...
01/01 00:38, 198F
→
01/01 15:40, 1年前 , 199F
年青都會覺得能抗，掌權很孬，都這樣過來的，但其實能
01/01 15:40, 199F
→
01/01 15:40, 1年前 , 200F
扛什麼，能扛就不會不能做主。
01/01 15:40, 200F
→
01/01 15:51, 1年前 , 201F
準備好完整方案，持續溝通，連這種信心度爆棚的都難溝
01/01 15:51, 201F
→
01/01 15:52, 1年前 , 202F
通，之後信心度不高的怎麼溝通。離職或跟隨也選項。
01/01 15:52, 202F
→
01/01 21:30, 1年前 , 203F
你可以有情緒推動不了就換公司呀，也可以排除所有障礙
01/01 21:30, 203F
→
01/01 21:30, 1年前 , 204F
去達成，沒有哪一個比較好，但陷在情緒裡面對你自己沒
01/01 21:30, 204F
→
01/01 21:30, 1年前 , 205F
有幫助
01/01 21:30, 205F
說得好，我努力不帶情緒 逃避問題不是我的個性 但是沒辦法解決的，看來也只能換環境試試 至少我努力過 ※ 編輯: TurtleGods (114.44.237.43 臺灣), 01/01/2025 21:44:04
推
01/02 16:02, 1年前 , 206F
拜託不要再花時間腦力去把這坨大便改善了 準備履歷優先
01/02 16:02, 206F
→
01/02 16:03, 1年前 , 207F
照前輩的流程走 不要有意見 但做好不久留的心理準備
01/02 16:03, 207F
推
01/02 16:15, 1年前 , 208F
建議你，找到好方法去檢查或處理你自己認為大便的事情，
01/02 16:15, 208F
→
01/02 16:15, 1年前 , 209F
節省自己花在維護上的時間，其他人就別管了
01/02 16:15, 209F
推
01/08 18:39, 1年前 , 210F
這陀大便變成今天這樣老員工都有責任，你也別想改
01/08 18:39, 210F
→
01/08 18:39, 1年前 , 211F
變了，只會碰一鼻子灰
01/08 18:39, 211F
推
01/10 19:56, 1年前 , 212F
快逃
01/10 19:56, 212F
推
01/25 18:45, 1年前 , 213F
你這個問題看起來很多 不要想一次到位 這個要一點一點改
01/25 18:45, 213F
→
01/25 18:45, 1年前 , 214F
善
01/25 18:45, 214F
→
01/25 18:46, 1年前 , 215F
版本庫裡面不該放 exe DLL 這些 build出來的檔案
01/25 18:46, 215F
→
01/25 18:49, 1年前 , 216F
然後應該要有一個檔案 來記錄每個環境是使用哪個版本號
01/25 18:49, 216F
→
01/25 18:49, 1年前 , 217F
部署階段就去拉那一些檔案
01/25 18:49, 217F
推
01/25 18:54, 1年前 , 218F
主程式裡面應該要維護一份 每個子程式的版本號相依關係
01/25 18:54, 218F
‣ 更多 TurtleGods 的文章
文章代碼(AID): #1dS24_YI (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文：
完整討論串 (本文為第 1 之 3 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共3篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 TurtleGods 的文章
文章代碼(AID): #1dS24_YI (Soft_Job)