該報告將從開發人員的角度討論一些 DevOps 實踐。 通常，所有加入 DevOps 的工程師都已經擁有多年的管理經驗。 但這並不意味著這裡沒有開發商的立足之地。 通常，開發人員正忙於修復“當天的下一個緊急關鍵錯誤”，他們甚至沒有時間快速瀏覽 DevOps 領域。 在筆者的理解中，DevOps首先是常識。 其次，這是一個提高效率的機會。 如果您是開發人員，具有常識並希望提高團隊合作效率，那麼這份報告適合您。
讓我自我介紹一下，我完全承認房間裡有人不認識我。 我叫 Anton Boyko，是 Microsoft Azure MVP。 什麼是MVP？ 這是模型-視圖-呈現器。 模型-視圖-演示者正是我。
此外，我目前在 Ciklum 擔任解決方案架構師。 就在最近，我為自己買了一個如此漂亮的域名，並更新了我的電子郵件，我通常在演示中展示它。 您可以寫信給我：me [dog] byokoant.pro。 您可以給我發電子郵件詢問問題。 我通常會回答他們。 唯一的問題是，我不想透過電子郵件收到涉及兩個主題的問題：政治和宗教。 您可以透過電子郵件寫信給我了解其他事宜。 過一段時間，我會回答。
請您簡短自我介紹：
- 我在這個領域已經工作了 10 年了。
- 我在微軟工作過。
- 我是烏克蘭 Azure 社群的創始人，我們於 2014 年在某個地方創立了這個社群。 我們仍然擁有它並且正在開發它。
- 我也是我們在烏克蘭主辦的 Azure 會議創辦人的父親。
- 我還幫忙組織基輔的全球 Azure 訓練營。
- 正如我所說，我是 Microsoft Azure MVP。
- 我經常在會議上發言。 我真的很喜歡在會議上發言。 在過去的一年裡，我表演了大約40次。 如果你經過烏克蘭、白俄羅斯、波蘭、保加利亞、瑞典、丹麥、荷蘭、西班牙或歐洲其他國家，那麼當你參加一個以雲端為主題的會議時，很可能你可能會在演講者名單上看到我。
- 我也是星際爭霸戰迷。
我們來談談議程。 我們的議程非常簡單：
- 我們將討論什麼是 DevOps。 讓我們談談為什麼這很重要。 以前，DevOps 是你寫在履歷上的關鍵字，立刻就收到了 +500 美元的薪水。 例如，現在你需要在履歷中寫下區塊鏈，才能獲得+500美元的薪水。
- 然後，當我們稍微了解這是什麼時，我們將討論 DevOps 實踐是什麼。 但不是一般的 DevOps 背景，而是開發人員可能感興趣的那些 DevOps 實踐。 我會告訴你為什麼你可能會對它們感興趣。 我將告訴您為什麼應該這樣做以及它如何幫助您減輕疼痛。
許多人展示的傳統圖片。 這就是許多項目中發生的情況。 這時我們就有開發和營運部門來支援我們的軟體。 而且這些部門之間互不溝通。
也許，如果你在DevOps和營運部門感受不那麼清楚，你可以與Dev和QA部門進行類比。 從開發人員的角度來看，有些人開發軟體，有些人則很糟糕。 例如，我將我精彩的程式碼提交到儲存庫，然後有一些無賴坐在那裡，將這段程式碼回傳給我並說你的程式碼很糟糕。
這一切的發生都是因為人們彼此之間不溝通。 他們透過一些誤解向對方扔出一些包裹、一些應用程序，並嘗試用它們做點什麼。
DevOps 文化正是旨在摧毀這堵牆，即迫使人們相互溝通，至少了解專案中不同人員的工作以及他們的工作為何重要。
當我們談論DevOps時，有人會告訴你DevOps是當專案有持續整合時； 有人會說DevOps就是專案實現了「基礎設施即程式碼」的實踐； 有人會說 DevOps 的第一步是功能分支、功能標誌。
本質上，這一切都以它自己的方式是正確的。 但這些只是我們的最終實踐。 在繼續這些實踐之前，我建議先看一下這張投影片，它顯示了在您的公司專案中實施 Dev-Ops 方法的 3 個階段。
這張投影片還有第二個非官方名稱。 你可以上網搜尋一下DevOps的三劍客是什麼。 您可能會找到這篇文章。 為什麼是3火槍手？ 下面寫著：人員、流程和產品，即PPP – 波托斯、波托斯和波托斯。 這是 DevOps 的 3 個火槍手。 本文更詳細地描述了為什麼這一點很重要以及它的意義。
當您開始實施 DevOps 文化時，按以下順序實施非常重要。
最初你需要與人交談。 你需要向人們解釋它是什麼以及他們如何從中獲得一些好處。
我們的會議稱為 DotNet Fest。 而且正如主辦單位告訴我的，我們這裡主要邀請的是開發者觀眾，所以我希望大廳裡的大部分人都參與開發。
我們會談論人，我們會談論開發人員每天想要做什麼。 他們最想要什麼？ 他們想要寫一些新程式碼，使用新奇的框架，創造新功能。 開發者最不想要什麼？ 修復舊錯誤。 我希望你同意我的觀點。 這正是開發商想要的。 他們想要編寫新功能，而不是修復錯誤。
特定開發人員產生的錯誤數量取決於他的手臂有多直以及它們從他的肩膀而不是從他的屁股口袋長出的程度。 但是，儘管如此，當我們有一個大型專案時，有時不可能追蹤所有內容，因此我們最好使用一些方法來幫助我們編寫更穩定和更高品質的程式碼。
QA 最想要什麼？ 不知道他們是否在大廳。 我很難說我想要 QA，因為我從來沒有做過。 無意冒犯這些傢伙，有人會說我希望我永遠不會。 但並不是因為我認為他們的工作毫無意義、無用，而是因為我不認為自己是一個能夠有效率地完成這項工作的人，所以我甚至不會嘗試去做。 但據我了解，QA 最不喜歡的是早上工作，不斷運行某種回歸測試，踩在 3 個衝刺前向開發人員報告的相同錯誤上，並說：「你什麼時候才能，達達尼昂先生，修復這個錯誤。 達達尼安先生回答他：“是的，是的，是的，我已經修好了。” 以及我是如何修復了 5 個錯誤並一路完成 XNUMX 個錯誤的。
在生產中支援該解決方案的人們希望該解決方案能夠無錯誤地運行，這樣他們就不必在每個星期五所有普通人都去酒吧時重新啟動伺服器。 開發人員在周五進行了部署，管理員一直等到週六，試圖啟動並修復此部署。
當您向人們解釋他們的目標是解決相同的問題時，您可以繼續將流程正式化。 這是非常重要的。 為什麼？ 因為當我們說「形式化」時，至少在餐巾紙上的某個地方描述您的流程是如何發生的對您來說很重要。 您需要了解，例如，如果您部署到 QA 環境或生產環境，那麼它總是會以此順序發生；在這些階段，我們執行自動單元測試和 UI 測試等。 部署完成後，我們檢查部署是否順利。 但您已經有了清晰的操作列表，在部署到生產環境時必須一遍又一遍地重複這些操作。
只有當您的流程正式化後，您才開始選擇能夠幫助您自動化這些流程的產品。
不幸的是，我經常看到這種情況相反發生。 有人一聽到「DevOps」這個詞，立刻建議安裝Jenkins，因為他們相信，只要安裝了Jenkins，就擁有了DevOps。 他們安裝了 Jenkins，閱讀了 Jenkins 網站上的「How to」文章，試圖將流程塞進這些 How to 文章中，然後來到人們面前，讓人們彎腰，說書上說你需要這樣做，所以我們就這樣做。
這並不是說 Jenkins 是一個糟糕的工具。 我無意以任何方式這麼說。 但這只是其中一種產品。 您使用哪種產品應該是您的最後決定，而不是您的第一個決定。 你的產品不應該由文化和方法的實施來驅動。 理解這一點非常重要，這就是為什麼我在這張投影片上花了這麼多時間並解釋了這麼長時間的所有內容。
我們來談談一般的 DevOps 實踐。 這些是什麼？ 有什麼不同？ 如何試穿它們？ 為什麼它們很重要？
您可能聽說過的第一個實踐稱為持續整合。 也許該專案中的某個人具有持續整合（CI）。
最大的問題是，最常當我問一個人：“你的專案有 CI 嗎？” 他說：“是的”，然後當我問他做什麼時，他向我描述了整個自動化過程。 這並不完全正確。
事實上，CI的實踐只是為了將不同人所寫的程式碼整合到某種單一的程式碼庫中。 就這樣。
除了 CI 之外，通常還有其他實踐 - 例如持續部署、發布管理，但我們稍後會討論。
CI本身告訴我們，不同的人編寫程式碼，而這些程式碼必須不斷整合到單一程式碼庫中。
這為我們帶來了什麼以及為什麼它很重要？ 如果我們有DotNet，那就很好，它是一種編譯語言，我們可以編譯我們的應用程式。 如果它能夠編譯，那麼這已經是一個好兆頭了。 這還沒有任何意義，但這是我們至少可以編譯的第一個好兆頭。
然後我們可以運行一些測試，這也是一個單獨的實踐。 測試全部都是綠色的——這是第二個好兆頭。 但話又說回來，這並不意味著什麼。
但你為什麼要這樣做呢？ 我今天要討論的所有實踐都具有大致相同的價值，即大致相同的收益，並且也以大致相同的方式進行衡量。
首先，它可以讓您加快交貨速度。 這如何幫助您加快交貨速度？ 當我們對程式碼庫進行一些新的更改時，我們可以立即嘗試使用此程式碼執行某些操作。 我們不會等到星期四到來，因為星期四我們將其發佈到 QA 環境，我們就在這裡進行。
我會告訴你我一生中的一個悲傷的故事。 那是很久以前的事了，那時我還年輕、英俊。 現在的我已經年輕、美麗、聰明、謙虛。 前段時間我在做一個專案。 我們有一個由大約 30 名開發人員組成的龐大團隊。 我們有一個非常非常大的企業項目，開發了大約 10 年。 我們有不同的分店。 在儲存庫中，我們有一個供開發人員行走的分支。 還有一個分支顯示了生產中的程式碼版本。
生產分支比可供開發人員使用的分支晚了 3 個月。 這是什麼意思？ 這意味著，一旦我在某個地方出現了由於開發人員的錯誤（因為他們允許）而進入生產的錯誤，並且由於 QA 的錯誤（因為他們查看了它），那麼這意味著如果我收到生產修補程式的任務，那麼我必須回滾3 個月前的程式碼變更。 我必須記住三個月前發生的事情並嘗試解決它。
如果您還沒有這種經驗，您可以在您的家庭專案中嘗試。 最重要的是，不要在商業上嘗試。 編寫幾行程式碼，六個月內忘記它們，然後回來嘗試快速解釋這些程式碼行的含義以及如何修復或優化它們。 這是一次非常非常令人興奮的經驗。
如果我們有持續整合實踐，那麼一旦我編寫了程式碼，我們就可以立即使用許多自動化工具進行檢查。 這可能無法讓我了解全部情況，但無論如何，它將至少消除一些風險。 如果有任何潛在的錯誤，我會立即知道，也就是說，實際上在幾分鐘內。 我不需要回滾3個月。 我只需要回滾 2 分鐘。 一台好的咖啡機甚至沒有時間在 2 分鐘內沖泡咖啡，所以這很酷。
這具有可以在每個項目上一次又一次重複的價值，即不僅僅是您設定的那個。 您可以重複實踐本身，並且對於您對專案所做的每個新更改，CI 本身都會重複。 這使您可以優化資源，因為您的團隊工作效率更高。 您將不再遇到 3 個月前使用的程式碼出現錯誤的情況。 當你坐下來花前兩個小時試圖理解當時發生的事情並在開始糾正某些內容之前了解上下文的本質時，你將不再需要上下文切換。
我們如何衡量這種做法的成功或失敗？ 如果你向大老闆報告我們在 CI 專案上實施的情況，他會聽到等等等等。 我們實施了它，好吧，但是為什麼，它為我們帶來了什麼，我們如何衡量它，我們實施它的正確或錯誤程度如何？
首先，由於 CI，我們可以越來越頻繁地進行部署，而且更頻繁地部署正是因為我們的程式碼可能更加穩定。 同樣，我們發現錯誤的時間減少了，糾正錯誤的時間也減少了，正是因為我們此時此刻從系統收到了答案，我們的程式碼出了什麼問題。
我們的另一個實踐是自動化測試實踐，它通常與 CI 實踐一起出現。 他們齊頭並進。
這裡需要理解什麼是重要的？ 重要的是要了解我們的測試是不同的。 每個自動化測試都是為了解決自己的問題。 例如，我們有單元測試，允許我們單獨測試模組，即它如何在真空中工作？ 這很好。
我們還有整合測試，使我們能夠了解不同模組如何相互整合。 這也不錯。
我們可能有 UI 自動化測試，使我們能夠檢查 UI 的工作滿足客戶設定的某些要求的程度等。
您執行的特定測試可能會影響您執行它們的頻率。 單元測試通常寫得又短又小。 並且它們可以定期啟動。
如果我們談論的是 UI 自動化測試，那麼如果您的專案很小，那就很好。 您的 UI 自動化測試可能需要一些足夠的時間。 但在大型專案中，UI 自動化測試通常需要花費幾個小時。 如果是幾個小時就好了。 唯一的問題是，為每個建置運行它們是沒有意義的。 在晚上運行它們是有意義的。 當每個人早上上班時：無論是測試人員還是開發人員，他們都會收到某種報告，表明我們在晚上運行了 UI 自動測試並獲得了這些結果。 在這裡，檢查您的產品是否滿足某些要求的伺服器的一個小時的工作將比同一個 QA 工程師的一個小時的工作便宜得多，即使他是一個為食物和感謝而工作的初級 QA 工程師。 儘管如此，機器運行一小時會更便宜。 這就是為什麼投資它是有意義的。
我還有另一個項目正在做。 我們對該計畫進行了為期兩週的衝刺。 這個項目很大，對金融部門很重要，不能出錯。 經過兩週的衝刺後，開發週期之後是測試過程，又花了 4 週。 試著想像一下這場悲劇的規模。 我們編寫程式碼兩週，然後像 CodeFreeze 一樣進行，將其打包到應用程式的新版本中，並將其推出給測試人員。 測試人員又測試了 4 週，即在他們測試的同時，我們還有時間為他們準備兩個版本。 這是一個非常悲傷的案例。
我們告訴他們，如果您想提高工作效率，那麼實施自動化測試實踐是有意義的，因為這正是此時此地對您造成傷害的原因。
實踐持續部署。 太棒了，你已經完成建造了。 這已經很好了。 您的程式碼已編譯。 現在，在某些環境中部署此版本會很好。 假設在開發人員的環境中。
為什麼它如此重要？ 首先，您可以查看部署過程本身的成功程度。 我遇到過這樣的項目，當我問：「如何部署應用程式的新版本？」時，他們告訴我：「我們將其組裝並打包到 zip 檔案中。 我們透過郵件將其發送給管理員。 管理員下載並擴展此存檔。 整個辦公室都開始祈禱服務器能夠接受新版本。”
讓我們從簡單的事情開始。 例如，他們忘記將 CSS 放入存檔中或忘記更改 java 腳本檔案名稱中的主題標籤。 當我們向伺服器發出請求時，瀏覽器認為它已經有了這個java腳本檔案並決定不下載它。 而且有一個舊版本，缺少一些東西。 一般來說，可能會出現很多問題。 因此，持續部署的實踐至少可以讓您測試如果您取得乾淨的參考映像並將其上傳到完全乾淨的新環境中會發生什麼。 你可以看到這會導致什麼結果。
此外，當您在彼此之間整合程式碼時，即在命令之間，這也允許您查看它在 UI 上的外觀。
使用大量普通 java 腳本時出現的問題之一是兩個開發人員魯莽地在 window 物件中宣告了一個同名的變數。 然後就看你的運氣了。 誰的java腳本檔案被第二個拉出，就會覆蓋另一個的變更。 這也非常令人興奮。 你進來：一件事對一個人有用，另一件事對另一個人不起作用。 當這一切投入生產時，那真是「太棒了」。
我們的下一個實踐是自動復原的實踐，即回滾到應用程式的先前版本。
為什麼這對開發人員很重要？ 仍然有人記得遙遠的 90 年代，當時電腦很大，程式很小。 Web 開發的唯一方法是透過 PHP。 這並不是說 PHP 是一種糟糕的語言，儘管它確實如此。
但問題是不同的。 當我們部署新版本的 php 網站時，我們是如何部署的？ 大多數情況下，我們會開啟 Far Manager 或其他東西。 並將這些檔案上傳到FTP。 然後我們突然意識到我們有一些很小很小的bug，例如我們忘記加分號或忘記更改資料庫的密碼，而資料庫有一個密碼，它在本地主機上。 我們決定快速連接到 FTP 並在那裡編輯檔案。 這簡直就是火啊！ 這是90年代流行的。
但是，如果你沒有看日曆，90 年代已經快 30 年前了。 現在一切都發生了一點不同。 當他們告訴您：「我們部署到生產環境，但那裡出了問題。」時，請嘗試想像悲劇的規模。 這是您的 FTP 登入名稱和密碼，連接到生產環境並快速修復它。” 如果你是查克·諾里斯，這會起作用。 如果沒有，那麼你就有可能修復一個錯誤，就會再犯 10 個錯誤。這正是為什麼回滾到以前版本的做法可以讓你取得很多成就的原因。
即使某些不好的東西以某種方式進入了某個地方，那麼它是壞的，但不是致命的。 您可以回滾到先前的版本。 如果用這個術語更容易理解的話，可以稱為備份。 您可以回滾到先前的版本，使用者仍然可以使用您的產品，並且您將有足夠的緩衝時間。 您可以冷靜地、不慌不忙地把所有這些都放在本地進行測試、修復，然後上傳新版本。 這樣做確實很有意義。
現在讓我們嘗試以某種方式將前面的兩種實踐結合在一起。 我們將獲得第三個稱為發布管理的工具。
當我們談論經典形式的持續部署時，我們說我們必須從儲存庫的某個分支中提取程式碼，編譯並部署它。 如果我們有同樣的環境就好了。 如果我們有多個環境，這意味著我們每次都必須提取程式碼，即使是從同一個提交中提取程式碼。 我們每次都會將其拉出，每次都會建置它，並將其部署到新環境。 首先，這是時間，因為要建立一個項目，如果你有一個很大的項目並且來自90後，那麼可能需要幾個小時。
除此之外，還有另一種悲傷。 當您建置時，即使在同一台機器上，您也將建置相同的來源，但您仍然無法保證機器處於與上次建置期間相同的狀態。
假設有人進來並為您更新了 DotNet，或者相反，有人決定刪除某些內容。 然後你就會產生認知失調，從兩週前的這次提交開始，我們正在建立一個版本，一切都很好，但現在看起來就像我們試圖建立的同一台機器，相同的提交，相同的代碼，但它不起作用。 你會在很長一段時間內處理這個問題，但事實上你並不會弄清楚。 至少，你的神經會非常緊張。
因此，發布管理實務建議引入一個額外的抽象，稱為工件儲存庫或庫或庫。 你可以隨意稱呼它。
主要想法是，一旦我們在那裡進行了某種提交，比如說，在我們準備部署到不同環境的分支中，我們就會從此提交中收集應用程式以及該應用程式所需的所有內容，然後將其打包到 zip 檔案並將其保存在一些可靠的儲存空間中。 我們可以隨時從該儲存中取得該 zip 檔案。
然後我們將其自動部署到開發環境中。 我們在那裡比賽，如果一切順利，我們就會部署到舞台上。 如果一切順利，那麼我們將相同的存檔部署到生產環境，相同的二進位文件，只編譯一次。
此外，當我們擁有這樣的圖庫時，它還可以幫助我們解決上一張投影片中我們討論回滾到先前版本時所解決的風險。 如果您不小心部署了錯誤的內容，您始終可以從此程式庫中取得任何其他先前的版本，並以相同的方式將其取消部署到這些環境。 如果出現問題，您可以輕鬆回滾到先前的版本。
還有另一個很棒的做法。 你我都明白，當我們將應用程式回滾到以前的版本時，這可能意味著我們還需要以前版本的基礎架構。
當我們談論虛擬基礎設施時，許多人認為這是管理員設定的東西。 比方說，如果您需要一台新伺服器來測試應用程式的新版本，那麼您必須向管理員或開發人員寫一張票。 DevOps 為此需要 3 週時間。 3 週後，他們會告訴您，我們已經為您安裝了一台虛擬機，具有一個核心、3GB RAM 和一台沒有 DotNet 的 Windows 伺服器。 你說：“但我想要 DotNet。” 他們：“好吧，三週後回來。”
這個想法是，透過使用基礎架構即程式碼實踐，您可以將虛擬基礎架構視為另一種資源。
也許，如果你們中有人在 DotNet 上開發應用程序，你可能聽說過一個名為 Entity Framework 的庫。 您甚至可能聽說過實體框架是微軟積極推動的方法之一。 對於使用資料庫，這是一種稱為「程式碼優先」的方法。 這是當您在程式碼中描述您希望資料庫的外觀時。 然後部署應用程式。 它連接到資料庫，它本身決定哪些表存在，哪些表不存在，並創建您需要的一切。
您可以對您的基礎架構執行相同的操作。 專案是否需要資料庫或專案是否需要 Windows 伺服器之間沒有區別。 這只是一個資源。 並且你可以自動化這個資源的創建，你可以自動化這個資源的配置。 因此，每次你想要測試一些新概念、新方法時，你不需要給 devops 寫票，你可以簡單地從現成的模板、現成的腳本為自己部署一個隔離的基礎設施並實現它那裡有你所有的實驗。 您可以刪除它，獲取一些結果並進一步報告。
下一個實踐也存在並且也很重要，但很少有人使用，那就是應用程式效能監控。
關於應用程式效能監控，我只想說一件事。 這種做法最重要的是什麼？ 這就是應用程式效能監控與修理公寓大致相同的地方。 這不是最終狀態，而是一個過程。 你需要定期這樣做。
從一種好的方式來說，在幾乎每個建置上執行應用程式效能監控是件好事，儘管正如您所知，這並不總是可能的。 但是，至少需要為每個版本執行此操作。
為什麼它如此重要？ 因為如果你突然遇到效能下降，那麼你需要清楚地了解原因。 如果您的團隊有兩週的衝刺，那麼您應該至少每兩週將應用程式部署到某個單獨的伺服器，在該伺服器上您有明確固定的處理器、RAM、磁碟等。並運行相同的效能測試。 你得到結果了。 看看它與之前的 sprint 相比有何變化。
如果你發現某個地方的回撤急劇下降，那就意味著這只是因為過去兩週發生的變化。 這將使您能夠更快地識別並解決問題。 再說一遍，這些指標大致相同，您可以透過它們來衡量您的成功程度。
我們的下一個實踐是配置管理實踐。 很少有人認真對待這一點。 但請相信我，這其實是一件非常嚴重的事情。
最近有一個有趣的故事。 這些人來找我說：“幫助我們對我們的應用程式進行安全審核。” 我們一起看了很長時間的程式碼，他們告訴我有關應用程式的信息，畫了圖表。 無論正負，一切都是合乎邏輯的、可以理解的、安全的，但有一個但是！ 他們的原始碼管理中有設定文件，包括使用 IP 資料庫生產的設定文件，以及用於連接到這些資料庫的登入名稱和密碼等。
我說：「夥計們，好吧，你們已經用防火牆關閉了生產環境，但事實上，你們在原始碼管理中擁有生產資料庫的登入名稱和密碼，並且任何開發人員都可以讀取它，這已經是一個巨大的安全風險。 無論您的應用程式從程式碼的角度來看多麼安全，如果您將其保留在源代碼控制中，那麼您將永遠無法通過任何審計。” 我就是這個意思。
配置管理。 我們在不同的環境下可能會有不同的配置。 例如，我們對於 QA、演示、生產環境等的資料庫可能有不同的登入名稱和密碼。
該配置也可以自動化。 它應該始終與應用程式本身分開。 為什麼？ 因為你建立了應用程式一次，然後應用程式並不關心你是否透過某某IP或某某IP連接到SQL伺服器，它應該運作相同。 因此，如果突然有人仍在程式碼中對連接字串進行硬編碼，請記住，如果您發現自己與我在同一個專案中，我會找到您並懲罰您。 它始終放置在單獨的配置中，例如，在 web.config 中。
而這個配置已經是單獨管理的，也就是說，這正是開發人員和管理員可以坐在同一個房間的時刻。 開發人員可以說：「看，這是我的應用程式的二進位檔案。 他們工作。 該應用程式需要一個資料庫才能運作。 二進位檔案旁邊有一個檔案。 在這個檔案中，這個欄位負責登錄，這個是密碼，這個是IP。 將其部署到任何地方。” 對管理員來說簡單明了。 他可以透過管理此配置將其部署到任何地方。
我想談的最後一個實踐是與雲端非常非常相關的實踐。 如果您在雲端工作，它會帶來最大的效果。 這是自動刪除您的環境。
我知道參加這次會議的有幾個人來自與我一起工作的團隊。 在與我合作的所有團隊中，我們都採用這種做法。
為什麼？ 當然，如果每個開發人員都有一個可以 24/7 工作的虛擬機，那就太好了。 但也許這對你來說是新聞，也許你沒有註意到，但開發人員本身並不是 24/7 工作的。 開發人員通常每天工作 8 小時。 即使他上班很早，他也會吃一頓豐盛的午餐，期間他會去健身房。 就讓開發者實際使用這些資源的時候一天12小時吧。 根據我們的立法，每週 5 天中有 7 天被視為工作日。
因此，在工作日，該機器不應工作 24 小時，而只能工作 12 小時，而在周末，機器不應根本不工作。 看起來一切都很簡單，但這裡要說的是什麼？ 透過按照這個基本計畫實施這個簡單的實踐，您可以將維護這些環境的成本降低 70%，也就是您將開發、QA、簡報、環境的價格除以 3。
問題是，剩下的錢怎麼辦？ 例如，如果開發人員還沒有購買 ReSharper，他們應該購買。 或舉辦雞尾酒會。 如果您以前有一個開發和 QA 都可以使用的環境，就是這樣，現在您可以創建 3 個不同的環境，這些環境將被隔離，人們不會互相干擾。
對於持續效能測量的幻燈片，如果專案中資料庫中有1筆記錄，兩個月後就有000萬筆記錄，我們如何比較效能？ 如何理解衡量績效的原因和意義？
這是一個很好的問題，因為您應該始終衡量相同資源上的效能。 也就是說，您推出新程式碼，衡量新程式碼的效能。 例如，您需要測試不同的效能場景，假設您要測試應用程式在輕負載下的效能，其中有 1 個用戶，資料庫大小為 000 GB。 你測量了它並得到了數字。 接下來我們來看另一個場景。 例如，5 個用戶，資料庫大小 5 TB。 我們收到了結果並記住了它們。
這裡重要的是什麼？ 這裡重要的是，根據場景、資料量、並髮用戶數等，您可能會遇到某些限制。 例如，網路卡的限制，或是硬碟的限制，或是處理器能力的限制。 這對您來說理解很重要。 在不同的場景中，您會遇到某些限制。 當你達到這些數字時，你需要理解這些數字。
我們是在談論在特殊測試環境中測量效能嗎？ 也就是說，這不是生產？
是的，這不是生產環境，這是測試環境，它始終相同，以便您可以將其與先前的測量結果進行比較。
Понял，спасибо！
如果沒有問題，我想我們就可以結束了。 謝謝你！
來源： www.habr.com