一、版本控制介紹

1. Day 2 : 應用程式的版本控制與自動化部屬流程
2. Day 3 : 資料庫版控的原理與方法
   -> 3. Day 4 : 資料庫的版本控制與自動化部屬流程

在上一篇我們知道了，資料庫內的結構會需要與程式內有所對應，不然會發生程式讀取錯誤的問題，因此我們會需要對資料庫做版本的對應，我們也知道了會有三種方案來進行，因此本篇的內容會著重在這三種方法所需要的人力配合與自動戶方案

1. 提交 SQL 語法給 DBA
   這其實是我較常在公司內看到的方案，原因在於這種方式不需要引入其他的工具且單純，具體的方式會在程式內放置一個 SQL_INIT 的資料夾，或為了不希望 DBA 看到程式碼而會獨立開一個 SQL_PRJ 之類專門拿來存放的變更語法的專案，而由 RD 將還原與建立表的語法接透過這專案發 MR 給 DBA 做語法審核與討論

完成之後開 release 分支透過 Jenkins 先進行備份再跑 SQL 部署腳本執行，當錯誤時做還原，而部分大量欄位變更且需要保持上線的情景透過 pt-online-schema-change 來做批次變更保持上線

這方法其實我覺得挺好，但很常會有 RD 漏提交語法或是 DBA 沒有上到，導致程式出錯而需要另外進行完整的 QAT 來找到這樣的問題，我認為還是有點缺憾

2. 由 RD 在 Dev 環境建立資料表與 SP，由 DBA 通過 SQL 比對工具產生語法
   很多工具能對不同的資料庫進行結構比對，並產生升級與還原的語法，在大部分的情況下表現得很好，部分大量欄位變更且需要保持上線的情景依然透過 pt-online-schema-change 來處理，然後產生的語法由 DBA 找功能開發的 RD 討論後就跟 1. 一樣走上版流程

3. 由框架的 Orm 工具直接進行遷移
   這會需要依賴語言 Orm 的實現，可以針對 Dao 來生成語法，並可在每次隨著程式更新時執行該遷移程式，這是最能確保程式與 AP 端ㄧ至的方案，但壞處在於中間不會產生 SQL 語法供 DBA 審閱，大部分是產生該語言的操作語法，不一定方便 DBA 做審核，而依賴 RD 與 DBA 間的溝通與在 Dev 上觀察目前 Schema 的欄位與效能狀態，大量欄位變更依舊建議使用 pt-online-schema-change 這類的工具，而將程式略過這次遷移會更好

後續預告

這是版本控制篇章的第三天，明日將會進入 二、資料庫版本控制的語法，介紹 Orm 與 SQL 這兩個描述資料庫結構的方式