網(wǎng)站建設(shè)的好不好,WordPress yeepay,如何找到網(wǎng)站管理員,寧鄉(xiāng)建設(shè)局網(wǎng)站一、軟件開發(fā)生命周期#xff08;SDLC#xff09;#xff08;一#xff09;概述Software Development Life Cycle#xff08;SDLC#xff09;是組織和實施軟件開發(fā)管理的框架#xff0c;定義系統(tǒng)工程師和開發(fā)人員在軟件開發(fā)和維護(hù)中的工作階段#xff0c;主要包括需求收…一、軟件開發(fā)生命周期SDLC一概述Software Development Life CycleSDLC是組織和實施軟件開發(fā)管理的框架定義系統(tǒng)工程師和開發(fā)人員在軟件開發(fā)和維護(hù)中的工作階段主要包括需求收集、可行性研究、設(shè)計、編碼、測試、部署和維護(hù)等環(huán)節(jié)。二主要SDLC模型瀑布模型Waterfall開發(fā)過程線性所有階段界限分明且逐個完成如同瀑布自上而下流動。是軟件開發(fā)史上第一個、最簡單且優(yōu)秀的SDLC方法之一。適用場景復(fù)雜領(lǐng)域項目如飛機(jī)制造、醫(yī)療、法規(guī)和要求相對穩(wěn)定、需求明確、有嚴(yán)格截止日期和固定成本的項目。缺點不允許返回到以前的開發(fā)階段糾正或?qū)嵤└闹荒茉谙乱粋€迭代中進(jìn)行。流程System engineering → Analysis → Design → Code → Testing → Maintenance迭代/增量模型Iterative Development先以較低成本快速創(chuàng)建產(chǎn)品版本再通過快速連續(xù)的迭代測試和增強(qiáng)。每次迭代生成更新、更可靠的版本需歷經(jīng)多次迭代至最終版本成型。典型特征可在未完全了解需求時啟動開發(fā)。適用場景ERP系統(tǒng)等復(fù)雜項目需求已明確定義、目標(biāo)確定但未來可能有細(xì)微變化的項目。流程Initialization → Requirements → Planning → Design → Implementation → Verification → Evaluation → Deployment敏捷模型Agile結(jié)合增量和迭代方法適應(yīng)靈活的應(yīng)用需求。項目分成小的子部分在迭代中交付每次迭代結(jié)束提供版本供客戶審查和反饋測試信息可融入下一個版本。流行實踐方法Scrum、SAFe、Extreme ProgrammingXP、Kanban。流程Requirement Analysis → Design Document Prototype → Development → Testing → If some errors are there, return to previous steps → Next IterationDevOps模型產(chǎn)生背景傳統(tǒng)SDLC中產(chǎn)品設(shè)計、開發(fā)、測試、運(yùn)維團(tuán)隊目標(biāo)不同測試人員關(guān)注找Bug、開發(fā)人員關(guān)注技術(shù)和高效開發(fā)功能、運(yùn)維關(guān)心系統(tǒng)穩(wěn)定易產(chǎn)生矛盾、增加成本競爭加劇下持續(xù)交付成為大勢所趨。核心目標(biāo)將協(xié)同但目標(biāo)不同的團(tuán)隊聚集共同實現(xiàn)目標(biāo)推動標(biāo)準(zhǔn)化環(huán)境、降低新版本失敗率、縮短交付時間、加快平均恢復(fù)時間。好處減少交付周期更快創(chuàng)建新功能推動創(chuàng)新提升員工參與度和溝通確保應(yīng)用程序更安全穩(wěn)定通過CI/CD實現(xiàn)部署頻率、交付周期等多方面改進(jìn)支持快速實驗、原型設(shè)計和A/B測試避免技術(shù)債務(wù)。關(guān)鍵指標(biāo)平均投產(chǎn)時間Mean-time to production、平均提前時間Average lead-time、部署速度Deployment speed、部署頻率Deployment frequency、生產(chǎn)失敗率Production failure rate、平均恢復(fù)時間Mean-time to recovery, MTTR。流程PLAN → CODE → BUILD → TEST → RELEASE → DEPLOY → OPERATE → MONITOR對比維度傳統(tǒng)開發(fā)模式瀑布式DevOps模式團(tuán)隊協(xié)作開發(fā)、運(yùn)維、測試割裂溝通成本高跨團(tuán)隊協(xié)同共享責(zé)任溝通高效開發(fā)周期周期長迭代慢難以快速響應(yīng)需求小步迭代周期短快速響應(yīng)需求變化部署頻率低通常以周/月為單位風(fēng)險集中高通常以天/小時為單位風(fēng)險分散問題修復(fù)響應(yīng)慢需等待下一階段修復(fù)成本高響應(yīng)快實時反饋修復(fù)成本低自動化程度低大量手動操作易出錯高全流程自動化穩(wěn)定性高風(fēng)險控制后期暴露風(fēng)險難以提前預(yù)判全流程持續(xù)監(jiān)控風(fēng)險提前識別與控制二、DevOps概念基本概念在如今互聯(lián)網(wǎng)的格局下?lián)屨际袌鲎兊糜葹橹匾虼嗣艚蓍_發(fā)越來越被大家所推崇。于是慢慢的有了DevOps這個概念含義就是開發(fā)-運(yùn)維一體化能夠理順開發(fā)和運(yùn)維之間相互配合關(guān)系的任何事物。DevOps是一組過程、部署及開發(fā)系統(tǒng)的統(tǒng)稱用于促進(jìn)開發(fā)應(yīng)用程序/軟件工程、技術(shù)運(yùn)營和質(zhì)量保障QA部門之間的溝通、協(xié)作與整合?？梢钥吹缴蠄D是一個無窮大的一個符號Dev對應(yīng)開發(fā)Ops對應(yīng)運(yùn)維。DevOps的方式可以讓公司能夠更快地應(yīng)對更新和市場發(fā)展變化開發(fā)可以快速交付部署也更加穩(wěn)定。核心就在于簡化Dev和Ops團(tuán)隊之間的流程使整體軟件開發(fā)過程更快速。開發(fā)流程整體的軟件開發(fā)流程包括PLAN開發(fā)團(tuán)隊根據(jù)客戶的目標(biāo)制定開發(fā)計劃CODE根據(jù)PLAN開始編碼過程需要將不同版本的代碼存儲在一個庫中。BUILD編碼完成后需要將代碼構(gòu)建并且運(yùn)行。TEST成功構(gòu)建項目后需要測試代碼是否存在BUG或錯誤。DEPLOY代碼經(jīng)過手動測試和自動化測試后認(rèn)定代碼已經(jīng)準(zhǔn)備好部署并且交給運(yùn)維團(tuán)隊。OPERATE運(yùn)維團(tuán)隊將代碼部署到生產(chǎn)環(huán)境中。MONITOR項目部署上線后需要持續(xù)的監(jiān)控產(chǎn)品。INTEGRATE然后將監(jiān)控階段收到的反饋發(fā)送回PLAN階段整體反復(fù)的流程就是DevOps的核心即持續(xù)集成、持續(xù)部署?？偟膩碚f就是Code階段編碼GitGitLabBuild階段構(gòu)建Maven或GradleOperate運(yùn)行DockerIntegrate集成JenkinsCI/CD(持續(xù)集成)操作Jenkins編寫對應(yīng)腳本文件Code review代碼質(zhì)量檢測Jenkins集成Sonar Qube自定義鏡像HarborJenkins流水線操作WebHook通知操作如釘釘機(jī)器人通知K8S編排更加方便我們管理容器三、為什么會出現(xiàn)DevOps容器化技術(shù)的發(fā)展微服務(wù)架構(gòu)的發(fā)展直接促進(jìn)了DevOps的迅速發(fā)展敏態(tài)需求的增加即探索性工作的增加軟件開發(fā)從傳統(tǒng)的瀑布流方式到敏捷開發(fā)再到現(xiàn)在對敏捷開發(fā)提出了更高的要求近些年創(chuàng)新型的應(yīng)用不斷涌現(xiàn)在這些應(yīng)用的研發(fā)過程中多采用小步快跑、快速試錯的方式這些探索性工作要求運(yùn)維能夠具備一天發(fā)布多次的能力需要企業(yè)完成由穩(wěn)態(tài)到敏態(tài)的轉(zhuǎn)變。軟件開發(fā)活動在企業(yè)經(jīng)營活動中占比的不斷增加業(yè)務(wù)發(fā)展對軟件的依賴由輕度依賴、中度依賴發(fā)展到目前的重度依賴。企業(yè)存在對消除浪費的需求軟件開發(fā)活動在企業(yè)中的位置越來越重要而像企業(yè)經(jīng)營活動一樣軟件開發(fā)活動中也存在著許多的浪費企業(yè)管理上必然存在著 「識別并消除浪費」 的需求。軟件開發(fā)中的浪費包括不必要和必要的浪費不必要的浪費有無人使用的功能、軟件bug、等待測試、等待審批等必要的浪費包括工作項移交、測試、項目管理等。四、DevOps的優(yōu)勢DevOps 的主要優(yōu)勢在于自動化流程可以比人員更快更可靠地執(zhí)行重復(fù)操作。對于組織而言讓開發(fā)人員或其他人員整天構(gòu)建和部署代碼既不可行也無濟(jì)于事。使這些重復(fù)性任務(wù)自動化可以使開發(fā)人員騰出精力去做自己最擅長的工作 ~ 修改代碼。這樣做是允許在幾分鐘之內(nèi)構(gòu)建和部署代碼這僅受組織選擇管理其DevOps管道的方式的限制。這意味著從開發(fā)功能或錯誤修正到向最終用戶提供更好的體驗之間的時間可以大大縮短從而使用戶更加滿意。它還創(chuàng)建了更好的反饋循環(huán)。新功能越早交付給用戶組織就越早可以收集反饋和指標(biāo)并深入了解用戶對其產(chǎn)品的喜好。這使組織保持敏捷并為創(chuàng)新提供了更好的環(huán)境。五、DevOps生命周期DevOps生命周期主要包括產(chǎn)品策劃、研發(fā)、運(yùn)營、推出、項目立項、執(zhí)行、完工而敏捷、持續(xù)集成、持續(xù)部署、持續(xù)交付都是 DevOps 的一個局部的階段。DevOps 在支持全生命周期的過程要以產(chǎn)品的視角來看待真正進(jìn)行交付的時候也要以產(chǎn)品為維度進(jìn)行組織的設(shè)立。DevOps 的核心是一組工具和實踐可幫助組織更可靠更快地構(gòu)建測試和部署軟件。DevOps 使組織能夠比具有傳統(tǒng)開發(fā)和發(fā)布周期的組織更快地發(fā)展和交付其產(chǎn)品從而可以提供競爭優(yōu)勢。與其每天兩周或更長時間發(fā)布一次版本不如每天向用戶交付新功能并且可以在數(shù)小時內(nèi)部署錯誤修正所有這些都遵循相同的可重復(fù)自動化流程。六、DevOps三大原則1、流動原則加速從開發(fā)、運(yùn)維到交付給客戶的流程堅持少做產(chǎn)品開始開發(fā)時采用 MVP 原則產(chǎn)品迭代時要適時做減法持續(xù)分解問題大的變更或需求拆解為一系列小的變更快速解決工作可視化采用 Sprint 看板將工作可視化控制任務(wù)數(shù)量減少前置時間降低測試人員的等待時間減少交接次數(shù)減少不必要的溝通和等待持續(xù)識別和改善約束點提高搭建環(huán)境、需求文檔、QA、開發(fā)、運(yùn)維的生產(chǎn)力消除價值流中的困境和浪費2、反饋原則建設(shè)安全可靠的工作體系在復(fù)雜系統(tǒng)中安全地工作及時發(fā)現(xiàn)問題在源頭保障質(zhì)量為內(nèi)部客戶優(yōu)化工作3、持續(xù)學(xué)習(xí)與實驗原則采用科學(xué)的工作方式將對組織的改進(jìn)和創(chuàng)新作為工作的一部分。建立學(xué)習(xí)型組織和安全文化將日常工作的改進(jìn)制度化把局部發(fā)現(xiàn)轉(zhuǎn)化為全局優(yōu)化在日常工作中注入彈性模式領(lǐng)導(dǎo)層強(qiáng)化學(xué)習(xí)文化七、DevOps與CICD的聯(lián)系與區(qū)別一核心定義CICD軟件工程實踐方法包括持續(xù)集成CI、持續(xù)交付CD、持續(xù)部署CD三個典型階段通過自動化實現(xiàn)高頻度向客戶交付應(yīng)用。DevOps一種文化容器、容器編排、微服務(wù)等技術(shù)使其落地DevOps團(tuán)隊的最終目標(biāo)通常是在開發(fā)環(huán)境中自動化CI/CD。二聯(lián)系與區(qū)別維度DevOpsCICD核心定位文化強(qiáng)調(diào)協(xié)作與共同目標(biāo)實踐方法強(qiáng)調(diào)流程自動化關(guān)注重點文化、角色、協(xié)作流程、工具、自動化目標(biāo)改善客戶體驗和底線結(jié)果實現(xiàn)持續(xù)交付高頻度、高質(zhì)量交付應(yīng)用關(guān)系CICD是DevOps的關(guān)鍵實踐和落地手段是DevOps團(tuán)隊的重要目標(biāo)之一三CICD詳細(xì)解析核心概念持續(xù)集成CI開發(fā)人員的自動化流程實現(xiàn)開發(fā)工作流程自動化包括代碼提交、構(gòu)建、單元測試、集成測試等。持續(xù)交付開發(fā)人員的更改自動進(jìn)行錯誤測試并上傳到存儲庫如GitHub或Image Registry由運(yùn)維團(tuán)隊部署到生產(chǎn)環(huán)境解決開發(fā)和運(yùn)維溝通問題減少部署工作量。持續(xù)部署自動將開發(fā)人員的更改從存儲庫發(fā)布到生產(chǎn)環(huán)境以持續(xù)交付為前提解決手動流程導(dǎo)致的交付速度慢、運(yùn)維超負(fù)荷問題。CICD Pipeline定義為交付新版本軟件必須執(zhí)行的一系列步驟是一套專注于改進(jìn)軟件交付的實踐加入監(jiān)控和自動化。核心價值自動化手動可執(zhí)行但自動化是關(guān)鍵。典型階段Build構(gòu)建應(yīng)用編譯。Test測試代碼測試如JUnit Tests、性能測試。Release發(fā)布將應(yīng)用交付到存儲庫如NPM Registry、Maven repository、Container Registry。Deploy部署將代碼部署到生產(chǎn)環(huán)境如Review App、生產(chǎn)環(huán)境部署。Validation和Compliance驗證與合規(guī)鏡像安全性掃描如Clair等。云原生支持傳統(tǒng)CI/CD為虛擬機(jī)設(shè)計云原生技術(shù)帶來突破如Tekton項目可構(gòu)建Kubernetes風(fēng)格的Pipeline。簡單工作流程Commit Change開發(fā)人員提交代碼至代碼倉庫。Build BinaryCI Server構(gòu)建應(yīng)用程序。Deploy UAT部署到用戶接受度測試UAT環(huán)境。Test UAT在UAT環(huán)境完成測試。Deploy PROD部署到生產(chǎn)PROD環(huán)境。Test PROD在PROD環(huán)境完成測試。常見流水線示例自動化CICD工作流Close Pull Request → GitHub Pull Request → Build → Test → Feedback → Success merges PR to master → Release type → Git tag → More Tests → Upload Artifacts → Staging Deploy → More Tests → Upload Artifacts → Production Deploy多分支Release流水線UpdateMetaData → Deploy to Dev → Test Dev → Notify DevUpdateMetaData → Deploy to QA → Test QA → Notify QAUpdateMetaData → Deploy to Stage → Test Stage → Notify StageUpdateMetaData → Deploy to Prod → Test Prod → Notify ProdKubernetes相關(guān)PipelinePush PipelineCI/CD Pipeline Workflow with KubernetesDeveloper Commit code, push to git → Git Repo → CI Server notices new code starts pipeline → Run tests → Build new Docker image → Push new Docker image to REPOSITORY → Kubernetes Pull new Docker image → Create new pod → Check pod health → If new pod is healthy, Restart deployment, Delete old pod; If new pod is not healthy, Continue running old podPush PipelineCI/CD With Kubernetes and HelmDeveloper Feature Branch → Push → Pull Request → Reviewer Review → Merge → Build Image → Publish Chart to ChartMuseum → Deploy Helm Chart to Development → Verify → Push to Staging Branch → Deploy Helm Chart to Staging → Verify Staging → Merge to Master Branch → Deploy Helm Chart to ProductionPull PipelineWeave Cloud的DevOps方法依賴Config Updater監(jiān)視image變動并更新配置清單和Deploy Synchronizer維護(hù)應(yīng)用當(dāng)前狀態(tài)工作機(jī)制Developer push code change → Git → CI Server build Docker Image → Config Updater update config repo → Deploy Synchronizer pull config and deploy to Kubernetes Cluster四Pipeline模型演進(jìn)Push Pipeline特點代碼從CI系統(tǒng)開始經(jīng)腳本自動化或手動完成Stage憑據(jù)可能保存于代碼中存在安全風(fēng)險。架構(gòu)DevRW Code Repo→ CIRW Image Repo→ ClusterROPull PipelineGitOps特點憑據(jù)保存于集群CI Pipeline構(gòu)建并推送新Image后Deployment Automator拉取Image并更新config repoDeployment Synchronizer察覺集群狀態(tài)落后獲取配置并更新Image。架構(gòu)DevRW Code Repo→ CIRW Image Repo→ Config RepoRO→ OperatorRW Cluster典型GitOps Pipeline兩個Git倉庫代碼倉庫開發(fā)人員推送代碼變更配置倉庫運(yùn)維人員推送基礎(chǔ)設(shè)施和應(yīng)用配置工作流程Developer push code → CI工具鏈測試和構(gòu)建 → CD工具鏈測試和交付推送Image至工件倉庫→ Config Update推送Image變更至配置倉庫 → 根據(jù)分支和發(fā)布策略部署應(yīng)用。