Please enable JavaScript.

Coggle requires JavaScript to display documents.

DevOps (部署pipeline (佈署相關實踐 (只生成一次二進位包, 確保生成是經過驗證流程, 不同環境使用相同佈署方式,…

- - - - 可透過IPMI
    - - unix透過collected
      - windows透過效能計數器
- - - - tmux
      - vim
      - 編譯原始碼
      - 系統效能監控: nmon, iostat, sar, vmstat
      - Process監控: ps, top, htop, atop, lsof
      - 網路: nmap, tcpdump, ping, mtr, traceroute, dig, airmon, airodump, iptables, netstat
      - 文字處理能力: awk, grep, sed...
    - - 正向代理
      - 反向代理
      - 負載平衡
      - 快取伺服器
      - 防火牆
      - 網頁伺服器
- - - - 測試先行再寫功能
      - 讓開發承擔更多軟體品質責任
    - - 程式碼合併到 mater分支過程
      - 頻繁小異動合併
        
        容易發現錯誤
      - 自動執行驗證，簡單快速檢視結果
    - - 確保異動能夠部署上線
    - - 異動部署到生產環境過程
    - - 用最小的努力打造產品原型，驗證概念可行性
  - - - 確保資源在生命周期的一致性
  - - - 個人互動重於流程和工具
      - 可用的軟體重於詳盡的文件
      - 與客戶合作重於合約協商
      - 回應變化重於遵循計畫
    - - 強化開發團隊面對專案和客戶的應變能力
      - 明確開發週期 sprint
        
        長度1週到一個月
        
        開始前會議確立該次 sprint目標
        
        sprint結束進行檢討會議
      - 每日scrum會議
        
        成員回答問題
        
        今天預計做什麼幫助團隊完成sprint目標
        
        有發現什麼阻礙團隊達成sprint目標
        
        我做了什麼幫助團隊達成sprint目標
        
        由scrum master 召開
        
        通常早上進行
        
        確保成員朝目標前進
  - - - 專案結束後進行的討論
        
        成功和失敗經驗應用於未來專案
      - 討論主題
        
        發生了什麼事情？
        
        那些部分進行順利？
        
        那些部分做的不好？
    - - 事故發生後的檢討
        
        針對特定狀況的討論
      - 目標是建立組織學習
      - 討論重點
        
        發生什麼事情？
        
        事件細節
        
        補救方式？
    - - 不是為了逃脫責任，而是確保人員可以自在描述事發經過
  - - - 原則
        
        價值(value)
        
        價值流（value stream)
        
        flow
        
        pull
        
        perfection
      - 藉由系統化的識別浪費並減少浪費的方式來追求完善
        
        追求客戶價值最大化和成本浪費極小化
        
        軟體開發應用
        
        透過工具監控避免浪費
        
        改善工作流程
    - - thinking in system
      - how complex system fail
  - - - 偏向被動
        
        建議更重視客戶
      - 核心
        
        service strategy
        
        service design
        
        service transition
        
        service operation
        
        continue service improvement
    - - 使業務經營與IT目標一致
        
        滿足厲害關係人不的需求
        
        涵蓋企業的端到端
        
        採用單一且整合的策略
        
        使用全面性的方法
        
        區分治理和管理
- - - - 重建系統所需的一切配置/腳本/程式
      - 解決團隊相關人員得到的資訊一致
        
        測試相關文件
        
        PM將發布計畫進度表風險日誌
        
        分析人員的需求文件
    - - 關聯的需求或bug單
      - 大標題和詳細描述
      - 給未來追查問題的人提供必要資訊
      - 工具檢查是否包含必要資訊
    - - 頻繁提交表示修改幅度相對小容易理解和維護
  - - - 是否放一份在版控各有優缺
      - 需要有明確的版本
        
        確保最終使用的依賴一致
    - - 應用程式透過多個組件合併而成
        
        使用組件依賴二進位檔案而非原始碼
        
        二進位檔是經過驗證的產出物
  - - - 軟體生命週期對配置的管理
        
        使用同一份編譯結果
        
        部署環境差異使用配置
        
        環境變數
        
        命令列參數
        
        登錄檔
        
        資料庫
        
        外部配置服務
        
        配置檔
      - 會影響軟體行為的都視為一種編寫程式
        
        如何驗證配置？
        
        部署的冒煙測試
      - 配置靈活度和複雜度要找到一個平衡點
    - - 能針對不同環境配置
      - 部署腳本能夠讀取配置
        
        檔案系統文件
        
        優: 簡單，語言實作容易
        
        缺
        
        部份執行環境不支援檔案系統讀寫, 如applet, web client
        
        集群環境需要同步配置
        
        配置服務中心
        
        透過對外服務端口存取佩ㄓ
        
        最好將api封裝方便測試替換
      - 如何描述配置
        
        項目盡可能少
        
        命名盡可能簡單
      - 機密資訊不要放進去
      - 配置需要測試驗證
  - - - 作業系統版本，補丁
      - 軟體依賴套件版本和補丁
      - 網路拓樸結構
      - 外部服務資訊
      - 資料庫香關
    - - 配置與應用軟體包分離
      - 所有配置存放在一起
    - - 能夠自己部署？
      - 它的配置能有效版本控管
      - 能自動化部署？
- - - - 請使團隊能有效且持久的完成工作
  - - - 修正:組織內所有的角色
    - - 修正:一種文化也是一種歷程
      - 修正:特定團隊會造成非必要溝通障礙
    - - 修正
        
        改善工作質量與效率
        
        降低服務中斷時間
        
        提高個人與團隊的效能
    - - 修正
        
        透過舒適的學習
        
        反覆迭代
        
        找出適合自己的工具和流程
    - - 修正
        
        持續向前的過程
    - - 修正
        
        devops是一種文化
        
        沒有特定工具
        
        選擇適合的工具和流程
    - - 修正
        
        devops希望改善工作效能，這部份自動化可以
    - - 修正
        
        可能被吸收或融合不會過時
- - - - 非同步程式碼審核
      - 文件
      - 更新issue 和 bug
      - 顯示每週進度
      - 定期狀態更新
- - - - 能夠描述系統符合需求規範的運作
      - 證明軟體符合需求運作
  - - - 一般稱為功能測試或驗收測試
        
        確保用戶需求得到滿足
        
        開發之前應該先完成測試
        
        工具
        
        JBehave
        
        Cucumber
        
        Twist
        
        Concordion
        
        自動化測試
        
        可快速反饋
        
        維護成本可能很高
        
        可選擇部分採用人工測試
- - - - 容易出錯
        
        壓力來源
      - 冗長文件和SOP
      - 除非你只部署這一次
    - - 後期才能發現問題
      - 開發沒有考量到部署環境
    - - 無法重現操作步驟
        
        無法自動化
        
        無法測試
      - 無法管理變動
  - - - CI/CD
    - - 自動化才能快
      - 接收反饋才能盡早修改錯誤
    - - 團隊成員能夠接收反饋訊息
  - - - build/test/deploy/release流程相關東西
        
        需求文件，測試文件，自動化測試案例，網路配置腳本，部署腳本，資料庫，升級，降級，初始腳本
    - - 錯誤盡早發現盡早修復
      - 團隊每個成員都有職責
      - 測試是持續的過程
    - - PMDC: 計畫執行檢查改進
      - 團隊每個成員都要參與
    - - 理想: 團隊有共同目標，團隊成員互相幫助實現目標，無論成功或失敗都屬於團隊而非個人
- - - - 結構和資料的修改
      - 升級和降級機制
      - 資料庫版本控制技術
        
        資料庫包含目前使用版本資訊
        
        數據異動時提供: 升級和降級腳本
        
        設定目前應用使用版本的機制
        
        升級:依序順序執行升級腳本
        
        降級: 依序執行降級腳本
        
        可查看目前目前版本和可用版本
    - - DbDeploy
      - Flyway
      - IBatis Dbmigrate
      - Microaoft DbDiff
      - Tarantino
    - - Python Django ORM
      - RoR ActiveRecord
      - Java DbDeploy
      - .net DbDeploy.net
      - PHP Laravel Migrations
- - - - 專案所有相關內容都要提交到版本控制
      - 自動化構建
      - 團隊共識
        
        持續集成是一種實踐不是一種工具
        
        團隊需要遵守一些準則
        
        頻繁提交程式到主分支
        
        確保每次異動影響範圍不會太大
        
        容易回滾一個變動
        
        容易驗證一些想法
        
        盡早發現錯誤
        
        修復錯誤是最高優先權
        
        修復完成前不要再提交新程式
        
        避免修復難度
        
        建立全面的自動化測試
        
        Component Testing
        
        測試時間較長
        
        驗收測試(Acceptance Test)
        
        確認功能是否吻合業務驗收要求
        
        測試執行環境最好與生產(Production)環境相同
        
        測試時間較長
        
        Unit Test
        
        需要能夠非常快執行完成
        
        不需要啟動整個應用程式也能運作
        
        不需要連接網路/資料庫/檔案系統
        
        測試劃分階段
        
        提交(Commit)
        
        Build 並執行單元測試並生出可佈署的二進位檔
        
        驗收
        
        驗收測試
        
        集成測試
        
        安全測試
        
        性能測試
        
        使用 Commit 階段產生的二進位檔案
        
        分組驗證縮短執行時間
        
        測試類型
        
        冒煙測試（smoke testing)
        
        基本快速驗證系統是否可運作
        
        回歸測試（regression testing)
        
        可用性測試（usability testing)
        
        驗證功能是否符合用戶需求
        
        A/B testing
        
        一種實驗方法
        
        1 more item...
        
        blue/green deployment
        
        一種部署流程
        
        兩組完全相同環境，一組用於前期驗證，確認無誤再進行切換
        
        canary testing
        
        production環境開放部分用戶使用新功能評估成效
        
        Build 和 Test 時間維持在10分鐘內完成
        
        時間拉太長會影響成員頻繁提交程式的意願
        
        成員開發環境應該盡量與集成環境一樣
        
        依賴套件版本要一致
        
        一個好的應用架構指標就是能夠很容易執行在開發機上
        
        自動化測試和冒煙測試(Smoke Test)能夠一致執行
        
        要達成這個目標需要將所有需要的一切都放入版本控制
        
        回家前確保 Build 成功
        
        隨時準備Rollback前一個版本
        
        如果無法快速修復時(如:10分鐘)
        
        測試驅動開發
        
        為自己導致的問題負責
        
        如果自己的提交導致別人的測試失敗需要負責修復
        
        不要將失敗的測試註解
        
        :!: 除非你明確知道哪個測試已經無效
        
        :!: 除非你要解決其他緊急情況暫時關閉特定測試
        
        :red_flag: 檢查測試數量減少趨勢
        
        測試速度過慢就判定為失敗
        
        編譯警告或程式風格問題視為失敗
    - - Gitlab CI
      - Drone
      - Jenkins
    - - 確認是否有 Build 在執行, 如果有等他執行完成。如果失敗需要與團隊一起修復他，然後才提交新的程式
      - Build 完成並通過 Test 後,合併版控和自己的程式
      - Build和Test合併後的程式是否正常
      - 本地Build和Test成功就可以提交程式
      - 如果 Build 失敗就修復直到進入步驟3
      - 如果 Build 成功就可以進入下一個任務
      - 等待遠端Build這次提交結果
- - - - 沒有唯一正解
      - 找出適合組織的答案
- - - - 充分授權和信任
      - 事後檢討
        
        錯誤中吸取教訓
        
        失敗的價值
    - - 包含 local,try,QA,production環境
      - 具有監控
      - 每日部署約60次，每次10分
      - VM取代刀鋒主機
      - 部署幫助開發完成功能並交付功能給客戶
      - 測試能幫助找出錯誤
      - 監控能看出工作成果造成的影響
    - - 經驗傳承
        
        資深帶領新員工
      - 文件完整