---
tags: 大話AWS雲端架構
---
# Chp 17 敏捷式架構 總覽

## 17.1 以往部署新功能需要停機，造成用戶流失

**部署的演進**

最早期的時候

後來部署的方式

* 重建部署：版本A下線後版本B上線
* 滾動部署（滾動更新或者增量釋出）：版本B緩慢更新並替代版本A
* 藍綠部署：版本B並行與版本A釋出，然後流量切換到版本B
* 金絲雀部署：版本B向一部分使用者釋出，然後完全放開
* A/B部署：版本B只向特定條件的使用者釋出
* 影子部署：版本B接受真實的流量請求，但是不產生響應

https://blog.marsen.me/2018/01/07/2018/six_strategies_for_application_deployment/

## 17.2 敏捷式開發論，縮短功能的開發部署週期

#### 敏捷式開發

敏捷軟體開發宣言

* 個人與互動 重於 流程與工具
* 可用的軟體 重於 詳盡的文件
* 與客戶合作 重於 合約協商 
*  回應變化 重於 遵循計劃 

敏捷宣言背後的原則

https://mybaseball52.medium.com/what-is-agile-c55a67aa65ca

**不斷產出**
* 我們永遠希望自己的工作或是產品都能有進度，這樣才能交付工作內容領薪水，或是把產品推到人們面前產生金流。
* 因此，敏捷宣言有提到幾個與不斷產出有關的事項：
* 我們最優先的任務，是透過及早並持續地交付有價值的軟體以滿足客戶需求。
* 經常交付可用的軟體，頻率可以從數週到數個月，以較短時間間隔為佳。
* 可用的軟體是最主要的進度量測方法。
* 敏捷程序提倡可持續的開發。贊助者、開發者及使用者應能維持穩定的步調。

**團隊溝通**

* 業務人員與開發者必須在專案全程中天天一起工作。
* 面對面溝通是傳遞資訊給開發團隊及團隊成員之間效率最高且效果最佳的方法。
* 最佳的架構、需求與設計皆來自於能自我組織的團隊。
* 以積極的個人來建構專案，給予他們所需環境與支援，信任他們可以完成工作。
* 團隊定期自省如何更有效率，並據之適當地調整與修正自己的行為。

**提升設計**

* 持續追求優越的技術與優良的設計，以強化敏捷性。
* 精簡──或最大化未完成工作量之技藝──是不可或缺的。
* 竭誠歡迎改變，就算處於開發後期。敏捷流程掌控變更，以維護客戶競爭優勢。


## 17.3 對應devOps 方法論， 對應的工具

**DevOps 定義**

> DevOps 是開發 (Dev) 和作業 (Ops) 的複合，是人員、程序與技術的聯合，可持續不斷為客戶提供價值。
>
> DevOps 對團隊代表了什麼意義？DevOps 能讓先前各自獨立的角色 (開發、IT 作業、品質工程和安全性) 互相協調並共同作業，以生產更好、更可靠的產品。藉由採用 DevOps 文化特性和 DevOps 做法及工具，團隊能更妥善回應客戶需求、對其建置的應用程式更具信心，並更快速達成業務目標。

https://azure.microsoft.com/zh-tw/overview/what-is-devops/#devops-overview

https://ithelp.ithome.com.tw/articles/10184557



**IaC**

基礎架構即代碼（IaC）是通過代碼（而非手動流程）來管理和置備基礎架構的方法。

利用 IaC，我們可以創建包含基礎架構規範的配置文件，從而便於編輯和分發配置。此外，它還可確保每次置備的環境都完全相同。

通過對配置規範進行整理和記錄，IaC 有助於實現配置管理，並避免發生未記錄的臨時配置更改。

版本控制是 IaC 的一個重要組成部分，就像其他任何軟件源代碼文件一樣，配置文件也應該在源代碼控制之下。

以基礎架構即代碼方式部署還意味著您可以將基礎架構劃分為若幹模塊化組件，它們可通過自動化以不同的方式進行組合。

整體講述方式：部署 ->敏捷式開發->devOps->infra as code