在系統開發中，管理開發環境至關重要。我們需要確保在開發與測試階段進行的所有操作不會影響正式環境的資料。

然而，許多團隊在系統建置初期，常常忽略這一點，因為能夠在本地方便地操作所有服務項目確實很吸引人，覺得一切先求有再求好。然而，當系統逐漸完善，團隊規模擴大後，這樣的做法便可能導致資料庫出現問題，並且在責任追溯上困難重重，出事時搞不好連誰出包了都不知道，甚至出包的人自己都搞不清楚。因此，早期便採取嚴謹的環境區隔策略能夠減少後期潛在的風險。

dbt core 提供了 profiles.yml 來作為建立與資料倉儲的 connection 的工具（文件在此），通過這個檔案，我們就能輕鬆地為開發、測試和生產環境設置不同的連接配置。

這邊先講明一個前提，我們在 BigQuery 中，有將資料倉儲設立了兩個 project，分別對應正式環境與測試環境，而我們會將正式環境的資料做隨機抽樣，將其複製至測試環境同名的資料表中。確保測試環境能夠使用與正式環境相近的數據進行測試，而不會直接操作正式的資料。（省錢 & 降低風險）

1. 本地開發環境：在 vscode / cursor 中進行開發時，會希望寫完的 sql code 能馬上執行看看，而我們絕對不希望剛寫完的東西直接影響到正式資料，因此在本地環境中我們預設連接至測試環境。在這個環境中，我們是透過 OAuth via gcloud 的方式做認證（文件），每個開發者以自己的帳號做登入，每個人各自的權限都有被管理，且操作可以輕易地追溯到始作俑者（？）
2. github action CI/CD 環境：在 github action 中我們會對 PR 進行 CI/CD，我們將其分成兩個環節。首先，在 PR 被建立時，我們在測試環境中執行 CI，確認它在測試環境中可正常運行；第二，在 code review approved 後，於 PR Merge 時，我們在正式環境中執行 CD，確保它有正確部署在正式環境中，而當這個流程遇到錯誤時，馬上發通知至 Slack，通知負責的夥伴加緊處理。這邊我們透過 Service Account File 認證（文件），將 service account 的資訊以 github secret 進行管理。
3. airflow production 環境：在 airflow 的環境中，也可以區分為正式與測試環境， 與 github action 的情境相同，會有兩個 service account 去對應至正式與測試環境，不過這部分的流程與提醒等，就是透過 airflow 去管理，與 dbt 分屬不同管轄。

profile 中，大概會有這些 connection target：

outputs:
  prod:
    type: bigquery
    method: service-account
    project: production_project
    ...
    keyfile: {production_service_account.json}
  test:
    type: bigquery
    method: service-account
    project: test_project
    ...
    keyfile: {test_service_account.json}
  cicd-prod:
    type: bigquery
    method: service-account
    project: production_project
    ...
    keyfile: {production_service_account.json}
  cicd-test:
    type: bigquery
    method: service-account
    project: test_project
    ...
    keyfile: {test_service_account.json}
  dev:
    type: bigquery
    method: oauth
    project: test_project
    ...
target: dev # 預設 connection

隨後，我們就只要記得在不同環境下運行 dbt 指令時，加上不同的參數即可。

dbt build --select model1 --target cicd-test

這樣就能輕鬆的依照不同環境來執行相對應的運行啦！