多層式架構的更新

DELPHI的最大討論區(就筆者的感覺)，應該就是K TOP了，近日看了一篇文章  面對快速持續改善的多層架構系統要如何規劃版本更新架構呢？  覺得很有趣，於是就做了一些回應，想不到一些淺見還得到大家的討論，所以說明一下本人的程式更新方式。還請大家多多指教。

首先，我們會把程式做一些分類，然後做一些存放程式位置的規定。

接下來，會有一個共同的檔案管理區，這個區域存放大家寫的程式，當個人要修改程式時，就要從這個區域CHECK OUT程式，這時程式就得屬CHECK OUT的人了，除非該名程式人員把程式更新CHECK IN，否則是不可以更動的。這樣才不會有程式互改的情形發生。

因為DELPHI這種語言的特性，基本上就是為程式人員設計的，所以大家寫的程式都是在自己的電腦上做測試。在自己Local的開發環境上開發程式是有道理的，因為這時你負責的程式你最大，你可以依自己的方式來解決問題(當然還是要遵守一下大家的規定，例如預設值的EVENT位置、引用適當的公共程式，而不要自己寫一套解決相似問題的程式等)，這樣程式的開發效率最快，DEBUG也很容易。

程式測試OK後，就會把程式上傳到共同的檔案管理區，這時個人的程式就告一段落了。

程式的更新分為AP端和Client端。如果狀況很緊急，程式馬上要用(例如不更新程式就沒辦法發薪水)，那就用平台工具更新資料庫，並把AP程式和Client放上主機。然後請使用者從新進入系統，當使用者使用到更改的功能時，就會自動下載Client端程式，然後用新的程式運作。

至於不緊急的程式，可以等大家都下線時做更新，因為有一堆人做修改，其實也很難知道每一個人改了什麼。但是可以確定，就是在共同管理區的程式是可以正確WORK的。那就用平台工具，把資料庫CREATE一次(平台工具會先比對TABLE，有修改的才做修改)，再把程式全部重BUILD，COPY到主機。這樣更新的工作就完成了。主要是資料庫和AP程式會同步更新，Client端是使用者有用到程式，才比對做更新。

沒有特別好，也很平實，不過會有問題通常都是程式人員程式有BUG，很少是更新的錯誤。