午啪啪夜福利无码亚洲,亚洲欧美suv精品,欧洲尺码日本尺码专线美国,老狼影院成年女人大片

1、 CHINAUNICOM敏捷與DevOps項目全過程研發管控2018年5月23敏捷與DevOps支撐下的快速研發、高效交付天梯-敏捷研發體系平臺1挑戰與變革下的敏捷研發DevOps理念與體系#業務人員開發測試人員運維人員最終用戶想法市場計劃和需求開發和測試發布和部署反饋和優化1stGap2ndGap敏捷DevOps敏捷(Agile)的出現縮小了商業需求與開發直接的隔閡，有效的加快了產品開發的周期和頻率。開發和運維之間的隔閡需要解決，DevOps的理念應運而生。#瀑布開發敏捷開發預見性開發模式每一個步驟有嚴格產出成果人和交互 重于過程和工具可以工作的軟件 重于求全而完備的文檔客戶協作 重于合同談2、判隨時應對變化 重于循規蹈矩設計越完美，成本損失越小不適應快速變化#100%ValuesValues敏捷宣言價值觀敏捷宣言價值觀1個體和交互勝于流程和工具2可工作軟件 勝于 冗長 的文檔3與客戶協作 勝于合同的談判4對變化響應 勝于 遵循原計劃#敏捷開發是“一種以人為核心、迭代、循序漸進的開發方法”在敏捷開發中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果都經過測試，具備可視、可集成和可運行使用的特征。#敏捷研發的目標：任何開發方法和實踐必須服務于業務成功，業務需求的快速響應與高質量交付是敏捷研發體系的最終目標；敏捷研發體系的原則：敏捷研發體系是以快速響應變化為基礎的背景下產生的一種3、軟件交付理念與方法論；敏捷研發沒有具象化的實施準則，不同的團隊的最佳敏捷實踐會不同；需求如何能夠快速迭代與響應；需求如何實現高保真、高質量交付；如何提升版本交付效率；如何降低版本交付的成本；平臺+應用的高度靈活、擴展性的系統架構；中心化、服務化的應用設計；以前端客戶為區分的灰度發布體系；團隊成員的水平與能力；敏捷聚焦的問題敏捷實現的前提#敏捷研發的實現主要取決于流程、管理、團隊與工具四大關鍵要素。通過四大要素的優化與協同，提升軟件交付的效率與質量是敏捷研發體系的核心所在過程 簡單 明確 高效管理 透明化 可視化 可管可控團隊 敏捷化 獨立化 一體化工具 自動化 便捷化#需求和開發團隊對產品業務4、目標達成共識需求分析人員建立和維護產品需求列表（需求會不斷新增和改變），并進行優先級排序需求人員每輪迭代前，Review需求列表，并篩選高優先級需求進入本輪迭代開發開發團隊細化本輪迭代需求，并按照需求的優先級，依次在本輪迭代完成開發團隊每日站立會議、特性開發、持續集成，使開發進度真正透明需求人員對每輪迭代交付的可工作軟件進行驗收和反饋回到第3步，開始下一輪迭代23如何支撐快速研發、高效交付1挑戰與變革下的敏捷研發DevOps理念與體系敏捷與DevOps支撐下的快速研發、高效交付DevOps是軟件開發、運維和質量保證三個團隊之間的溝通、協作和集成所采用的流程、方法和體系的一個集合。它是人們為了及5、時生產軟件產品或服務，以滿足某個業務目標，對開發和運維之間相互依存關系的一種新的理解。打破了目前的RD-QA-OP流水線的流程例如：RD每次提交代碼觸發一系列的自動化步驟，包括編譯、單元測試、代碼覆蓋率、功能測試、部署測試、性能/容量測試，RD，QA,OP都在過程中做質量保障。#Culture(文化)擁抱變革，促進協作和溝通Automation(自動化)將人為干預的環節盡量從價值鏈中消除Lean(精益)使用敏捷和精益原則促使高頻率循環周期題Metrics(度量)與他人分享成功與失敗的經驗，并在錯誤中不斷學習改進Sharing(分享)度量每一個環節并通過度量數據來持續改進#效能提升效能提升上：上6、：能夠有效縮短提交代碼到正式部署上線的時間，降低風險；能夠自動的、快速的提供反饋，以便及時發現和修復缺陷；能夠讓軟件在整個生命周期中處于可部署狀態,能按下按鈕，就能將任意版本、按需部署在任意環境中；能夠讓整個交付過程變成一種可靠、可預期、可視化的過程；文化建設文化建設上：上：團隊重組;交叉組合;加強協作;最小邊界(崗位輪換，知識共享)；方法與技術方法與技術上：上：軟件產品交付過程中IT工具鏈的打通(開發類工具，部署工具，測試工具，度量工具等)；工作流程和標準的定義(開發提交標準，測試標準，部署標準，質量標準);采用敏捷實踐提高開發效率&質量；技術架構上向微服務架構演進降低系統耦合；分工協作上分7、工協作上：與人合作(like one team/face to face);穿他們的鞋走路(put ones shoes);為其他人而工作(for the people)；什么是什么是DevOpsDevOps（DevelopmentDevelopment和和OperationsOperations的組合的組合）:是一種重視“軟件開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例,（此為目標）透過自動化“軟件交付”和“架構變更”的流程,（此為方法）來使得軟件構建、測試、發布能夠更加地高效、快速和可靠（此為結果）。持續改進持續改進上：上：通過對改進過程數據收集、度量8、分析，確定如何對低效過程實施改進；通過工具自動化、工具鏈信息打通實現協作改進；通過ETC組統一識別、推動改進的持續進行；開發、質量、運維之間緊密協作DevOps是一種體系框架，包含文化建設、組織轉型、流程轉變，以及一系列的實踐方法與支撐工具組合23天梯-敏捷研發體系平臺1挑戰與變革下的敏捷研發DevOps理念與體系敏捷與DevOps支撐下的快速研發、高效交付#體系建立敏捷提效任務自助內建質量度量改進 建立適用于自身特點的建立適用于自身特點的DevOpsDevOps實踐體系實踐體系 盡可能清晰定義活動邊界和檢驗標準；敏捷開發模式敏捷開發模式推薦作為DevOps的必選項 選擇Scrum+KANB9、AN+XPScrum+KANBAN+XP實踐方法 CICD可由非專職人員一鍵執行，重復執行；能自動化能自動化的流程盡量自動化 CICD流程對接自動化測試自動化測試；代碼編寫規范及SonarSonar掃描掃描；代碼變更代碼變更影響分析自動評估；持續集成各環節時長及次數度量；持續交付各環節成功率度量；代碼質量各維度度量；根據度量結果進一步優化優化工作流程123455種核心策略#業務人員開發測試人員運維人員最終用戶想法市場計劃和需求開發和測試發布和部署反饋和優化持續業務計劃和需求分析協作式開發持續測試持續監控持續發布和部署DevOps精益和敏捷原理持續改進、持續反饋、持續優化需求快速沉淀到敏捷小組中10、開始迭代各小組認領各自的需求分支和容器化環境，獨立開發需求開發部署測試一體化，快速組成發布版本，隨時交付需求快速響應多小組眾籌研發版本靈活交付同時研發異地多版本多分支多團隊 極端情況可持撐全部需求的獨立自動化部署、測試、快速交付 支持不停服、用戶無感知版本交付 提供正式版本、灰度版本等多版本支持需求研發測試發布Docker版本管理優化提出版本與功能研發分離概念使用Git分布式版本控制，在研發過程中引入多分支，根據需求的優先級不同可隨時制定版本計劃，動態發布。應用部署測試優化基于容器化平臺給不同的小組分配不同的開發測試環境在小組內通過路由算法，可以針對不同的需求內容進行定向部署，測試。自動化程度11、優化 提取各工具之間的配合邏輯，在工具之外做流程的自動化流轉。改變目前各工具各自為戰的狀態，使所有的工具形成一個整體，統一為體系服務。010203基于互聯網的敏捷研發體系#全功能運營管理提升全功能團隊搭建每個敏捷小組可獨立完成需求的分析、研發、測試、發布流程。敏捷配置按照功能劃分敏捷小組，以職能為單位，獨立管理。人員與團隊解耦，靈活調配。團隊配置團隊之間邊界清晰，責任明確。每個團隊獨立對相關需求的全生命周期負責。能力提升團隊內部成員互相學習，成長，通過人員互換，加深業務了解，培養全面型人才傳統的敏捷開發模式，注重小而靈的團隊開發思路，通過團隊內部的快速響應來完成交付目標。但在運營商龐大而復雜的12、需求接收、嚴格把控的版本交付環境下，項目的管理人員如何能夠準確的掌握每一個項目、每一個需求的具體進度成為了困擾我們的難題。針對以上問題，我們設計了不同參與人員各自關注的需求視角加任務視角的敏捷研發過程。需求節點豐富清晰 需求涵蓋任務生命周期 需求狀態流轉自動化 需求驗證自動化 需求交付自動化 任務類型明確 任務驅動需求 任務串并行可配置 任務串聯自動化#需求的整個生命周期過程由業務需求、需求單元、任務三種工作項來呈現。項目人員只需關注分派給自己的任務，通過任務的完成情況來驅動需求單元及需求的狀態變更需求單元做為最小獨立可上線業務單元，狀態節點需盡量細化：需求分析中 需求分析完 需求評審中 需求13、評審完 設計中 設計完 開發中 開發完 分支合并中 分支合并完 測試環境發布中 測試環境發布完 集成測試中 集成測試完 聯調環境發布中 聯調環境發布完 聯調測試中 聯調測試完 生產環境發布中 生產環境發布完 驗證中 驗證完 BUG修復中 BUG修復完任務根據工作的不同分類型，任務狀態只有待分配、活動中、完成三種：需求設計開發合并發布測試#需求研發測試發布運維全過程生命周期管理，覆蓋DevOps體系全系流程多維度、多種視角項目監控，透明化項目管理立會制度，全面信息掌握，準確把握項目進展與問題靈活的人員配置，充分調用各級、各小組人員能力，全面服務項目建設項目管理人員管理#需求與研發持續集成、持續測14、試持續交付需求管理流程管理敏捷管理版本管理單元測試自動構建自動測試性能測試倉庫管理持續部署XunitTestNGRobotframeworkNexus灰度發布天宮持續集成工具（封裝Jenkins）需求管理模塊數字化質量分析代碼安全掃描Review Board/Gerrit/ATDD（Cucumber）系統漏洞掃描開源軟件集中管理單元測試覆蓋率SVN/GIT接口測試UI測試自動性能測試倉儲管理Maven/Gradle代碼影響分析需求管理JmeterKANBAN第三方商業產品工具圖例開源軟件自建平臺工具封裝第三方軟件#任務卡片、關注工作流標準看板狀態：未領取，未開始，進行中，阻塞，完成免費KANB15、AN-Leangoo-Redmine國內：-yugusoft魚骨#看板中支持Sonar違規修改任務、自動化測試任務、缺陷任務從StoryTask均可以派生缺陷（bug）、測試用例（case）#提交階段編譯單元測試分析構建安裝包自動化測試自動化驗收測試自動化容量測試手工測試手工測試演示探索性測試發布階段發布構建好的軟件包只要點擊一下鼠標，就可以將軟件部署到任何目標環境。#持續集成持續集成(CI)(CI)-Continuous Integration大師Martin Fowler對持續集成是這樣定義的：持續集成是一種軟件開發實踐軟件開發實踐，即團隊開發成員經常集成它們的工作，通常每個成員每天至少集16、成一次至少集成一次，也就意味著每天可能會發生多次集成。每次集成都通過自動化的構建自動化的構建（包括編譯，部署，自動化測試)來驗證，從而盡快地發現集成錯誤。許多團隊發現這個過程可以大大減少集成的問題，讓團隊能夠更快的開發內聚的軟件。持續交付持續交付(CD)(CD)-Continuous Delivery持續交付并不是并不是指軟件每一個改動都要盡快的部署到產品環境中。它指的是任何的修改都已證明可以在任何時候實施部署已證明可以在任何時候實施部署。Carl Caum(ccaum)August,2013持續交付(Continuous Delivery)是一系列的開發實踐方法開發實踐方法，用來確保讓代碼能17、夠快速、安全的部署到產品環境中，它通過將每一次改動都提交到一個模擬產品環境中，使用嚴格的自動化測試，確保業務應用和服務能符合預期。因為使用完全的自動化過程來把每個變更自動的提交到測試環境中，所以當業務開發完成時，你有信心有信心只需要按一次按鈕就能將應用安全的部署到產品環境中。Carl Caum(ccaum)August,2013通常將側重研發側的過程稱為稱為CICI（持續持續集成集成），側重正式環境部署的過程稱為側重正式環境部署的過程稱為CDCD（持續交付持續交付）。一般不單獨提持續部一般不單獨提持續部署署（ContinuousContinuous Deployment)Deployment)18、#統一的版本管控 發布版本管理詳細關聯具體的任務單信息發布版本管理詳細關聯具體的任務單信息，防止遺漏和多出任務防止遺漏和多出任務部署版本構建版本部署版本構建版本構建版本構建版本Svn-測試分支Svn-生產分支測試環境生產環境準生產環境交付版本變更范圍-需求處理范圍-代碼&SQL來源-代碼分支構建版本部署環境部署版本上線交付范圍交付版本#CI/CD整體流程開發活動開發活動、測試活動測試活動、生產交付活動通過生產交付活動通過CICICDCD系統串聯自動化并全領域覆蓋系統串聯自動化并全領域覆蓋Agile-敏捷活動CI-持續集成CD-持續交付設計開發需求軟件構建(代碼&SQL)Sonar掃描單元測試J19、unit應用部署(測試環境)自動化測試(接口&UI)集成測試版本交付應用部署(準生產環境)驗收測試應用部署(生產環境)系統運營流程節點可定制#持續集成主要組件：Gitlab+Jenkins+SonarQube+阿里EDAS平臺+RF自動化測試套件Jenkins通過Pipeline腳本拉取Gitlab里面的項目并組合編排編譯順序及后續調用編譯過程中同步使用Jenkins agent對源碼進行sonar檢查編譯成功后將生成的服務包發送到阿里EDAS平臺，使用EDAS來管理服務服務啟動成功后自動運行RF自動化測試腳本，生成測試報告TFS收集分析任務測試發布開發人員1開發人員2開發人員3GitlabM20、erge到分布庫測試分支應用代碼測試腳本生產環境測試環境中央第三方快照通知測試流程開始集成、部署、單元測試、自動化測試pomdeploy拉取測試分支代碼拉取開發環境代碼拉取代碼提交代碼#持續的軟件版本發布/測試項目監控外部調用執行的工作Jenkins，之前叫做Hudson，是基于Java開發的一種持續集成工具，用于監控持續重復的工作。作為全球領先的開源自動化服務器，Jenkins 提供了數以百計的插件來支持構建、部署和自動化任何項目。發布監控#LBABAAAA路由策略現網環境BBBB灰度發布（藍綠切換）流程：部分更新服務，并選擇更新的實例數（綠色版本）如果更新成功，更新會暫停將部分流量引導至新21、實例，進行測試如果測試通過，可繼續更新剩余實例（增加綠版，減少藍版）如果測試失敗，可將服務回滾至舊版本在任何階段如果更新發生錯誤，可將服務回滾到舊版本灰度發布：指逐步擴大某一產品特性（版本）的使用范圍的過程，在灰度期間，有倆個版本在同時使用；大多數場合下灰度發布也常叫做藍綠切換、灰白切換或AB切換。#DevOps灰度發布支持策略：1.對于使用第三方云平臺的應用，通過DCOS調用云平臺的灰度發布能力2.對于使用kubernetes+docker的應用，調用k8s能力進行灰度發布3.對于使用mesos+marathon+docker的應用，調用marathon能力進行灰度發布4.對于自帶部署工具的22、應用，如新版訂單中心，調用自身的部署工具如ACC的能力進行灰度發布5.對于使用Spring cloud架構(非docker化）的應用，調用Eureka的配置能力進行灰度發布6.對于傳統非云化架構的應用，使用滾動發布（分區域逐臺替換）的方式進行灰度發布灰度發布相關因素：灰度發布相關因素：用戶無感知停機用戶無感知停機：在應用切換時在線用戶無感知，也叫“應用無狀態化”容器化（容器化（dockerdocker）：容器化不是灰度發布必要條件，但是大部分的灰度發布都默認首先要容器化，因為容器便于創建和銷毀，具備更高的發布效率和資源使用效率。而傳統模式要經歷“停止老應用更新版本啟動新應用”過程 分布式部署集23、群部署分布式部署集群部署：分布式部署不是灰度發布的必要條件，但是區分正式集群和灰度集群更方便限制灰度應用范圍 容量彈性伸縮容量彈性伸縮：可以根據版本發布的需要自動擴展或收縮應用實例的個數，減少資源浪費 灰度配置灰度配置：灰度版本可以擁有自己的配置文件，可以與正式版本區分。通常需要分布式數據庫或分庫支持。灰度發布版本控制平臺灰度發布版本控制平臺：控制灰度版本的發布或回退平臺，必要條件 灰度路由策略灰度路由策略：灰度發布必要條件#核心價值對軟件產品的二進制文件（.class)進行分析，得到版本變更影響的業務范圍，從而精確進行產品測試，減小回歸測試范圍，降低測試時間，同時避免測試遺漏，保證產品質量軟24、件產品代碼影響分析工具測試指導分析代碼級測試覆蓋率通過java agent方式監控JVM采集方法動態執行數據，與代碼靜態分析變更數據比對，從而得到測試覆蓋率功能延伸最佳實踐：納入持續集成（CI）流程，自動調用，分析結果可視化展現 分析結果輸出到測試環節，以選擇小范圍回歸測試用例 通過代碼級測試覆蓋率分析，確定熱點代碼和非核心不常用業務代碼，促進代碼優化#Sonar效果：1)阻斷級違規：405-02)嚴重級違規：2332-03)代碼變更行數：190#接口自動化測試是接口及服務測試工具。主要特點包括：1.支持Http/https,WEB Service,Restful等接口協議2.支持HSF、CS25、F等微服接口協議3.支持接口定義批量導入4.支持從接口報文自動解析接口定義5.支持自動解析WSDL6.支持個性化的報文加解密實施要素：1.每次持續集成（CI）部署必須調用接口自動測試2.每個成員都承擔接口測試用例的編寫與調試工作，不由專人負責#1、單元測試整體覆蓋率27.5%（其中行覆蓋率29.7%，分支覆蓋率20.8），測試用例總數269702、部分用例采用FUZZ隨機測試理念由程序自動生成。#整體流程BACKLOG用戶需求用戶故事用戶故事用戶需求用戶故事用戶故事用戶需求用戶故事用戶故事開發任務測試任務設計任務單元測試驗證測試開發任務開發任務BACKLOG障礙問題計劃會議：PO主持創建Spr26、int backlog評審會議：PO主持驗收用戶故事回顧會議：只有團隊成員參與好的、待改進、如何改進看板+每日例會：可視化流程鼓勵團隊溝通產品backlog：條目化用戶故事優先級排序按用戶故事組織開發和交付Sprint Backlog：經任務分解和估算的用戶故事經設計的測試用例可以迭代完成的周期持續集成：自動化隨需的軟件構建、靜態代碼掃描、單元測試、部署任務領取編碼&單元測試測試用例&自動化測試腳本集成測試環境準生產環境生產環境開發分支測試分支交付(生產)分支持續集成版本發布集成自動化測試UAT測試應用上線UAT測試組織者缺陷反饋開發測試環境自動化部署執行測試+自動化測試敏捷團隊組成：干系人 PO ScrumMaster 團隊（跨職能，開發，測試等）DevOps平臺系統(工具集)用戶故事未認領未開始執行中阻塞完成1.1.需求敏捷需求敏捷開發模式開發模式2 2.敏捷活動敏捷活動與看板與看板3 3.團隊團隊4 4.CI.CICDCD CHINAUNICOM謝謝