Re: [請益] 請問大家是怎麼做依賴管理的呢？

看板Soft_Job作者qrtt1 (有些事，有時候。。。)時間12年前 (2014/02/02 21:48)推噓5(5推 0噓 4→)

留言9則, 8人參與討論串7/12 (看更多)

過年期間剛好比較閒，又重看了這一串討論。看來它已經不只單純的「相依管理」問題了，而是工作流程的改善。要改變現有團隊的工作流程，毫無疑問是個大問題，多數只有具有管理權限的人才有權決定工作流程的變更。不過，這不表示你得對目前的窘境繼續抱持著無奈、累積憂鬱。在現在的公司待了三年多，剛進來公司的版本控制系統用的是 CVS，現在是用 git。剛進來公司的函式庫管理是將 JARs 丟進版控內，現在我管理的專案是用 gradle。這些改變是漸進的，把它單純當故事聽就好，因為被稱為『經驗』的閒聊，通常不適用太多人。 CVS 在我眼中跟前一份工作用的 svn 的差別蠻大的。有幾個麻煩的地方像是 commit 的檔案有分文字檔處理的與非文字檔處理的，還有 commit 動作不具有交易性質，它可以部分成功。由於不是一個交易，它就不會有一個 commit 能對應到一個 revision。簡單的應付辦法就是將檔案一律以非文字檔處理，使用 tag 標示版本號，代替沒有 revision 的問題。但是 tag 是手工上的，這有時忘了上就比較麻煩，或是覺得改變太少想在下一個 release 再上，然後許多小改變持續堆積 ... 最初的工作是實作 library 給其他同事使用，不過某回 release apk 之後，災難隨之而來。程式不斷地 crash，而且我還不知道同事用了哪一個版本。在不一定有 tag 的情況下，要同時由出 app 跟 lib 間的組合實在很麻煩。即使不知道哪個版本，至少能先退回已知不會有問題舊的版本。那一回大爆炸之後，我開始計劃要逃離 CVS，好家在是公司內不太限制我們把程式碼放在什麼地方，只要它不是公開的就行了，至少我知道主管的態度是開放的。（雖然，最後在全公司換上 git 是不是要使用 github 時又正式跟老闆討論了幾回）選擇使用 git 只是剛好符合我的需求，除了先提到的「不習慣」之處。再來就是網路傳輸真的很費時間，我的辦公室在台北，但我們部門總部在新竹。 CVS 伺服器就架在新竹，我需要透過 ssh tunnel 來跟它連線。加上剛進公司 credit 還不夠多，也沒有權在 server 上多架個 svn，在那個當下會使用的 git 或 mercurial 這類 DVCS 的工具就會是較好的選項。（至於為何選 git 是因為太多情況會改變歷史、建立 branch，對我個人來說是比較順手的。）租了一個 github 最小的空間，就放那個唯一的 library project。（bitbucket 那時還沒有 git repo 支援，不想架 private server 就租 github 唄）自己規劃了 release 流程與寫好了 script，連同 commit id 一同編進最後的 .so 內，只要有 strings 工具就能找到 .so 內寫的 commit id 精確對上 git commit 這並不是要 git 才能做得到，只是在『工作流程』改善的過程中使用到 git 罷了。經過 release 流程的重新規劃，我能有效率地找出需要重現問題的 release 試著依同事記錄的操作方式，試著反覆弄掛它，觀察問題在哪裡。真正使用到 DVCS 優點的情況是：不知道哪一種方式比較好，都實作看看吧。就像打電動在下一個階段前先存個檔，每一個路徑都試著走看看。一個路徑一個 branch，每一個嚐試可以知道哪些有潛力，哪些不可行不用再浪費時間，把 branch 砍一砍，把開發的心力專心投入在能佔優勢的 branch 上。同事開始注意到我使用 git 配合管理 release 流程的方式，管理產出成品與原始碼精準地對應，能較快速地確認 release 與 reproduce。（其實中間還歷經用 git 輔助 CVS 找出有問題的版本，將 CVS 轉成 git，再簡單地用二分法縮小問題版本）在幾個『良好案例』的證見之下，公司開始有空間討論是不是要轉移至新世代的版本控制系統。當時的討論是以 DVCS 為主的工具，主要是 git 與 mercurial。 mercurial 的用法相對於 git 是較簡單的， git 一般的認知是比 mercurial 難（雖然我不這麼覺得）。對討論的過程的記憶不多，就不多加以著墨（請各自的粉絲另開一篇討論唄！？） git 能出線主要是公司內已經有實際使用的案例（即使非正式證可）並且成果看起來不差（我一直在對 RD 人蔘中的金手指 git 做宣傳）最後，我們選用的是 git，前年同事做了一場正式的教育訓練正式宣告公司的版本控制系統進入 git 的時代。從這故事看到了什麼『亮點』嗎？即使我沒有管理權限，但還是有能控制到的範圍，因為我們不是生線產生上的作業員，工作方法不會有 SOP。多數的時候能自己在上司不反對的情況下，決定許多事情。在足夠的活動空間之內，建立了自己的『理想國』，讓別人羨慕你的國度，成為別人想仿效的對象。要改變公司的一些事物，對沒有實質管理權的人，並不那麼難。對有實質管理權的人，並不是那麼簡單。對沒有管理權的人，至少要能掌握改變會帶來哪些優勢，並要事先將有問題的雷都踩一踩，提出一個符合團隊實質能運作的模式。你得有成功案例才能拿出來推銷，並且要明顯獲得好處。對有實質管理權的人，難處在即使知道其他團隊做得那麼好。在自己團隊是否推得起來是個疑問，至少需要有一些『種子』，讓新的想法在團隊內發芽，漸漸把新的想法散播出去。二個方向的人馬，要面對的不外乎解除疑慮、化解阻力。並且能預見比過去更好的開發生活，但別忘了改變一開始都會經過混亂。那個有經驗的人，就得去處理這些混亂。導入 gradle 是我下一個目標，至少我現在控制的專案都是 gradle 管理相依性的，只要我啟動專案專案越多，公司內 gradle 的專案就會越多。配合 DevOps 概念寫好的 deploy 系統，發佈新 library 相關專案重新 refresh dependency 再 deploy 出去，下一輪的運算就會自動生效，這也是一種良好案例的累積（推銷、宣傳）用實績來解除同事的疑慮吧。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 36.231.145.54

推

lovdkkkk

02/02 23:25, , 1^F

02/02 23:25, 1^F

推

hahach

02/02 23:56, , 2^F

02/02 23:56, 2^F

推

diabloevagto

02/03 00:01, , 3^F

02/03 00:01, 3^F