放心進行部署
 達到可預測性部署的預期狀態。 |
|---|
建置可讓您在您的所有環境中，跨工作負載的裝載平台、應用程式、資料和設定資源一致地達成可預測性目標的工作負載供應鏈。 部署機制必須能夠進行自動化、測試、監視及版本設定。 其應該進行模組化，並視需要準備好執行。 其不應以整合型端對端流程來表示。 該供應鏈不一定是為了更快速執行，而是為了在多個反覆項目上達成一致性和自我記錄。
工作負載小組要對供應鏈負責，因為它與他們自己的工作負載有關。
範例案例
Contoso Manufacturing 開發了一個 Java 型應用程式，可用來監視其製造流程並進行最佳化。 該工作負載最近已移轉至 Azure，現在已在 Azure Spring 應用程式、適用於 MySQL 的 Azure 資料庫和 Azure IoT 中樞上執行。
透過程式碼部署基礎結構
使用基礎結構即程式碼 (IaC) 來定義已準備好生產之供應鏈的可重複層面。 偏好宣告式方法，而不是命令式方法。
宣告式 IaC 技術已在設計時將自動化和再使用性納入考量。 您可以將基礎結構部署從個人卸載到工具，並達成一致的品質。
從基礎結構的觀點來看，擁有較少的技術選項可消除工具中的差異，並讓設定漂移易於偵測。 維護也會比較容易。 如果您讓選項與小組的現有技能保持一致，小組就能輕鬆採用它們。
Contoso 的挑戰
- 工作負載的內部部署版本使用了一組指令碼和手動步驟來擴建基礎結構，並跨環境部署應用程式。 在 Azure 移轉流程初期，小組將現有的命令式指令碼修改為以新平台為目標，因而能夠盡可能地重複使用現有的自動化程式碼基底。 另一個採用此方法的原因是缺乏 Azure 和 Bicep 等 IaC 技術的專業知識。
- 隨著移轉的進展且小組變得越來越熟悉平台，他們確信使用 IaC 方法搭配 Bicep 將是更好的解決方案。
套用方法和結果
- 由於缺乏內部知識，因此，小組將移轉和擴展工作負載的部署自動化指令碼外包給有經驗的承包商，他們在專案的初始階段就與開發小組合作，同時為小組的其餘人員提供知識轉移。
- 產生的 Bicep 型實作提供一種更可靠、可管理且有效率的方式，以在 Azure 中佈建基礎結構。 程式碼現在更容易閱讀且可維護，而且 VSCode 中提供絕佳的工具支援。 其也是完全等冪的，並簡化了狀態管理，這是他們在先前/命令式版本中永遠無法完全實現的。
將 IaC 視為與應用程式程式碼相同
遵循 IaC 開發和維護的軟體建議：適度地模組化、避免自訂或低價值的抽象概念，並遵循多層式方法來反映不同的生命週期。 形成基礎層，其中下層會保持不變，上層則會視需要變更。
部署成品 (例如，應用程式二進位檔、IaC 範本和參數) 是受攻擊面的一部分。 套用保證，例如，祕密管理、存取控制和其他安全性要素的準則。
成品經歷了與應用程式程式碼相同等級的工程嚴謹性。 透過同儕檢閱和測試進行品質控制，讓您能夠有信心地進行部署。
多層式方法讓維護變得更容易，並建立明確的責任界限。
將安全性控制措施新增至成品，有助於在部署流程中強化系統。
Contoso 的挑戰
- 專案小組在移轉工作開始時有寬裕的預算，因此僱用了非常有經驗的承包商，在短時間內提供高品質的成果。 承包商使用了個別存放庫進行開發，而該存放庫並未定期針對安全性進行稽核，但會對主要應用程式程式碼存放庫進行稽核。
- 小組已準備好釋出解決方案的重大重新設計，而部署程式碼需要進行顯著變更。 由於開發資源短缺，因此，有兩名實習生正在進行最新一批變更。 當小組的其中一位資深開發人員被叫來協助實習生時，他注意到存放庫中的多個認可與小組的開發標準不符，包括將 API 金鑰之類的應用程式祕密硬式編碼於程式碼基底中。
套用方法和結果
- 小組決定將組建和部署程式碼基底移至針對應用程式程式碼使用的相同存放庫，並開始套用與程式碼基底其他區域相同等級的工程嚴謹性。 程式碼在第一次認可之前達到小組標準、應用程式祕密遭到移除，並對其套用所有其他小組品質標準和工具。
- 因此，小組在提高程式碼品質的同時，保護了這個區段的程式碼基底。 接下來，對程式碼基底這個區域的變更將遵循相同的標準，並利用針對核心應用程式程式碼基底使用的相同工具，包括同儕程式碼檢閱，以及使用品質和安全性工具自動掃描程式碼。
將單一資訊清單上的部署標準化
開發適用於所有環境的通用部署資訊清單。 使用該資訊清單作為綠地專案、累加式工作負載更新或災害復原的預設機制。
套用此方法將可讓您移除維護多個資產的額外負荷。
如果發生災害，復原將快速且可靠，因為您可以部署已嘗試且經過測試的資訊清單，而不是建立臨時的環境。
Contoso 的挑戰
- Contoso Manufacturing 使用完全自動化的管線，將基礎結構、應用程式程式碼和設定變更部署到開發和實際執行環境。 應用程式已設定為在單一區域中具有高可用性。 除了 MySQL 資料庫之外，大部分的應用程式元件都是無狀態的。 資料庫會依照已建立的 RTO/RPO 所指定的設定進行備份，且備份會複寫至次要區域。
- 如果主要區域發生重大或嚴重失敗，小組便會規劃建置新環境，以在次要區域中裝載應用程式。 在計劃性演練中測試 DR 程序期間，嘗試在次要區域中重新建立環境時，部署指令碼會因為缺少數個資源和其他服務限制的可用性而失敗。
套用方法和結果
- 小組透過使用這兩個區域中可用的對等 SKU 來取代某些資源的使用，並讓某些選項可設定為不同的有效值，藉以減輕嘗試在次要區域中佈建時所遇到的問題。
- 此練習增強了小組的信心，讓他們能夠從重大基礎結構失敗中復原。