從最早的 CMMI 到現在的啥 ISO 或是 soc2 ... audit 系列都有個目標，做什麼事都要有記錄，並有人審核

我以前一直都被誤導為要另外開系統，但看到我們公司的作法感覺合理（入內）

戳人處理機器需要額外 ticket 或 email 記錄，不能口頭或私下指導，這規則很常見

但我們家用了大量的 bot 來完成這事，類似 chatops 大家在 slack 上面去按讚（committer approve）按船（repo / project owner approve & trigger），bot 就自動 trigger deploy 中間完全不用人介入

當然起點會是 PR，PR 有人 review 後 merge，剛剛戳 bot 的動作是所有人 confirm & approve，所有事情都有人重新審核畫押過，完全符合 audit 精神

好奇這麼多的紀錄要怎麼comfirm 比較好呢/

之前某個系統需要更新設定值，某些 manager 才有權限

目前也都改成了 gitops，能在 PR 內下特殊的 comment（在 PR 內留特殊的留言）機器人會搜尋整個 org 的 code，如果沒有or有 client 使用這個 config 才允許被移除or新增

merge 後就會自動去該系統設定，這樣就不用過任何人的手，不怕肥手指那樣

永遠的真田幸村 : 每次 deploy 會有上次和這次的 diff commit 所以 chatbot 只需要列這次還沒被 committer approve 的"人名"，叫他要去按讚=一次approve多個 commit 即可

所以我們家 deploy bot 的 slack channel 是最忙的地方

機器人每天固定早上九點，會掃所有 repo 看哪些已經 build prod image，和上次 diff 了多少 commit，這些 commit 有沒有 committer approve(with bot)，沒有的話就 tag 對方，並把 stop 的 deploy pipline 列在那邊，這樣 committer 就能進去看這次 deploy 有多少 commit 是自己的

所有人都有按過讚後，機器人會回説可以按船 deploy 了，則 owner 按個船就上了

anyway 詳細應該更複雜些，不過 ...... 我想表達的是

寫個機器人應該比寫個系統簡單，且更讓人容易接受的

而 audit 需要看 log 就給他們看你們整個流程，沒人需要登入另外一個系統，使用 slack 或 github PR comment log 就能證明所有的事情，符合 audit 所有的流程

當然 audit 真的太 87 也能直接整理出報表的，開發者只需要會 slack & github 就能完成所有動作，不用登入額外的系統，大家都開心

在想假設我們只有三個人，這個流程要怎樣設計 一個開發一個上版一個審核

永遠的真田幸村 : 你的人數太少了，我喜歡 x 100 以上

假設你們公司有 1000 個開發者，每個開發者能任意開發任何 repo

每個 repo 有 3 個 reviewer / owner 則 merge PR 後能直接 trigger deploy to stag 然後大家都能進行測試了

隔天早上 9 點，deploy bot 開始列 prod image 與 stag image 的 commit diff，然後 group by email 然後開始 tag committer，committer 按讚後等於一次 approve 他自己在這組 diff 內的所有 commits

deploy bot 在有人按讚後，trigger 檢查是否所有 commits 都被 approve 了，如果是，新增留言説可以按船來 deploy

然後 repo owner 按了船後，bot 就去 trigger prod deploy

這類的內部系統我們家做得很多就是了，沒有的就自己寫，大家都開心，我們有一個 team 專門服務工程師的那樣

剛剛按讚的範例還能按 recycle 來放棄這次 deploy 防止別人誤 deploy，當然 ops 也能下特殊指令強迫 trigger deploy，類似有點急，但同事在別的 timezone 那樣