本文檔旨在爲開始部署CAS Server 提供一個指導思路，爲CAS 部署人員提供一個合適的流程以幫助他們成功的架構和部署CAS Server。
1、收集用例
在部署之前對所需的用例和需求進行文檔記錄、編目和分析是非常重要的。一旦您有了一些想法，請與CAS社區討論並共享這些想法，以瞭解可能已經解決了您今天面臨的相同問題的共同趨勢、實踐和模式。
2、學習架構
理解CAS 是什麼以及它能夠做什麼是很重要的，這可以幫助您使用CAS來完成用例和需求的基礎搭建，您可以通過《CAS SSO介紹》瞭解CAS的架構。
同樣的學習CAS 所支持的協議和規範也很重要，CAS所支持的協議和規範將在後續的文章中逐步介紹。
3、閱讀博客
通常，Apereo Blog 所展現的文章能夠幫助您考慮您的需求和分析特性。通常建議您關注這個博客，儘可能多地瞭解項目新聞和公告，不要回避在整個CAS部署過程中撰寫和貢獻您自己的博客文章、經驗和更新。
4、準備環境
CAS 6.1.X版本的安裝環境要求如下：
（1）JDK：JDK 11 及以上
（2）Servlet 容器：沒有指定特定的Servlet容器，但是Apache Tomcat是最常用的選擇。
（3）構建工具：不需要單獨安裝Gradle，Cas已實現自動化構建。
（4）Git(可選)：雖然不是嚴格的要求，但強烈建議您爲CAS部署安裝Git，並在源代碼控制存儲庫中管理所有CAS構件、配置文件、構建腳本和設置。
（5）操作系統：雖然不指定，但是Linux相比Windows更加通用。
（6）網絡：任何基於Maven/Gradle的項目的構建階段通常都需要Internet連接，包括用於安裝CAS的推薦WAR覆蓋。構建過程通過搜索包含在本地下載和安裝的組件(大多數情況下是jar文件)的在線存儲庫來解決依賴關係。
（7）硬件：坊間證據似乎表明，CAS部署在雙核(3.00Ghz)處理器和8GB內存(至少)的情況下性能良好。如果日誌保存在服務器本身，那麼還需要足夠的磁盤空間(最好是SSD)來存放由cas生成的日誌。
5、部署CAS
建議使用 WAR 包覆蓋的方式安裝（詳細的安裝步驟後續文章再進行介紹），這種方法不需要採用者顯式地下載任何版本的CAS，而是利用覆蓋機制來組合CAS原始構件和本地定製，從而進一步簡化未來的升級和維護。
CAS安裝是一個基本的面向源代碼的過程，我們建議使用WAR overlay項目來組織定製，比如組件配置和UI設計。WAR覆蓋構建的輸出是cas.war文件，該文件可以直接部署到servlet容器(如Apache Tomcat)。
覆蓋是一種避免重複代碼/或資源的策略。與下載CAS代碼庫並從源代碼構建不同，overlay允許您下載項目本身提供的預構建的通用CAS web應用服務器，並覆蓋/插入特定的行爲。在構建時，構建安裝過程將首先嚐試下載提供的二進制工件，然後該工具將定位您的配置文件和在相同的項目目錄中可用的設置，並將它們合併到下載的工件中，以生成一個完整的歸檔文件(例如：case .war)。被覆蓋的工件可能包括資源、java類、圖像、CSS和javascript文件。爲了成功地執行合併過程，本地被覆蓋工件的位置和名稱必須與最初下載的歸檔文件中項目提供的位置和名稱完全匹配。您可以覆蓋項目的 src/main/java文件夾中的Java代碼和src/main/resources中的資源，甚至是cas.war中的的WEB-INF\classes文件夾。它們將由類加載器加載，而不是由WEB-INF\lib中的jar文件中具有相同名稱的資源加載。
不用說，雖然預先啓動時間可能有點複雜，但這種方法有以下明顯的優勢:
- 不需要從源代碼下載/構建；
- 在大多數情況下，只需調整構建腳本以下載更新的CAS版本，升級就會變得非常容易；
- 與託管整個軟件源代碼不同，作爲部署人員，您只保留自己的本地自定義，這使得更改跟蹤更加容易；
- 因爲您只管理相關的更改(而不是整個軟件)，這樣使得您跟蹤源代碼控制存儲庫中的更改變得非常輕量級。
管理覆蓋：
可以通過在覆蓋層中添加、刪除或修改文件來控制CAS的大部分切面(如果不是全部的話);通過添加實現了CAS api的Java源文件或依賴項引用的第三方組件來定製CAS的行爲也是可能的，也是最常見的做法。
使用overlay的過程可以總結爲以下幾個步驟:
A.開始並構建所提供的基本構建/部署，模板可參見 CAS WAR Overlay項目。
B.從生成的構建中確定需要更改的構件。這些工件通常由Gradle的build目錄中的build命令生成，可以使用gradle的explodeWar 任務。
C.將標識的工件從上面標識的目錄複製到src/main/resources目錄:
創建src/main/resources 目錄，如果這個目錄不存在的話；
複製的路徑和文件名必須與對應的構建版本完全匹配，否則更改將不起作用。請參閱下面的表，以瞭解如何將文件夾和文件從構建映射到src。
D.更改之後，重新構建並儘可能多地複用該過程；
E.在構建的二進制工件中仔細檢查您的更改，以確保覆蓋過程正常工作。
注意：不要複製生成的所有內容。儘量減少更改和自定義，只獲取實際需要的內容。確保部署環境保持整潔和精確，否則您將面臨嚴重的升級問題和極大的風險。
在做任何其他事情之前，先建立一個功能基線是非常重要的。避免立即進行特別更改以自定義部署。堅持使用cas提供的默認設置和設置，每次只做一步更改。當您取得進展時，請跟蹤過程和源代碼控制中的應用更改以及標記更改。
6、自定義建議
自定義修改時需要研究清楚需求用例與CAS 特性的映射關係，這需要您瀏覽文檔來尋找最匹配的特性進行應用。但是以下紅線希望您不要踩踏：
- 避免對軟件內部進行特別的更改；
- 避免對核心配置組件(如Spring和Spring Webflow)進行手動更改；
- 如果遇到問題，避免對部署進行一次性的錯誤修復。
相反，以下建議希望您遵從：
- 任何屬於CAS core 的Bug修復和小的改進（不包含您自己開發的部分），希望您能盡一切努力向CAS報告，提供修復方案和補丁，並與CAS社區合作一次性解決這些問題；
- 一定數量的內部CAS組件難以擴充和修改。在大多數情況下，這種方法的目的是引導您遠離危險和不必要的複雜更改。如果您遇到一個需要和有一個特性或用例的配置和實現需要修改的核心內部軟件,希望您能參與社區討論,並嘗試增強直接構建到CAS軟件,而不是把它作爲一個雪花。
總而言之，只有在部署配置真正且完全特定於您的需求時才進行更改。否則，試着總結和貢獻，以保持維護成本低。反覆地，不遵守這一戰略從長遠來看可能會導致災難性的後果。
7、故障排查
故障排查指南可能會對您可能遇到的問題提供一些答案，它通常嘗試描述一種對故障排除和診斷有用的策略。你也可以向CAS維護團隊尋求協助。