開發人員社區中流傳着大量的DevOps神話。考慮到近年來DevOps概念的流行,這並不奇怪。運維
DevOps是鼓勵採用敏捷思惟來提升軟件交付過程的速度和質量的實踐。在DevOps中,開發團隊與運維團隊的相互合做,貫穿整個軟件生命週期,兩者對本身的具體任務負責但並不真正在一塊兒工做。機器學習
若是實施得當,DevOps方法能夠爲組織帶來顯著的積極影響。它能夠下降成本,提升效率,並使開發團隊的工做更加精簡。爲了掌握這個過程的優點,有必要認識到DevOps是什麼、不是什麼。在本文中,就將討論一些流傳甚廣的關於DevOps的一些誤解。工具
關於DevOps最大的誤解之一是它與CI/CD是一回事。事實上,持續集成和交付只是DevOps生命週期的一環,是Devps的關鍵組件。性能
DevOps注重團隊的文化和責任感,它強調團隊中的每一個人都須要參與彼此的任務,這樣能夠提升團隊中的協做和溝通能力。學習
另外一方面,CI/CD經過強調自動化的軟件和工具實現了這種溝通的文化,因此能夠將CI/CD看做達到DevOps的手段。測試
NoOps的概念描述了雲基礎設施足夠自動化,以致於不須要手動管理。人工智能
NoOps被認爲是DevOps的下一個發展模式。與DevOps同樣,它的目標是改進軟件交付,但容許開發人員專一於應用程序開發,而沒必要在基礎設施和維護上花費過多精力。spa
經過使用機器學習和人工智能,能夠自動化設置、部署和監視過程,從而更接近NoOps。vps
自動化是DevOps提供的最大好處之一,但它不是能夠解決全部問題的銀彈。生命週期
持續交付過程使團隊可以快速推出新功能,而且更快地獲得所須要的反饋。固然,這意味着必須確保產品的質量。此外,在擴展時必須考慮到運行狀況和性能,還須要確保順利的生產部署。
自動化CI/CD管道有助於消除代碼提交和部署之間的瓶頸。但這只是軟件交付過程的一個階段。除非開發人員和測試人員結成夥伴關係,不然沒法解決全部問題,且極可能只會將問題轉移到其餘流程。
擁有一個適用於全部團隊和公司的流程是不可能的,這與廣泛的想法相反。每一個組織都有不一樣的需求和要求,即便是同一組織中的不一樣項目也須要不一樣的持續交付管道。
您能夠有隻須要兩到三個環境的項目。例如,頻繁部署的開發、測試和生產環境。在軟件交付週期中有多個階段的項目可能就須要更多的環境。
這就是爲何持續交付管道應該符合公司已經在使用的發佈過程。
關於DevOps的討論主要集中在公司使用的工具上。而後就變成了關於什麼是最好的工具的哲學爭論。相反,應該交流關於更大的前景,如DevOps給公司帶來的商業價值。
DevOps意味着關注文化、心態以及我的如何協同工做。只有在此以後,才應該爲流程選擇正確的工具。團隊常常在工具的大生態系統中尋找最完美的解決方案。構建DevOps管道的時間很長,一旦完成就應該從新進行。
Atlassian的一項研究代表,成功實施DevOps的兩個主要因素是合適的工具和合適的人員。
因爲DevOps的優勢和靈活性,許多世界領先的公司都採用了它。看着這些公司的成功故事,咱們固然會敬佩他們的成就。但咱們效仿的時候,卻忽視了他們的背景和成功的步驟。
有一件事是確定的——這些組織選擇並構建了當時最適合他們的工具和流程。這並不必定意味着咱們必定要效仿這些組織。此外,他們所作的不會奇蹟般地對咱們的業務也起做用。
咱們應該向他們學習,尋找創新和發展的新途徑。探索並找到定義問題空間的正確流程和工具。什麼會給咱們的事業帶來成功?這就是DevOps的所有內容。
頻繁發佈的想法讓公司擔憂他們的軟件發佈不夠連續。「船常」已成爲行業標準。可是,這並無指定時間。多是每兩到三個星期,也多是一天幾回。
最重要的是得到了團隊的信心,使您可以在須要的時候發佈新軟件。CD是一種從主分支發佈代碼並對其充滿信心的能力。DevOps的理念是你的代碼應該在任什麼時候候均可以發佈。
因此請記住,持續交付並不意味着您應該儘量頻繁地發佈,而是給予想要的頻繁發佈的能力,而多長時間發佈一次應該由公司決定。
但願這篇文章能幫助你解開一些廣爲流傳的DevOps誤解,不要讓這種誤解阻礙你團隊的進步。實施DevOps能夠幫助你的公司提升生產力,創造更好的產品,因此不要由於這些DevOps誤區而錯失良機。