Re: [請益] Firmware 做CICD是可行的嗎?

其實大一點的案子每天都有人進扣

要每次進扣前都做完測試全pass才進也不是不行，只是會很慢

我分享一下我的經驗，講不對的地方望各位指正

打個比方好了，我之前做的案子有三個組分在不同時區，一組五到六人。五到六人算是極限了，不然code review會拖垮全部人。三個組加起來一天平均大概15條新增的PR

進code後jenkins會開始build,完成後自動跑unit test和GUI test, 全部完成要兩小時。GUI test必須用正常人的速度模擬不可能一下子就測完。每次進扣都要做test這樣一天有15個PR那server會跑不完

當然你說加server也可以，但公司還有其他幾十個案子不可能把server全部給你

於是就變成進扣時只跑最重要的test。等到下班後沒人進code再把今天整進來的PR全部一起跑全部測試，沒過的測試再發報告出來明天再改。

大概是這樣

引述《Lotto (技術全面)》之銘言：
: 打欸賀! 是這樣的小弟公司是做wifi SOC，
: 窩們家老闆打算在開發導入CICD 來加速開發&提高Quality，
: 也正在找相關人才, 然後聽他說客運公司那邊開發藍芽，
: 可以做到submmit 後一小時就有測試結果，
: 這到底是唬爛還是真的有可能做到的??
: ※ 編輯: Lotto (101.11.32.190 臺灣), 10/16/2020 17:00:45
: 推 younge: moxa和發哥好像都有在導cicd 10/16 17:20: → wellkom: 有錢要怎樣都行啊。怕的是老闆沒錢又什麼都想要 10/16 17:32: 推 susumiya: 怎麼覺得前幾天 好像看過這篇 10/16 18:09: 推 sb5471: 做 wifi soc...南方硅谷? 10/16 18:24: 推 ARSENE2007: 瑞昱吧 網路上都寫了 10/16 18:37: 推 yamakazi: 有心都做得到，以前某大廠是各組排值日生把daily build 10/16 18:56: → yamakazi: 燒進手機裡然後拿去實驗室接CMW500跑測項。再把結果發em 10/16 18:56: → yamakazi: ail。但其實都可以自動化不用排值日生 10/16 18:56: 推 longlyeagle: iot greengrass 10/16 19:05: 推 shortoneal: 工具都有，看你能不能砸資源搞 10/16 19:20: → james732: 可行但不要為了做而做，譬如FW要怎麼測試就很麻煩 10/16 19:29: 推 kingofsdtw: 有的不能吧？fw開機會把console切去用 10/16 20:30: 推 sunsamy: CICD是不會測試的人發明出來的,相信的公司輕者獲利降低, 10/16 20:59: → sunsamy: loading增加,重者公司倒掉 10/16 21:00: → jeff40108: 薪水只請的起高職生，只好搞cicd 感覺好像有在做測試這 10/16 21:14: → jeff40108: 樣 10/16 21:14: 推 blackrays: 台商就別鬧了 10/16 21:18: 推 pponywong: firmware做CI很容易 10/16 21:30: → pponywong: 在上到系統就難了 10/16 21:31: 推 jack7923love: 測試真的難 10/16 21:38: → yuming123: 笑死 什麼叫cicd是不懂測試人推的，是你不懂cicd吧！ 10/16 22:33: 推 markbex: 正是因為有CICD，反而能讓測試的質與量提升 10/16 22:54: 推 easyman: 這不難吧,古早一點就jenkins, 新一點就gitlab 10/16 23:20: → easyman: 撈到check in就 build, 燒code, 抓一下誰check in 10/16 23:21: → easyman: 然後總有一些cmd去scan connect , 傳data 10/16 23:23: → easyman: 有問題就發bug , 測個基本的而已啦 10/16 23:23: 噓 final01: 講幾次幹嘛不行阿 10/16 23:51: 推 exeex: 可呀 發哥手機韌體有CICD 但要做的好我覺得滿不簡單的 10/17 00:06: 推 exeex: CICD的文化要花時間滿滿建立 10/17 00:09: → exeex: 慢慢 10/17 00:09: → exeex: 要讓整個公司的人習慣用CICD系統可不是一件簡單的事 需要 10/17 00:17: → exeex: 有經驗的人一個一個盯 10/17 00:17: → exeex: 先扛得住各部門的靠背聲浪再說 ㄎㄎ 10/17 00:18: → exeex: 挺不過中間生產效率降低的陣痛期會得不償失 10/17 00:20: 推 pkh1234: 完全可行 目前perchange後就會測code地方的測項 team內部 10/17 00:34: → pkh1234: 有rdqa 公司也有dqa部門 10/17 00:34: 推 Busufu: 我覺得難的是初期導入跟習慣培養 10/17 00:36: → MediaTekInc: 發哥有 10/17 00:53: 推 bery: 看情況 如果導入也只能自動檢測原本人為build能自行簡測的 10/17 07:29: → bery: 部分 那就是浪費成本沒效益了 10/17 07:29: 推 NSYSUEE: 有做程式開發都一定要做CICD啦，很難想像現在還有軟體開 10/17 09:09: → NSYSUEE: 發的團隊沒做這件事，如果沒做，這間軟體公司也快倒了， 10/17 09:09: → NSYSUEE: 不用待了，CICD這個文化是開發團隊一定要建立的，firmwar 10/17 09:09: → NSYSUEE: e一定可以做，就看有沒有心 10/17 09:09: 推 NSYSUEE: 除非你是接case的公司，結案後整個軟體開發流程就結束了 10/17 09:19: → NSYSUEE: ，這樣就不太需要做 10/17 09:19: 推 NSYSUEE: 但如果是一直有軟體開發需求，常常要更新版本，就更應該 10/17 09:23: → NSYSUEE: 要做 10/17 09:23: 推 wulouise: 有，只是你要連上硬體的部分一起自動化才有效益 10/17 10:46: 推 bnd0327: 可行吧，網路上查一下關鍵字 10/17 12:38: 推 sunsamy: 真正懂測試的check in後就PASS了,不懂的才會一直在CICD 10/17 19:32: → sunsamy: 傻B一堆 10/17 19:32: → sunsamy: CICD=continue integrated continue develop,代表一直不 10/17 19:34: → sunsamy: 知道bug在那或找不出bug才會一直在那"continue"，蝦忙 10/17 19:35: 推 NSYSUEE: 看來樓上不懂CICD，CICD也要求要做自動測試，在持續整合 10/17 23:30: → NSYSUEE: 的過程，如果程式有問題，就會在自動測試的時候就該被抓 10/17 23:30: → NSYSUEE: 到，怎可能不知道bug在哪...不知道bug在哪代表你的測試 10/17 23:30: → NSYSUEE: 項目沒寫好，要持續改進... 10/17 23:30: 推 sunsamy: CICD是chick in後才測試能否PASS,這不是傻B的行為嗎? 10/17 23:55: → sunsamy: 懂測試的人都知道要確定會PASS才chick in 10/17 23:56: → sunsamy: 這幾年來一堆歪理邪說一直出現,什麼敏捷,CICD... 10/17 23:56: → sunsamy: 都是在騙一些沒腦的傻B,多半沒什麼鳥用 10/17 23:56: 推 popcool: 原來世界上有做CICD的軟體巨頭都是傻逼，我大台廠工程師 10/18 01:35: → popcool: 想的才是真理 10/18 01:35: 推 NSYSUEE: 什麼叫做懂測試的人？好啦..你很懂測試，但是你旁邊的工 10/18 03:52: → NSYSUEE: 程師會很懂測試嗎？你確定整個團隊的人都懂測試嗎？你們 10/18 03:52: → NSYSUEE: 全部的code整合在一起不會有災難？我告訴你，某一天一定 10/18 03:52: → NSYSUEE: 會發生可怕的大災難 10/18 03:52: 推 NSYSUEE: 團隊成員每天都在改版上傳新的程式，CICD在持續整合的過 10/18 04:07: → NSYSUEE: 程，就會做自動建置、自動測試的工作，如果團隊成員有一 10/18 04:07: → NSYSUEE: 個人出包，就會馬上抓到有錯，馬上通知成員修改，交付出 10/18 04:07: → NSYSUEE: 去的程式品質絕對比你那種只有一個人懂測試的還要好 10/18 04:07: 推 NSYSUEE: 還有CICD強調的是軟體開發的過程，從需求一直到交付、部 10/18 04:12: → NSYSUEE: 屬能夠自動化，你的團隊每一個人都要建置、測試，如果有 10/18 04:12: → NSYSUEE: 做CICD就可以省掉團隊非常多的時間... 10/18 04:12: → sc1: 拿原碼過來改比導入啥CICD做SOC Wifi快 10/18 07:27: 推 sunsamy: NSYSUUEE的team或公司果然是傻B,弄這種,讓每人整天在蝦忙 10/18 08:08: 推 sunsamy: 這種team的特點是:bug是越修越多,然後越是強調要注重品質 10/18 08:13: → sunsamy: 說中了,請在心中自已默默承認自已的team或公司是傻B就好 10/18 08:14: 推 sunsamy: 傻B的現象:怎麼bug還是那麼多,一定是CICD不夠撤底 10/18 08:23: → sunsamy: 加大力度CICD,結果bug更多了,傻B會想:更加大力度CICD 10/18 08:23: → sunsamy: 結果bug更多了,傻B心理想:真不敢想像那些沒做CICD的公司 10/18 08:24: → sunsamy: 怎麼活下來,幸好我們一直加大力度CICD 10/18 08:25: 推 NSYSUEE: bug會越來越多是沒做CICD的團隊才會遇到，有做CICD的團 10/18 09:55: → NSYSUEE: 隊在交付和部屬程式的時候都會比沒做的安心更多更多 10/18 09:55: 推 NSYSUEE: 還有沒做CICD的團隊才是每天瞎忙吧，沒做CICD的團隊每天 10/18 10:00: → NSYSUEE: 一堆工程師在那邊瞎忙建置專案、測試專案，有做的根本不 10/18 10:00: → NSYSUEE: 用在乎這些，CI就會幫團隊的所有專案自動建置、測試，有 10/18 10:00: → NSYSUEE: 問題就會自動通知，省下來的時間可以做更多事，沒做CICD 10/18 10:00: → NSYSUEE: 的才會瞎忙... 10/18 10:00: 推 NSYSUEE: 然後就說了CICD是軟體開發流程，從需求、開發、建置、測 10/18 10:07: → NSYSUEE: 試、...交付到部屬的過程，除了寫code外，其他項目能夠 10/18 10:07: → NSYSUEE: 自動化，目的也是要節省開發人員的時間，說瞎忙的肯定沒 10/18 10:08: → NSYSUEE: 做CICD，甚至不懂CICD 10/18 10:08: 推 sunsamy: 所以我就說囉:傻B們會心理想:真不敢想像那些沒做CICD的 10/18 11:31: → sunsamy: 公司怎麼活下來,幸好我們一直加大力度CICD。的確是這樣 10/18 11:32: 推 NSYSUEE: 世界上的軟體巨擘公司Google、apple、amazon、microsoft 10/18 13:54: → NSYSUEE: 都是傻逼，原來這個是沒做CICD不懂CICD的人做的結論 10/18 13:54: 推 MaryWorkHard: 我還以為有點規模的公司都有在做 不做不會被客戶靠 10/18 15:25: → MaryWorkHard: 北產品穩定度問題嗎 10/18 15:25: 推 sunsamy: 但你會發現做了更會靠北,因為客戶也是傻B沒發現CICD本身 10/18 16:28: → sunsamy: 就有問題 10/18 16:28: 推 NSYSUEE: CICD如果有問題，早就會被全世界的軟體公司丟棄了，不會 10/18 18:14: → NSYSUEE: 輪到一個小咖在那邊說嘴CICD有問題，如果沒用的話，國內 10/18 18:14: → NSYSUEE: 外軟體公司就不會去推動了 10/18 18:14: 推 vivijacky: 感覺有人只懂名詞解釋,連bug就是來自於submit也不懂 10/18 18:23: 推 sunsamy: 傻B的特點是自已不會獨立思考,只依據大家都用,所以沒問題 10/18 20:08: 推 sunsamy: 來做結論 10/18 20:10: 推 NSYSUEE: 傻B的特點就是自己也沒有一套機制，然後只會批評廣泛運 10/18 22:45: → NSYSUEE: 用在業界的機制有問題，不懂還硬要批評就是傻B的特點 10/18 22:45: 推 shietsd: 待過的外商都會做 10/19 01:01: 推 gugeegee: CICD連100多人的軟體公司都導入了，大公司不導入是傻B嗎 10/19 10:52: 推 pacers: 某s做的案子太小就不要再丟人了 10/19 11:53: 推 lpoijk: 當然可以 只有願不願意 10/20 08:37: 推 lpoijk: 說沒用的是沒出社會嗎？開學了 快去上課 10/20 08:39
-----
Sent from JPTT on my iPhone

--