小型團隊的 4 個 DevOps 技巧

已發表: 2020-02-08

想知道如何為小型團隊部署 DevOps? 在各種規模的公司中,DevOps 是一個不斷發展的戰略和執行領域。 它加快了上市時間,實現了更快的推出,並使開發人員、運營經理和客戶更加滿意。

我們將討論 DevOps 是什麼,大公司如何部署它,以及小公司現在可以收集和部署哪些經驗教訓和技巧。

什麼是 DevOps?

DevOps 是一個很難定義的術語,主要是因為它包含一系列實踐。 基本上,為了更好的溝通,DevOps 是兩件事的組合:“Dev”代表“開發人員”,“Ops”代表運營。

因此,DevOps 通常是一組代碼開發人員和系統運營經理,他們合作打破知識孤島——本質上是為了確保他們在有效開發和部署代碼時始終保持一致。

DevOps 意味著部門之間的有效溝通。 這意味著共同努力為一個部門製定策略,使另一個部門的生活更輕鬆。 它通常還意味著更多的代碼自動化、更小的代碼塊、源代碼控制系統,也許還有更多的會議。

但是沒有 DevOps 會發生什麼?

為什麼需要 DevOps?

傳統上,運營經理維護生產環境——即客戶和客戶與之交互的一切。

另一方面,開發人員在幕後工作,在測試環境中創建代碼——一個與生產環境隔離的區域。 理想情況下,此開發環境模擬生產環境以及代碼或應用程序在現實世界中的工作方式。

在實踐中,這意味著開發人員在他們的氣泡中編寫代碼並將其發送到生產環境中部署,運營經理必須弄清楚如何在集成新代碼的同時保持一切正常工作和穩定。 開發人員通常忙於編寫新功能,而運營經理則忙於讓每個板塊都在運轉,因此溝通和環境改造的時間很短。

雖然 DevOps 需要一點時間來設置和啟動,但其結果可以使任何公司——無論大小——變得更加敏捷和更具競爭力。

大公司的 DevOps

devops for small teams

DevOps 對大公司來說是一個灌籃高手。 擁有大量開發人員和足夠大的代碼庫,代碼的開發和部署可能是一場巨大的鬥爭。

大公司有更多的客戶。 更多的客戶意味著更多的服務器、更多的功能以及更多的網絡壓力。 這會創建一個更大的代碼庫,這意味著即使是很小的調整也會在環境中產生級聯效應。 而且由於大公司經常嘗試推出新功能以保持市場競爭力,因此他們需要開發環境和生產環境保持同步。

Netflix、Amazon 和 Target 等公司已經採用 DevOps 來簡化他們的服務。 他們的開發環境與生產環境的集成(以及高度自動化)使 Netflix 和 Amazon每天可以部署數千次

亞馬遜使用持續部署和自動源代碼控制系統來自動檢查修訂,在沒有人為乾預的情況下完成構建和測試過程。

NASA 採用了類似的系統,結合使用 Amazon 的 AWS 服務和容器化數據系統,使 NASA 數據專家能夠以恆定的速度與他們的工程師共享遙測數據和分析。

但這些公司和組織是巨大的。 一個小團隊如何才能達到這樣的組織和自動化水平? 小型團隊的 DevOps 如何在野外工作?

小型團隊可以採用的 DevOps 解決方案

小型團隊在人員、部門和資源方面的帶寬與大型公司不同。 然而,這最終成為一把雙刃劍,因為一般來說,較小的團隊已經使用了許多 DevOps 解決方案。 即使是無意的。

然而,這並不意味著沒有工作可以下降。 目前,只有 25% 的軟件行業在高水平上實現 DevOps。

其他 DevOps 工具和策略可以從大公司那裡獲得併同樣有效地使用。

1. 組建 DevOps 團隊

如果你沒有一個龐大的開發團隊,創建一個獨立的 DevOps 團隊可能是不可能的。 如果你有一個開發人員和一個系統經理,或者這些角色由同一個人擔任,那麼“團隊”的想法甚至會讓人覺得很傻。

沒關係。 這不一定是關於創建某種工作組——它只是關於溝通。 即使您有一名開發人員和一名 IT 經理,您的 DevOps“團隊”形式也可能是每週一次的會議和每日的異步更新,以讓彼此了解正在發生的事情。

團隊的主要目標應該是使開發環境與生產環境保持一致,更頻繁地編寫(和部署)較小的代碼塊,並提高自動化和源代碼控制。

讓我們談談這些事情的含義以及如何實現它們。

2. 調整實踐和環境

即使是小型團隊也可以通過讓開發人員更多地訪問生產環境來開始調整他們的環境,即使只是為了監控修訂對最終產品的影響。

嘗試向您的開發團隊提供網絡狀態的運行提要,即使它只是在角落的監視器上。 他們可以立即看到他們部署的代碼可能如何影響流量,或者註意是否有可能是主要問題的突然下降。

您還需要 DevOps 團隊制定策略,使開發測試環境和實際生產環境盡可能接近——理想情況下是相同的。 它將涉及大量會議和一個強大的文檔項目,不僅要使環境保持一致,而且還要隨著時間的推移使它們保持一致。

使這兩種環境保持一致意味著運營團隊將花費更少的時間來嘗試將開發人員代碼改造成最終產品的現實。

3. 部署更小的代碼塊

第三步,跳出大更新的心態。 大型代碼修訂可能需要數週或數月才能進行測試、批准和部署。 這會減慢功能的推出速度,並且通常會降低您在市場上的競爭力。 在出現新的、令人興奮的趨勢或災難性問題時,它還會使您變得不那麼敏捷。

為貴公司的小團隊擴展 DevOps 的關鍵之一是進入編寫更小的代碼塊並更快地部署它們的心態。 這些應該足夠小,以便可以在幾個小時內進行測試和實施。

4. 擁抱自動化和源代碼控制

小團隊成功 DevOps 的最後一條途徑是大量使用自動化。

為什麼要自動化? 一方面,自動化加快了代碼測試和部署。 它還為開發人員和運營經理騰出時間來製定上面列出的 DevOps 策略。 這段額外的時間還可以讓您的開發和運營團隊專注於改善業務的事情,而不僅僅是撲滅大火。 最後,它提高了文檔的效率和準確性,這兩者在入職、教育和合規方面都有各自的優點。

您首先需要一些可以幫助您隨時構建和測試代碼的東西。 像 Jenkins 或 Bitrise 這樣的應用程序可以幫助促進持續集成和交付。

然後,您需要一個源代碼控制平台來跟踪和管理代碼中的修訂。 GitHub 和 SourceForge 等平台可以在這里為您提供幫助。

鏈中的下一步將是一個配置管理系統,以保持全面的一致性和質量。 Chef 或 SaltStack 等工具是很好的起點。

New Relic 創建了一個用於觀察所有系統的平台,對於監控這種端到端的代碼自動化非常有用。

如果您確實必須快速將整個自動化系統轉向新的方向,那麼研究動態配置也是一個好主意。

為小型團隊和小型組織實施 DevOps

不要擔心您的團隊或公司太小而無法有效實施 DevOps。 相反,將這些工具視為一張自助餐桌,您可以從中提取組織理念。

沒有任何組織,無論其規模如何,都不會因更多的溝通、更多的責任以及更大更細粒度的修訂跟踪而受到傷害。