我們曾經在一家工廠向客戶提供了電子文件管理系統。 然後到另一個對象。 還有一個。 還有第四次、第五次。 我們太得意忘形了，以至於我們發現了 10 個分散式物件。 結果非常有力……尤其是當我們要交付更改時。 作為交付到生產電路的一部分，測試系統的 5 個場景最終需要 10 小時和 6-7 名員工。 這些成本迫使我們盡可能減少交貨。 經過三年的運營，我們無法忍受，決定透過一些 DevOps 為該項目增添趣味。
現在所有測試都在 3 小時內完成，有 3 個人參與：一名工程師和兩名測試員。 這些改進以數字明確表達，並導致備受喜愛的 TTM 降低。 根據我們的經驗，能夠從 DevOps 中受益的客戶比了解 DevOps 的客戶還要多。 因此，為了讓 DevOps 更貼近人們，我們開發了一個簡單的建構函數，我們將在這篇文章中更詳細地討論它。
現在讓我們更詳細地告訴您。 一家能源公司正在 10 個大型設施中部署技術文件管理系統。 如果沒有 DevOps，要駕馭這種規模的專案並不容易，因為大量的體力勞動極大地延遲了工作，也降低了品質——所有的體力工作都充滿了錯誤。 另一方面，有些專案只有一個安裝，但一切都需要自動、持續且無故障地工作 - 例如，大型整體組織中的相同文件流系統。 否則，有人會手動進行設置，忘記部署說明 - 結果，在生產中設置將丟失，一切都會崩潰。
通常我們透過合約與客戶合作，在這種情況下我們的利益略有不同。 客戶嚴格按照預算和技術規格審視項目。 向他解釋技術規格中未包含的各種 DevOps 實踐的好處可能很困難。 如果他對具有附加業務價值的快速發布感興趣，或者對建立自動化管道感興趣怎麼辦？
遺憾的是，當使用預先批准的成本時，並不總是能找到這種興趣。 在我們的實踐中，曾經有過這樣的情況：我們不得不接一個無良且粗心的承包商的開發。 這太糟糕了：沒有最新的原始程式碼，同一系統的程式碼庫在不同的安裝上是不同的，文件部分缺失，部分品質很差。 當然，客戶無法控制原始碼、彙編、發布等。
到目前為止，並不是每個人都了解DevOps，但是當我們談論它的優勢，談論真正的資源節省時，所有客戶的眼睛都亮了。 因此，包含 DevOps 的請求數量隨著時間的推移而不斷增加。 在這裡，為了輕鬆地與客戶說同一種語言，我們需要快速連接業務問題和 DevOps 實踐，這將有助於建立合適的開發管道。
因此，我們一方面有一系列問題，另一方面我們有 DevOps 知識、實踐和工具。 為什麼不把經驗分享給大家呢？
建立 DevOps 建構函數
敏捷有自己的宣言。 ITIL有自己的方法論。 DevOps 就沒那麼幸運了——它還沒有獲得模板和標準。 雖然 根據對公司發展和營運實踐的評估來確定公司的成熟度。
幸運的是，2014年知名公司Gartner 並分析了關鍵的 DevOps 實踐以及它們之間的關係。 基於此，我發布了一個資訊圖表：
我們把它當作我們的基礎 。 這四個領域中的每一個領域都有一套工具 - 我們將它們收集到資料庫中，確定了最受歡迎的工具，確定了整合點和合適的最佳化機制。 總共結果是 36 個實踐和 115 個工具，其中四分之一是開源或免費軟體。 接下來，我們將討論我們在每個領域所取得的成就，並作為範例，討論如何在創建技術文件管理的專案中實施這一點，我們就是以此開始這篇文章的。
流程
在臭名昭著的 EDMS 專案中，技術文件管理系統按照相同的方案部署在 10 個物件中。 此安裝包括4台伺服器：資料庫伺服器、應用程式伺服器、全文索引和內容管理。 在安裝過程中，它們在單一節點內運行，並位於設施的資料中心內。 所有物件的基礎設施都略有不同，但這不會影響全局互動。
首先，根據DevOps實踐，我們在本地自動化基礎設施，然後將交付到測試電路，然後交付到客戶的產品。 每一個流程都是一步一步製定出來的。 環境設定在原始碼系統中是固定的，並考慮到分發工具包的編譯以進行自動更新。 如果配置發生變化，工程師只需對版本控制系統進行適當的更改 - 然後自動更新就會毫無問題地進行。
由於這種方法，測試過程得到了極大的簡化。 此前，該計畫的測試人員除了手動更新支架外什麼也不做。 現在他們來了，看到一切都在運轉，並做更多有用的事情。 每個更新都會自動測試 - 從表面層級到業務場景自動化。 結果作為單獨的報告發佈在 TestRail 中。
Культура
透過測試設計的例子可以最好地解釋連續實驗。 測試尚不存在的系統是一項創造性工作。 在編寫測試計劃時，您需要了解如何正確測試以及遵循哪些分支。 並且還要在時間和預算之間找到平衡，以確定最佳檢查次數。 重要的是準確選擇必要的測試，考慮使用者將如何與系統交互，考慮環境和可能的外部因素。 沒有不斷的實驗是不可能做到的。
現在談談互動文化。 此前，有兩個對立的面向──工程師和開發人員。 開發商表示： 「我們不關心它將如何啟動。 你們是工程師，你們很聰明，確保它運行無故障”。 工程師回覆： 「你們開發商太粗心了。 讓我們更加小心，我們會減少播放您的版本的頻率。 因為每次你給我們一個有漏洞的程式碼時，我們都不清楚如何進行互動。”。 這是一個從 DevOps 角度來看結構不同的文化互動問題。 在這裡，工程師和開發人員都是團隊的一部分，該團隊專注於不斷變化但同時可靠的軟體。
在同一個團隊中，專家們決心互相幫助。 和以前一樣嗎？ 例如，正在準備一些厚厚的部署說明，大概有50頁左右，工程師看了，有什麼不懂，就罵罵咧咧，凌晨三點就讓開發人員評論。 開發商評論了，也罵了——最後沒人高興。 另外，自然會出現一些錯誤，因為你無法記住說明中的所有內容。 現在，工程師與開發人員一起正在編寫用於自動部署應用軟體基礎架構的腳本。 他們幾乎用同一種語言互相交談。
人
團隊的規模由更新的範圍決定。 該團隊是在交付形成期間招募的；其中包括來自一般專案團隊的有興趣的人員。 然後，與負責每個階段的人員一起編寫更新計劃，並在進展過程中團隊進行報告。 所有團隊成員都是可以互換的。 作為團隊的一部分，我們還有一名後備開發人員，但他幾乎從來不需要連線。
技術
在技術圖中，突出顯示了一些點，但在它們下面有一堆技術 - 您可以出版一整本書及其描述。 所以我們將突出顯示最有趣的內容。
基礎架構即代碼
現在，這個概念可能不會讓任何人感到驚訝，但以前對基礎設施的描述還有很多不足之處。 ，測試環境獨特，它們被珍惜和珍惜，灰塵顆粒被吹掉了。
如今沒有人害怕嘗試。 有虛擬機器的基本鏡像，有現成的部署環境場景。 所有模板和腳本都儲存在版本控制系統中並及時更新。 以前，當需要將包裹運送到展台時，就會出現配置差距。 現在您只需在原始程式碼中新增一行即可。
除了基礎設施腳本和管道之外，文件即程式碼方法也用於文件編制。 因此，可以輕鬆地將新人員連接到項目，根據測試計劃中描述的功能將他們引入系統，並且還可以重複使用測試案例。
持續交付和監控
關於DevOps，我們討論如何選擇用於實施持續交付和監控的工具。 通常不需要重寫任何東西 - 使用先前編寫的腳本、正確建置元件之間的整合並建立通用管理控制台就足夠了。 所有流程都可以使用一鍵或時間表啟動。
在英語中有不同的概念，持續交付和持續部署。 兩者都可以翻譯為“持續交付”，但實際上它們之間還是有細微差別的。 在我們的分散式能源公司的技術文件流程專案中，相反，使用交付 - 當根據命令進行生產安裝時。 在部署中，安裝會自動進行。 該專案中的持續交付通常已成為 DevOps 的核心部分.
一般來說，透過收集某些參數，您可以清楚地了解 DevOps 實踐為何有用。 並將這一點傳達給真正熱愛數字的管理階層。 啟動總數、腳本階段的執行時間、成功啟動的比例——所有這些都直接影響到每個人最喜歡的上市時間，即從提交到版本控制系統到在平台上發布版本的時間。生產環境。 透過實施必要的工具，工程師透過郵件收到有價值的指標，專案經理可以在儀表板上看到它們。 這樣您就可以立即評估新工具的好處。 您可以使用 DevOps 設計器在您的基礎架構上嘗試它們。
誰需要我們的 ?
我們不要假裝：從一開始，他就對我們有用了。 正如我們已經說過的，您需要與客戶使用相同的語言，並且在 DevOps 設計師的幫助下，我們可以快速勾勒出此類對話的基礎。 業務專家將能夠自行評估他們的需求，從而更快地發展。 我們試著讓設計器盡可能詳細，添加大量描述，讓任何使用者都能理解他所選擇的內容。
設計器的格式可讓您考慮公司在建立流程和自動化方面的現有發展。 如果您只能選擇與現有流程良好整合並且可以輕鬆填補空白的解決方案，則無需拆除並重建所有內容。
也許您的開發已經邁向更高的水平，而我們的工具看起來太「隊長」了。 但我們發現它對我們自己有用，並希望它對某些讀者有用。 我們提醒您 給設計師 - 如果有的話，您在輸入初始資料後立即收到圖表。 我們將感謝您的回饋和補充。
來源： www.habr.com