2015年7月30日 星期四

多層式架構的更新

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,很少是更新的錯誤。