#疫情下當業務量減少的決策差異
去年疫情當業務量出現真空期的時候,我輔導的客戶,以及能接觸到其他的公司朋友,大家的決策出現了很顯著的差異。
我覺得最成功的一例,就是趁著疫情所有客戶往來都被迫暫停時,一條線開始 migrate 過去總是沒空翻新的核心 legacy 模組(順帶針對最核心常見的業務情境建立自動化測試)。
另一條線則是針對新舊模組 A/B testing 的相關設計(如何切換 toggle 與決定分配比例)跟基礎建設(例如如何加強 log, exception 控管分析與通知)。
第三條線則是把 build server 到部署這一段做得更加順暢,尤其是快速 hotfix 與 rollback 的機制,同時有些團隊開始實驗把 git flow 分支策略改成 trunk-base 的機制,提早撞牆那樣的 conflict 頻率。
一樣的疫情,一樣的業績低點,他們卻趁機讓多出來的時間空間與團隊能量,投資在未來的競爭優勢。
這是我很佩服他們領導者的遠見跟決策能力,不會因為業務量變少而直接走無薪假、辭退多餘人力,等有業務量才再走招募的老派路線。
現在他們已經在享受去年疫情的基礎建設投資的好處了。
圖片來源:Thanks to Jared Murray @jaredmurray for making this photo available freely on Unsplash 🎁 https://unsplash.com/photos/NSuufgf-BME
「git conflict」的推薦目錄:
- 關於git conflict 在 91 敏捷開發之路 Facebook 的最佳貼文
- 關於git conflict 在 91 敏捷開發之路 Facebook 的最讚貼文
- 關於git conflict 在 Git: 更新分支+解衝突 - Summer。桑莫。夏天 的評價
- 關於git conflict 在 Resolving a merge conflict using the command line - GitHub ... 的評價
- 關於git conflict 在 How to resolve merge conflicts in a Git repository? - Stack ... 的評價
- 關於git conflict 在 How to Resolve GitHub Merge Conflicts | Cloudbees Blog 的評價
- 關於git conflict 在 GitHub 及EGit ( PART 6 / 8 ) + Git Conflict - 放棄思考 的評價
- 關於git conflict 在 How do I resolve merge conflicts in git/GitHub/GitLab? 的評價
- 關於git conflict 在 Tutorial Git and GitHub - Merge conflicts with simple example 的評價
- 關於git conflict 在 Merge conflicts on GitHub, not locally? 的評價
git conflict 在 91 敏捷開發之路 Facebook 的最讚貼文
看吧,每人每天至少 merge 回主幹一次,基於主幹的開發 搭配 feature toggle,才能比較容易達到真實的 CI, CD 的精神。
CI 本質是「持續整合」,不是 build server。
CD 是「持續佈署」,不是自動化佈署。
TDD 也不是自動化測試,是測試輔助開發,用測試來描述情境,確保每一行程式碼都是剛好的為某些情境而存在,沒有多餘,重構沒有負擔,顆粒度小的單元測試能完整且扎實。(你們確定你們團隊有能力在實務上有效、有用地使用TDD來獲得好處嗎?)
紅燈除錯時間降到最低,上版後要 hotfix 也可以直接關掉 toggle 再找到問題的原因,快速地 merge 回主幹,直接推到 production 再開 toggle。
如果走 feature branch,那你們產品是多久才 merge 回主幹一次?一天多次?如果是,那你會覺得連開 feature branch 本身都是個多餘、不必要的 effort。
一切都是基本功,不要只被絢麗的工具、解決方案給迷惑了。
#給了你鑿子也不會因此變成米開朗基羅
--
每次在上課或是在輔導的客戶那邊聊到,Odd-e 幾乎所有人一般都是不走/不建議 用 git flow 之類的 feature branch,工程師們總是十分吃驚。你們不拆 feature branch? 那你們怎麼做的?
feature branch 的主要目的就是為了避免 conflict 造成的成本,然後透過 delay merge 來降低這一段成本(事實上降低的是頻率,而不是成本),因此而付出「延遲整合」的代價。
其實如果退回來敏捷出來之前的瀑布式或傳統的開發方式,大部份都是 component team 或是專業分工團隊,依據大家的專業去內聚成一個 team, 看起來貌似 efficiency 提高,其實是在增加整合的困難,失去全局概念,增加依賴的不穩定性,甚至「避免」溝通。
如果你看過前端一個 team, 後端一個 team 在做一個產品,他們只透過 API spec 跟 文字在溝通如何界接,最終都會導致許多無形的浪費。(怪了,我們這樣分的原始目標還是為了避免浪費)
一個需求需要兩個 team 跨 team 合作的配合,才能正常且順利 deliver,分頭開發就是導致延遲整合,如果再用類似 sprint 的 iteration,一個 sprint 的結束之前才來做整合,當時間已經用盡,但整合出現問題時,就會開始出現責任歸屬問題。
例如前端改也可以,後端改也可以,那麼誰要改?沒時間了啊...後面的工作跟時程都安排好了。
其實,本質問題都是一樣的。
總是碰到客戶那邊用了華麗的 build server 之後,再套上潮流的 git-flow, github-flow,再搭配上一個產品超過 3 個團隊在同個 product code-based 上工作,不同專案不同時間點要上線,再加上從 local/dev 到 prod 至少有三個環境。
結論就是光一個佈署、merge、上版、退版、pull、解 conflict,他們就身在其中痛苦不已。越痛苦,就希望痛苦的頻率降低,做一次痛總比老是痛來得好。
所以,誰晚 merge 誰倒楣。
--
當然啦,feature toggle 也不是萬靈丹,他會帶來 application 複雜度的挑戰,而 application 的複雜度控制,其實卻反而是最簡單的,因為只要設計的底子夠足,這一段可以設計地很美、很無感、很無痛,而且開發維護成本低廉,品質良好。
git conflict 在 Resolving a merge conflict using the command line - GitHub ... 的推薦與評價
Competing line change merge conflicts · Open TerminalTerminalGit Bash. · Navigate into the local Git repository that has the merge conflict. · Generate a list of ... ... <看更多>
git conflict 在 How to resolve merge conflicts in a Git repository? - Stack ... 的推薦與評價
... <看更多>
git conflict 在 Git: 更新分支+解衝突 - Summer。桑莫。夏天 的推薦與評價
git push origin master To github.com:cythilya/git_test.git ! ... Auto-merging hello_world.html CONFLICT (content): Merge conflict in ... ... <看更多>