開發的任務到這裡已經差不多，接下來幾天應該都會談一些軟性的議題 XD

至於部署我沒有想要講太多流程或細節，但如果想真正理解部署在做什麼，我也推薦自己實際買網域和架機器來試試看。

我剛開始自學前端時是 2022 年初，那時候 Huli 大大的轉職班已經沒有在經營，但留下的課綱還是蠻好用，尤其是每週的自我檢核：連結。

當時我是看這份課綱搭配影片自學，最狠的就是架站的作業，沒有任何前置教學，得靠自己的 Google 之力生出來。

現在有 AI 的幫助，部署遇到的問題相對更容易解決，所以我更鼓勵大家自己實際部署看看，這樣會對整個應用程式和機器的服務架構更有概念。

下面也簡單講解部署上要釐清的名詞概念。

應用程式 (Application)

鬧鐘、計算機、試算表、電玩遊戲等等，這些東西是我們生活中常接觸到的應用程式。

在啟動 NestJS 時也會看到 LOG [NestFactory] Starting Nest application... 等，所以伺服器程式也是一種應用程式。

廣義來說，設計來解決特定使用者或業務需求的軟體都算是應用程式。

作業系統 (Operating System)

要啟動應用程式，必須要有機器，而且機器必須安裝作業系統，我們個人電腦最常用的 Windows、MacOS，或是手機作業系統 Android、iOS。

而部署最常用的機器，使用的作業系統就是 Linux，因為開源、輕量、相容性等優勢，大部分的雲端平台也都提 Linux 的選項。

機器 (Machine)

就是機器像我們手上的手機本身、電腦主機、銀行 ATM 等等，這些都是機器的一種。

只要我們能夠自己搞定網路設定的話，就可以開放給大家連線到運行在自己機器上的應用程式，就像前面實驗過的 Ngrok。

虛擬機 (Virtual Machine) 則是透過軟體設定，在機器上劃分一個隔離環境來啟動作業系統。

雲端平台提供的機器就是一種虛擬機，所以這些雲端服務背後也是有實體機器在運行的，只是我們不用管理實體機器，只要跟平台端說我要什麼規格的機器和作業系統就好。

像是 GCP 的 Computer Engine、AWS 的 EC2。

部署 (Deployment)

有了機器跟作業系統，我們就可以把專案打包成正式的應用程式，上傳到機器上跑起來，簡單地說就是複製貼上啦！

但專案的改動那麼頻繁，不可能每次都要自己連線到機器再上傳過去，所以平台端通常會有 hook 的功能，允許 GitHub、GitLab 等等的專案來源進行串接，只要滿足特定條件，就會觸發自動化部署。

網路設定 (Network)

應用程式當然不是部署好就能用哩！

要開放給大眾使用的話，就要處理好網路設定，例如防火牆、SSL 憑證、網域、反向代理等等。

自動化 (Automation)

部署被自動化之後就可以串上很多工作流，例如每次觸發部署時都跑測試，只要測試 fail 就取消該次部署。

這些自動化背後也是機器在幫我們執行，像是 GitHub Actions 就可以在 runs-on 指定要用什麼作業系統的虛擬機來跑。

由於專案編譯、打包都需要 CPU 運算，所以部署的條件要設定好，機器也不能太爛，否則像電玩遊戲這種運算消耗比較大的專案，條件沒有設好，機器可能三不五時就掛了。

環境變數 (Environment Variables)

環境變數是一種不直接寫在程式碼裡的數值，最常見的就是 .env 這種純文字檔或者是 XML 等。

環境變數又分成 build-time 和 run-time 兩種類型。

• build-time：在編譯、打包時讀取並寫入到程式中，或是在雲端平台的部署作業執行時讀取
• run-time：在應用程式運行時讀取

像是 DB 的連線設定、帳號密碼，或是第三方服務的 key、secret，就是 run-time 類型的環境變數，所以機器上也會有一個 .env 檔提供應用程式來讀取！

也可以透過 GitHub Actions 設定 SSH 連線，在每次部署時自動將 GitHub Secret 寫到機器上的 .env。

社群上有些討論 Vibe Coding 金鑰的爭議，大部分是因為沒有做好環境變數的處理，對於前後端應用程式的差別又不熟悉的話，很容易就把機敏資訊暴露出去。

小結

1. 親自架一台機器來部署自己的專案，來理解網頁服務的架構和運作
2. 任何專案都應該注意環境變數的管理