筆者今天抱持著昏沉沉的頭腦在思考，
靈光一閃的想到，
筆者在寫完軟體後就進行部屬（Deployment），
但除了了解過怎麼安裝，
跟一些聽過就放置的記憶，
就沒去思考過了。

筆者決定今日重新回憶一下這些內容，
今天的內容不會是如何設定，
而是探討何謂部屬，
自動化部屬的各個步驟。

所以這邊不會有詳細的部屬與自動化部屬是怎麼設定，
為了看這些的各位萬分抱歉，
請去看其他地方。

----部屬----

在寫完程式，
要經由一套手續才能放到運行環境，
而這行為叫做部屬。

而部屬實際作為概括來說，
指的是把完成的軟體上傳到特定Server運行，
而Server也可以是本機，
當然本機部屬往往在初始測試的階段都經歷過了。

前提
安裝TOMCAT在Linux上，
設定也都設定好了，
並且打包好應用程式成war檔。

那麼部屬會看起來很簡單的，
只要想辦法把本機的War，
上傳至Linux就行，
不論是用一些應用程式做跳板或是使用scp傳輸，
最後打開終端機(也就是類似cmd的東西)，
最後透過
./catalina.sh deploy war檔案的路徑，
進行部屬。

而最後的部屬，
也可以透過xml，
設定好足夠權限的帳號，
減少一些步驟。
不過進行這一步可能會需要有一點小心，
因為是有可能造成安全性與權限問題。

看起來足夠簡單，
但為什麼現在除了簡單、輕量或是有的一定程度上的依賴舊的建置的話，
都會盡可能的去使用自動部屬呢？

目的是
提高效率、確保穩定性，並降低錯誤風險。

造成這些的主要原因就是重複性的工作，

解決方式為盡可能減少人為操作，包含標準化環境、上板等等。

舉個例子，
如果我要回復到2023年9月的版本，
要怎麼做呢？

第一個方式，在linux部屬的時候，
就把舊有進行備份，
後面帶著日期碼嗎?

如果是一個人這樣勉強能行，
但出現同一日有多個，
同時往往也有著同事，
熟悉的競爭條件又出現，
而人腦又是難以記錄無意義的日常作為，
難以看到實際內容。

這樣就會需要本機使用版本控制的方式去找，
如常見的git。

除此之外最常見的人為操作失誤呢?
胖手指總會有遇到的時候，
像是不小心下到刪除指令呢?
linux可沒有垃圾桶，
這時候只能透過備份拉回來，
或是重新部屬被刪除的部分。

這些總總都會是部屬所容易產生的問題。

----自動化部屬----

懶惰是科學進步的一大動力，
那麼勢必會有眾多前輩前仆後繼的用出方式來解決，
筆者在此獻上敬意。

筆者目前使用的自動化部屬，
Azure DevOps，
那麼怎麼判斷哪些被用成自動化，
又為什麼某些不這樣做呢？

前提創建好Azure DevOps項目，
並設定好代碼管理(如git、Azure Repo...)與其餘環境設定。

第一步 確認程式完成
把程式從正式環境分支出來，
各種各式各樣的測試。
(單元測試 (Unit testing)、整合測試 (Integration testing)、端對端測試 (End-to-end testing) (E2E testing))

第二步 合併分支
確認無合併衝突後，
把分支程式合併到正式機分支，
可能中間會有一些合併正式機前分支，
進行檢驗與解決合併。
最後可能由自己或他人進行檢核確認。

第三步 CI（Continuous Integration）持續整合
從字面上就能看到，
連續/不斷/持續　一體化/整合。

那麼這邊最主要就是排除簡單的驗證問題，
如未引用、衝突未處理好、配置有問題等一系列建置就會發生的問題。

也能給予一些狀況，
如果不符合/符合就是錯誤，
常見的就是單元測試(Unit testing)。

確保不會出現品質不良的程式

最後建置出即將部署的版本（Build）

第四步 CD（Continuous Deployment）持續部署
這邊實際上，
就是部屬，可以手動也可以自動。

第五步 監控錯誤log
一路上的日誌，運行狀態的健康檢查、性能監控等。

Argo、K8s、grafana等等，
各種不同的協助工具。

結論
那麼在一開始說過
判斷有哪些被用成自動化，
那些不能？
第一步 確認程式完成
沒什麼好說的，
第一步要等奇點（technological singularity）。

第二步 合併分支
優化合併技術，
讓合併的範圍縮寫或是不再發生空格或一模一樣的合併衝突，
但這些是絕大多數人無緣參與的。

第三步 CI（Continuous Integration）持續整合
以自動化，但可以透過各種測試方式提升驗證範圍。

第四步 CD（Continuous Deployment）持續部署
為何有分手動或自動呢?

例如為什麼不直接CI過就直接CD，
筆者會認為這邊是看運行的程式的定義，
有時候現在運性的程式不能斷，
或是相對無關緊要的事情，
可以等人數較少的時候，
如離峰時間等等，
避免出現一些不可控的情形發生。

第五步 監控錯誤log
這一步算是明確的可以嘗試自動化，
但不會像之前一樣，
是一個共同的流程，
而會是個案。

某些錯誤只會在某種狀況下發生，
而應對方式也是固定的狀況，
就可以考慮有沒有辦法統一或是自動化解決。

筆者舉一個例子，
防呆，
各位不知道有沒有聽說過，
其中常見的是null去其下調用屬性、方法，
而出現NullReferenceException。

那麼這其實就有切合到自動化的精神。
當然如果直接一刀切是十分危險的。

限縮範圍，
例如在if判斷條件裡面出現NullReferenceException，
就走else路線。

而這樣也有可能過大，
會有安全性的疑慮，
甚至會有去引發其他錯誤的可能。

為了確保其安全性，
在傳入、傳出的驗證中搞類似的事情。

那麼就會考慮到值不值得，
現有機制能不能達到，
會不會更為簡單點。

從上而論可以看到，
這個機制很明顯已經完善，
當然這些是基於現在的狀態所做出的判斷。

而這個機制筆者認為，
一定程度上推進了敏捷開發的進程。

因為這個機制推薦頻繁上板，
原因來至於上版的成本大幅度下降，
導致眾人一起上的程式的優勢，
開始大幅降低。

筆者在此模擬一遍，
假如固定某個時段才能上板，
例如某月一日，
這個期間眾多工程師不斷地上程式，
並且都通過CI，
確認不是不良品。

那麼上版的更改範圍會越發擴大，
比起點一下CD來說，
這個越發膨脹的更改範圍更令人害怕。

當然這是極端情形，
但這就是時代的變遷，
而導致一些行為方式上的轉變。