昨天我們聊到當時組織在管理服務的環境架構上的問題，延伸的其實也跟程式碼控管該怎麼做有關，
所以我們今天就來聊聊當時組織在程式碼控管的狀況，而團隊是怎麼處理這件事情的~

Situation

組織在程式碼控管上大致上有以下問題：

• 沒有程式碼管控流程：
  • 當時程式開發分兩種方式，一種是將需求單位的規格整理後轉給外包程式廠商開發。廠商開發完成後直接以 FTP 上傳程式到測試環境供驗收及測試。
  • 另一種內部開發的程式則是直接到測試機上進行修改，完成後請相關單位驗收。
• 沒有程式碼管控就會導致異動沒有紀錄：
  • 測試機的異動修改沒有任何紀錄，正式機則是每次更新時將原資料夾複製一份作為備份。
  • 無法明確知道每次改了哪些程式內容，只能依靠檔名更新時間和大小異動來推測哪些檔案有異動。
    而這也延伸了對於服務以及甚至於組織的影響：
• 服務:
  • 品質失控
    • 事故率高
    • 除錯、回滾困難
  • 產品迭代速度變慢:
    • 每次上線都手工比對與複製
    • 交付週期長
    • 團隊疲於救火
  • 資安破口
    • 被植入惡意碼風險無法控管
    • 無法確保是否無資料外洩風險
  • 可擴展性差
    • 難以整合/重構
    • 服務羅架構越做越破碎
    • 技術債雪球
• 組織：
  • 用戶體驗受損
    • 降低用戶對組織的信任
  • 法遵與稽核
    • 面對稽核、董事會、甚至監理單位都無法提供佐證
    • 面臨相關的裁罰
  • 成本失控
    • 人力被綁死在重複工作、外包費與機會成本上升
  • 人才風險
    • 離職就斷層
    • 難以讓新人上手

Task

綜觀以上風險，團隊針對程式碼控管有以下的任務：

• 確保所有的程式都必須要進版控
• 確保所有的異動都必須有記錄
• 制定分支策略
• 提升人員對於程式碼控管的能力

Action

• 所有計畫的起手式都是盤點，因此要建立標準開發流程第一件事也是要先盤點目前的程式碼。
• 開始之前還必須要先進行教育訓練，因為大家還不知道怎麼使用 git ，不過這是另外一段故事了
• 導入git，要求大家把所有正式機的程式都 commit 進去。之所以選擇正式機程式，是因為這是在線上對外服務的版本，因此我們以正式機的版本作為我們的“真理之源” (source of truth)。
• 當然在
• 接下來便是要求所有的程式異動都必須需要進版控。當然在一開始的時候比較困難，因為還沒有機制能強制避免沒有進版控的程式推到正式機。等到整個 release pipeline 都建立完成後這件事就自然而然發生了。
• 當所有程式異動都進版控了，接下來可以繼續串接程式庫和工單系統，所有需求相關異動、部署狀態都可以直接在工單中看到。

Result

• 所有的程式都在 git 之中，隨著每一次的需求異動也都可以看到對應的 diff。
• 程式庫與工單系統整合，所有程式異動都能夠清楚知道當初的需求背景。
• 所有的異動都包含完整的背景資訊，追查線上問題的時候更容易找到可能出錯的異動
• 每一次的異動都有個別 PR 紀錄，修正橫跨多個 commit 的程式時能協助確認異動範圍，減少非預期錯誤的風險。

有了程式碼的控管後，明天我們會聊聊程式碼怎麼整合~