一千萬個為什麽

搜索

DevOps僅限於使用SaaS產品的公司嗎?



描述DevOps的實踐(如持續交付,自動化等)與提供持續服務的產品(如SaaS產品)相關。

例如,主要為其他客戶開發項目的軟件開發公司在項目結束後可能永遠不會維護這些項目。而客戶項目不與其他客戶共享,因為不相關。

DevOps是否適用於開發一次性多個項目的公司?在這種情況下,DevOps的做法是否適用?

轉載註明原文: DevOps僅限於使用SaaS產品的公司嗎?

一共有 5 個回答:

絕對不!

DevOps全部是關於打破傳統的孤島(部門),以提高效率。

團隊之間更好的溝通,更好的可見性和可靠的自動化流程是實現更好產品的途徑。

我曾經為一家大型媒體公司工作,我們將支持內部工具並開發面向公眾的網站。

DevOps在我們的案例中的好處如下:

  • Through continuous building, we let know the development team earlier rather than later if there are integration or build problems with their code. They can fix issues while their mind is still on the piece of code they just committed.
  • Through continuous testing and delivery (into QA), we enabled the QA team to find problems earlier and report them earlier. This reduced the time it took to find and correct bugs as well as reduce the complexity of these investigation.
  • With out log collection & aggregation tools, we gave to the developers access to something they wouldn't usually look at (they were very keen on the debuggers :) - understanding how logs are seen and used by other teams improved the overall quality of logs
  • We often shared information and created documentation to share knowledge between teams, trying to break down walls. By understanding the Ops' needs, we create a few guides for what should always be kept in mind when bootstrapping an application (where/how to manage properties, etc.). By understanding the Dev's reality (code more features, faster, gogogogo!) we were able to have the ops create servers and clusters that were better suited to the dev's needs.
  • The overall quality of deployments was greatly improved too. Deployments were handled by our team, so we had perfect visibility on both Ops and Dev. This eliminated many issues related to the "code hand-off" where the dev would hand over a package and one-page document to the ops saying "Install this!".

總的來說,無論您每天更新一次或每月更新一次生產環境,也不管您擁有多少客戶或您的業務模式,每個企業都可以使用更好的溝通,更好的工具,更好的可見性,更快的反饋,等等

我和我的團隊負責開發“一次性”產品,一次完成的產品將提供給客戶進行維護或在某些情況下由我們收取費用。

我們仍然需要保持穩固的開發流程來處理來自客戶的持續反饋,以確保我們為他們提供可靠且經過驗證的運行。

雖然客戶不關心DevOps(大多數情況下),但它仍然對我們有幫助。通過DevOps,我們可以快速推送新版本,因此客戶可以在幾分鐘內看到反饋,而不是幾個小時,並且我們還能夠通過Jenkins/Travis的測試捕捉任何錯誤/錯誤。

為確保我們的部署策略在各個項目中保持一致,我們專註於容器化我們的應用程序。使用Docker,我們可以輕松地將應用程序交給我們的客戶。

DevOps節省的成本很難確定。我們確實有額外的成本,以我們選擇用於流水線的軟件(Travis,Jenkins,Puppet,你有什麽)的形式出現,但我們也通過修復錯誤/快速給予客戶反饋來節省時間和金錢。我們快速的響應時間讓我們的客戶高興,反過來,保持我們的錢包快樂。

我曾為生產軟件作為收縮包裝產品的公司工作,如完全安裝和支持的部署以及設備中的嵌入式代碼。在所有這些公司中,DevOps都為開發提供了必要的支持:

  • 使用編譯器,庫和其他構建工具的已知控制配置自動完成可重現的軟件構建。
  • 自動化,可重復的系統測試,用於回歸測試和新功能測試。
  • 其他自動和常規操作(例如,不斷更新的所有支持語言的示例屏幕截圖,供翻譯人員驗證,並且技術作者可將其納入用戶手冊)。

在所有情況下,這些都是單個開發人員可以做的一次性事情,但這不會很好地利用開發人員的時間,也不能保證自動化構建具有相同的配置控制。

以前開發和實施軟件的活動並不需要各部門之間的深入整合。但對於今天來說,有必要密切合作所有部門(開發,IT運營,質量保證等)。

對於開發者來說,變化是他們得到的報酬。企業總是需要改變以適應現代世界。這種理解推動開發人員盡可能多地產生變化。 IT專業人員有不同的理解,其中的變化是傷害。他們每個人都認為它工作正常,有利於業務。事實上,如果我們分開考慮它們,它們都是對的。

所有員工都必須明白他們是單一流程的一部分。 DevOps培養了思維,這使得人們可以認識到每個人的個人決策和行動都應該針對實現單一目標。成功應該從整個開發到交付的周期來衡量,而不是從個人角色的成功。 由於開發人員和維護專家之間的緊密合作,形成了新一代工程師,他們將這兩個學科的最佳成果結合起來,為用戶帶來益處。這體現在具有開發,配置管理,數據庫管理,測試和基礎架構管理經驗的跨職能團隊的出現。

所以這種方法不僅在SaaS中有用。

一點也不。雖然這個主題已經有很多例子,但我想分享一下我自己的趣聞。在2001年,我繼承了一個涉及創建CD的發行版的軟件項目。發布過程的文檔包括由以前的工程師記錄的40(!)個步驟,其中包括一些荒謬的手寫指令,如“打開此配置文件並在第41行更改.jar文件的名稱,以包含版本號新版本“。

我們積極地自動化了構建過程的每一步,用像batch這樣的“補丁”來代替手寫指令。我們甚至不得不與我們的第三方安裝工具供應商一起打開門票,以使他們的項目文件可以打包。

一旦這個過程自動化,我們就買了一臺'CD Jukebox'。在測試通過後的每個晚上,構建機器都會自動創建一個新的安裝CD。我們的測試人員可能會在第二天早上進來,拿起磁盤,並確保所有東西都可以安裝。

當我們可以將軟件作為服務進行部署時,我們肯定有更嚴格的反饋循環,但自動化,反饋,周期時間,小版本等核心原則都適用。