使用Siebel CRM的推薦開發實踐？

Question

我很快就會與Siebel CRM合作，並且正在尋求使用現代開發實踐和企業最佳實踐的建議。

具體來說，我想對以下幾個方面的建議：

• 我們應該如何設置版本控制（特別是與顛覆）？我們的倉庫應該有什麼樣的結構？我們應該如何處理分支和標籤？
• 我們如何做代碼評論？我們如何評估通過Siebel Tools進行的不需要任何「代碼」的修改配置更改？我們希望審查這些質量保證和知識轉移的變化，以及是否符合變更管理政策。
• 什麼樣的變更管理與Siebel的配合良好？我們如何驗證在進行新部署時，只有更改日誌中列出的內容才真正發生更改？
• 我們如何自動測試我們的應用程序？ Siebel甚至可以進行單元測試嗎？我看到了另外一個問題，提出用於Web測試的QTP，但是還有其他選項可行嗎？
• 我們可以通過我們的Siebel開發工作來實現持續集成實踐嗎？
• 對於傳統上屬於「編碼風格」指南的命名約定和其他內容，您有什麼建議？
• 我們應該如何將開發角色與Siebel管理員角色分開？我們的構建/測試/部署週期應該是什麼樣子？

我不可能爲此獲得任何新的昂貴的工具，但如果有一個付費工具可以提供非常好的投資回報率，請隨時提及。

如果您對此有其他建議，但沒有具體針對我的一個問題，請隨時添加。

Answer 1

我們應該如何設置版本控制（特別是使用Subversion）？

使用Siebel Tools文檔中提供的指導。但請注意，Siebel不會從SVN中的文件構建，因此它只能作爲檔案工具使用;您無法管理您的代碼或從SVN構建。

我們的倉庫應該有什麼樣的結構？我們應該如何處理分支和標籤？

的Siebel開發代碼未建或SVN管理的，所以這是做一個漂亮沒用的東西。只需記下您構建SRF的日期並導出您的回購，並與SVN中的標籤或分支匹配。

我們該如何做代碼評論？我們如何評估通過Siebel Tools進行的不需要任何「代碼」的修改配置更改？我們希望審查這些質量保證和知識轉移的變化，以及是否符合變更管理政策。

使用Siebel Tools執行此操作。它有一個內置的「檢查」工具，用於顯示錯誤（所有開發人員在他們簽入之前都應該使用這個工具）和一個diff工具（你需要檢查一個老版本的同一個對象 - 你可以將它拖出SVN如果你想）。我通常每天自動執行一次檢查工具並檢查輸出日誌，並且每天從Siebel服務器自動構建5次，並在編譯期間查找錯誤。通過SVN和一個標準差異工具的差異可能是可能的，但是Siebel對象在SVN中存儲爲類似XML的文件，所以有時很難閱讀。

什麼樣的變更管理對Siebel有效？我們如何驗證在進行新部署時，只有更改日誌中列出的內容才真正發生更改？

？

我們如何自動測試我們的應用程序？ Siebel甚至可以進行單元測試嗎？我看到了另外一個問題，提出用於Web測試的QTP，但是還有其他選項可行嗎？

QTP是要走的標準方法 - 檢查Oracle網站上爲那些他們可能會建議其他廠商。你也可以嘗試Sikuli。

還有沒有其他的事情可以做，以實現我們的Siebel開發力度持續集成實踐？

不是。

什麼建議，你有沒有在「編碼風格」的指導方針命名約定和其他的東西，傳統上會下跌？

結帳Siebel Bookshelf上的電流命名指南的相應部分，並始終使用這些。

我們應該如何將開發角色與Siebel管理員角色分開？

不確定你的意思。

我們的構建/測試/部署週期應該是什麼樣子？

構建一個新的SRF並從Dev一個晚上導出一個新的Repo一次。一旦所有開發工作已經簽入並完成了單元測試，則需要使用下一個SRF和Repo，並將其推入測試環境。在正常的軟件開發的這一點上，你會分支你的SVN並繼續在主幹上開發，但是Siebel是不同的，因爲你不能從SVN構建，並且你不能很容易地將大量來自SVN的文件恢復到你的構建環境中，最好在dev（並暫停主線開發開發直到完成）或測試環境中做好熱修復測試，並在開發環境中進行醜陋的backports（這是大多數人的事實）。構建一個新的SRF並從測試中導出一個新的Repo一次，一旦出現這種情況，請爲您的Production版本提供一個副本。 嘗試堅持不超過4周的週期（設計/原型設計爲1周，設備爲1周，測試爲1周，錯誤修復和部署爲1周） - 任何超過這一點的時間，計劃的開銷將變爲太棒了。

提示更輕鬆的生活：避免eScript（除非在商業服務中）（否則它變得難以管理）;使用所有的Siebel內置工具而不是滾動 - 您自己的;儘量避免任何滾動功能（它總是看起來像個好主意，但總是會破壞性能）;儘量減少屏幕和視圖的數量;當您應該構建報告時，不要構建視圖;始終確保EIM表匹配和您製作的模式擴展 - 即使您現在不使用EIM;嘗試構建集成對象來匹配您的邏輯模式 - 它們總是有用的（對於Web服務，XML發佈）以及在事實之後構建的一份工作。比運行時事件更喜歡工作流策略;不要添加沒有索引的新排序或搜索規範 - 永遠都不會;不要通過LOV表的引用鏈接;總是補丁;如果供應商沒有說你可以做點什麼，那就不要這樣做。

Answer 2

我們爲我們的Siebel系統建立了一套完整的持續集成工具鏈，包括Subversion，Hudson，Jira，Siebel ADM和一些自行編寫的集成了所有內容的東西。

雖然Siebel的「源代碼」不適合標準的CI方法，比如某些基於Java的項目，但這很受歡迎。

而且，是的，您可以將您的文件（包括SIF）放入您的Subversion存儲庫，並將其作爲源用於您的部署。

我打算在http://siebel-ci.blogspot.de/的博客上關注此事 - 敬請期待。

Answer 3

SVN/CVS不適用於Siebel，原因有幾個：
a）Siebel對象是db對象，SVN/CVS等存儲sif等效的更改。
除一些基本查詢外，這些更改不可能查詢。
b）Siebel工具和SVN之間的集成是鬆散耦合的集成。
理想的集成應該與Siebel存儲庫和各種工具配合使用。

看看我們的工具Object Hive，它解決了許多基於文件的版本控制的缺點。
http://www.enterprisebeacon.com/siebel_version_control_tool.html
對象蜂巢已經從地上爬起來專門針對Siebel版本控制，它的一些特點是：
1）基於對象的存儲庫類似於存儲所有版本歷史記錄Siebel庫。
這使得查詢更改和基於更改進行代碼評論變得非常容易。
2）基於瀏覽器的GUI，與Siebel工具類似，用於查詢版本歷史記錄（無需爲更改而梳理sif文件）。
3）無縫集成 - 直接與Siebel存儲庫集成。
對於個體開發人員來說，沒有麻煩的安裝。4）強大的報告功能（實時和批量）輕鬆識別任何時間段的變化。
5）Oracle Exa-ready認證。