在許久許久之前，有位異常懶惰的工程師，正躺絕對不坐，能做絕對不站。如果能夠自動化的事情我就絕對不會親自動手，所以凡舉布版打包一類的瑣事，這位工程師通通交由腳本去執行。但事情往往不會這麼順利
在他的服務單位有一個傳統，正式機需由後端或維運來佈版，至於背後的原因，那可能又是另外一則鬼故事了。
測試機在沒人管的前提下，當然由這位工程師說了算，直接從github actions ci走腳本一路打包布版版到機器，全程無尿點，舒服！至於正式機......總之我秉持你愛怎樣我配合的想法，工程師就寫了個腳本打包，然後傳壓縮檔給後端讓他們自己去發揮。多日來倒也算相安無事，但鬼故事總是發生得措手不及那才叫做鬼故事啊！
這專案再一次大更版後，正式環境出現了不明原因的錯誤，且多日debug無果，老闆開始檢討起開發流程，覺得在測試與正式間，應該再多一個uat環境。這想法原則上沒問題，問題在後面。老闆覺得換皮站應該每個皮的系統是獨立的，防止換Ｂ皮結果Ａ皮壞掉.....從技術面向來看，這位工程師已經不知道要從何吐槽起了。總之還是那句，你愛怎樣怎樣。
老闆最終再提一個想法，應該要加快布版速度，防止用戶有不良體驗。
看到這裡大家應該覺得，那不就測試機的佈版腳本，就改一下環境變數直接上到正式機就好。工程師原本也是這樣想。但很可惜關於佈版前端工程師並沒有話語權。接下來主管一系列指令更是殺得工程師手足無措
關於快速佈版，主管提出使用cicd。這乍看下沒有問題，問題在工程師以為他也是github actions腳本寫一寫佈版，大錯特錯！他把佈版腳本寫進寶塔裡面，使用人工點擊腳本佈版
然後關於uat，工程師原本以為他會叫工程師開一個uat分支，多一個環境變數檔，當uat push時觸發佈版。結果完全不是我想得這麼回事！每當程式要上uat，會叫工程師把開發分支merge回master。（先別噓），然後他再點“按鈕”進行uat佈版，等測試完成後再點按鈕上正式。
哎.......就請問如果uat測試沒過，要改東西，這時有hotfix趕著上版怎麼辦！算了～只是一個小小前端工程師～如果能保一切順利老闆開心，這位工程師願意陪你們演猴戲，但好巧不巧事情就這麼發生了......
因為這套系統在打所有api前，會先讀取本地ip.txt，把裡面的網址進行解析測試，看哪個通就走哪個，但當初也不知道怎麼規劃的ip.txt放在根目錄，有開發過vue vite的小夥伴一定知道如果打包完要在根目錄，那檔案開發時要放在/public裡面，但事實是，ip.txt不歸前端管，是歸維運管，所以不應該放到前端專案中，等於打包時不應該打包到ip.txt這隻檔案，但最終打包出來卻要有這個檔案。
這聽起來很饒口，但實際上就是這樣。那應該怎麼做到呢？很簡單，測試機腳本是先下指令清光ip.txt以外的所有檔案，再把壓縮包直接壓進來，這樣就可以ip.txt不會被覆蓋及刪除。
當然主管也不笨，他在package.json中使用指令，在打包完把指令路徑的ip.txt複製到指定目錄。這樣原本上也沒什麼問題，但問題出在寶塔，例如yarn build && cp ../ip.txt ./dist/，這樣理論上會先打包在複製檔案，但不知道為什麼如果是按按鈕下指令，最終會看不到ip.txt這隻檔案，或許是寶塔優化了腳本變成多執行序執行？？導致一開始就複製進去，在build完後一並被刪除，不知道，這位工程師並不想了解。總之在改成這樣上版後，正式機癱瘓了，原因是找不到ip.txt。死活也找不到為什麼，最終只好一遍又一遍人工把ip.txt複製進去，可喜可賀......個頭啊！所以當初導入cicid的意義在哪，還是要人工啊！
後記
過程中工程師無論明著說，暗著說，告訴他們已經有寫好腳本。然後把專案管理權全數交數去，主管明明就可以看著腳本知道過程中到底都發生些什麼事，卻一行都不看，偏偏選用這麼....不自動的方式去打包，唉～槽點滿滿。真的搞不清楚主管到底是強還是弱了～
最終這位工程師將何去何從，下場又是如何，請靜待下回分曉
3/21鬼故事更新
果然就在發文兩天後就生了塞車，事後工程師主動請纓才讓事件有了完美的帷幕，至於日後還會發生怎樣有趣的事呢，讓我們拭目以待
沒有留言:
張貼留言