讓我們討論一下為什麼 CI 工具和 CI 是完全不同的東西。
CI 旨在解決什麼痛點，這個想法從何而來，它有效的最新確認是什麼，如何理解你有一個實踐而不僅僅是安裝了 Jenkins。
做一篇關於持續整合的報告的想法出現在一年前，當時我正在去面試和找工作。 我與 10-15 家公司交談過，只有其中一家能夠清楚回答 CI 是什麼，並解釋他們如何意識到自己沒有 CI。 其餘的人都在談論關於 Jenkins 的難以理解的廢話:) 好吧，我們有 Jenkins，它確實可以構建，CI！ 在報告中，我將嘗試解釋持續整合實際上是什麼，以及為什麼 Jenkins 和類似工具與此關係非常微弱。
那麼，當您聽到 CI 這個詞時通常會想到什麼？ 大多數人會想到Jenkins、Gitlab CI、Travis等。
即使我們用谷歌搜索，它也會給我們這些工具。
如果您熟悉詢問，那麼在列出工具後，他們會立即告訴您 CI 是指您在 Pull Request 中建置並執行測試以進行提交。
持續整合與工具無關，與在分支中進行測試的程序集無關！ 持續整合是非常頻繁地整合新程式碼的實踐，使用它根本不需要隔離 Jenkins、GitLab 等。
在我們弄清楚成熟的 CI 是什麼樣子之前，讓我們先深入了解它的提出者的背景，並感受他們試圖解決的痛苦。
他們解決了團隊合作的痛苦！
讓我們來看看開發人員在團隊開發時面臨的困難的範例。 這裡我們有一個專案、一個 git 的主分支和兩個開發人員。
他們按照大家早已習慣的方式去上班。 我們在宏偉的計劃中承擔了一項任務，創建了一個功能分支，並編寫了程式碼。
人們更快地完成了該功能並將其合併到母版中。
第二個需要更多時間，後來合併並最終發生衝突。 現在，開發人員不再編寫業務所需的功能，而是將時間和精力花在解決衝突上。
將您的功能與通用大師結合越困難，我們花在上面的時間就越多。 我用一個相當簡單的例子來展示這一點。 這是一個只有 2 位開發人員的範例。想像一下，如果一家公司中有 10 人、15 人或 100 人寫入一個儲存庫。 你會為了解決所有這些衝突而發瘋。
有一個稍微不同的情況。 我們有一個大師和一些開發人員在做一些事情。
他們創造了一根樹枝。
死了一個，一切都好，他就通過任務了。
與此同時，第二個開發人員交出了他的任務。 假設他將其發送以供審核。 許多公司都有一種稱為審查的做法。 一方面，這種做法是好的、有用的，但另一方面，它在許多方面減慢了我們的速度。 我們不會深入討論這個問題，但這裡有一個很好的例子，說明了負評故事可能會導致什麼後果。 您已提交拉取請求以供審核。 開發人員無需再做任何事情。 他開始做什麼？ 他開始承擔其他任務。
在此期間，第二個開發人員做了其他事情。
第一個完成了第三個任務。
過了很長一段時間，他的評論受到了考驗，他正在努力達成協議。 發生什麼事了？ 它捕獲了大量的衝突。 為什麼？ 因為雖然他的拉取請求掛在審查中，但程式碼中的許多內容已經改變了。
除了衝突的故事，還有溝通的故事。 當您的執行緒等待審核時，當它正在等待某些內容時，當您長時間致力於某個功能時，您將停止追蹤服務程式碼庫中其他正在發生的變更。 也許你現在想要解決的問題昨天已經解決了，你可以採取一些方法並重複使用它。 但您不會看到這一點，因為您始終使用過時的分支。 這個過時的分支總是導致您必須解決合併衝突。
事實證明，如果我們作為一個團隊工作，即不是一個人在存儲庫中閒逛，而是5-10 個人，那麼我們不將代碼添加到master 的時間越長，我們遭受的痛苦就越多，因為我們最終需要然後合併它。 我們遇到的衝突越多，使用的版本越舊，問題就越多。
一起做某事是痛苦的！ 我們總是互相妨礙。
這個問題早在20多年前就被注意到了。 我發現極限編程中第一次提到持續整合的實踐。
極限程式設計是第一個敏捷框架。 該頁出現於 96 年。 我們的想法是使用某種程式設計實踐、規劃和其他東西，使開發盡可能靈活，以便我們能夠快速回應客戶的任何變更或要求。 他們從 24 年前就開始面對這個問題，如果你長時間在場外做某件事，那麼你就會花更多的時間在這件事上，因為你會遇到衝突。
現在我們來單獨分析一下「持續整合」這個詞。 如果我們直接翻譯它，我們就會得到持續整合。 但它的連續性如何還不是很清楚；它是非常不連續的。 但它有多少集成度也不是很明顯。
這就是為什麼我現在要引用《極限編程》中的內容。 我們將分別分析這兩個詞。
整合 - 正如我已經說過的，我們努力確保每個工程師都使用最新版本的程式碼，以便他努力盡可能頻繁地將其程式碼添加到公共分支，以便這些是小分支。 因為如果它們很大，那麼我們很容易陷入一週的合併衝突。 如果我們有一個很長的開發週期，例如瀑布式開發，開發人員會離開一個月來削減一些巨大的功能，則尤其如此。 而他將會在很長一段時間內陷入整合階段。
整合是當我們將分支與主分支整合時，我們將其合併。 當我們是 transbase 開發人員時，有一個最終選擇，我們努力確保立即寫入 master 而不需要任何額外的分支。
一般來說，整合意味著獲取您的程式碼並將其拖曳到母版中。
這裡的「連續」一詞是什麼意思，什麼叫連續性？ 實踐意味著開發人員努力盡快整合他的程式碼。 這是他執行任何任務時的目標 - 盡快掌握他的程式碼。 在理想的情況下，開發人員每隔幾個小時就會執行一次此操作。 也就是說，你把一個小問題合併到主問題。 一切都很好。 這就是你努力的目標。 而且這必須持續進行。 你一做事，立刻就放進master裡。
製作某些東西的開發人員應對他為使其正常工作所做的事情負責，而不是破壞任何東西。 這就是測試故事通常出現的地方。 我們希望對我們的提交和合併運行一些測試，以確保它有效。 這就是 Jenkins 可以為您提供幫助的地方。
但對於故事：讓我們把改變做小，讓我們讓任務小，讓我們提出一個問題並立即嘗試以某種方式將其嵌入到 master 中 - 詹金斯在這裡不會提供幫助。 因為 Jenkins 只會幫你執行測試。
沒有它們你也可以做。 這根本不會傷害你。 因為練習的目的是盡可能經常測量，以免在將來的任何衝突上浪費大量時間。
讓我們想像一下，由於某種原因，我們在 2020 年沒有網路。 我們在當地工作。 我們沒有詹金斯。 這可以。 您仍然可以繼續在當地設立分公司。 你在裡面寫了一些程式碼。 我們在3-4小時內完成了任務。 我們切換到 master，執行 git pull，並在那裡合併我們的分支。 準備好。 如果您經常這樣做，那麼恭喜您，您已經實現了持續整合！
現代世界有什麼證據顯示它值得花費精力？ 因為一般情況下是很難的。 如果你嘗試這樣工作，你就會明白一些計劃現在會受到影響，你將不得不投入更多的時間來分解任務。 因為如果你做男人…，那麼你將無法很快達成協議，因此會陷入麻煩。 你將不再有練習。
而且價格會很昂貴。 從明天開始，不可能立即使用持續整合進行工作。 你們需要很長時間才能習慣，需要很長時間才能習慣分解任務，需要很長時間才能習慣重做複習練習，如果你們有的話。 因為我們的目標是讓它今天融化。 如果您在三天內進行審查，那麼您就會遇到問題，並且持續整合不適合您。
但我們現在有任何相關證據告訴我們投資這種做法是有意義的嗎？
我首先想到的是 DevOps 狀態。 這是他們進行了七年的一項研究。 現在他們作為一個獨立的組織來做這件事，但在谷歌的領導下。
他們 2018 年的研究表明，嘗試使用整合速度快、整合頻繁且具有更好 IT 效能指標的短期分支機構的公司之間存在相關性。
這些指標是什麼？ 他們在問卷中從所有公司中獲取了 4 個指標：部署頻率、變更準備時間、恢復服務的時間、變更失敗率。
首先，存在這種相關性，我們知道經常進行衡量的公司有更好的指標。 他們將公司分為幾類：生產緩慢的慢速公司、中績效公司、高績效公司和菁英公司。 菁英是Netflix、亞馬遜，它們速度超快，做任何事都快速、漂亮、有效率。
第二個故事，發生在一個月前。 技術雷達有一篇關於 Gitflow 的精彩文章。 Gitflow 與其他所有分支的不同之處在於它的分支是長期存在的。 有些發布分支會存在很長時間，而功能分支也會存在很長時間。 Technology Radar 的這種做法已轉至「保留」。 為什麼？ 因為人們面臨融入的痛苦。
如果你的分支使用了很長一段時間，它就會被卡住、腐爛，我們就會開始花更多的時間嘗試對其進行某種改變。
最近 Gitflow 的作者說，如果你的目標是持續集成，如果你的目標是想要盡可能頻繁地滾動，那麼 Gitflow 是一個壞主意。 他在文章中單獨補充道，如果你有一個可以為此努力的後端，那麼 Gitflow 對你來說是多餘的，因為 Gitflow 會減慢你的速度，Gitflow 會給你帶來集成問題。
這並不意味著 Gitflow 不好且不應該使用。 這是為了其他場合。 例如，當您需要支援服務或應用程式的多個版本時，即需要長期支援時。
但如果你與支持此類服務的人交談，你會聽到很多痛苦的事實，這個版本是3.2，這是4 個月前的版本，但這個修復程序沒有包含在其中，現在，為了做到這一點，你需要做出一系列改變。 現在他們又陷入困境了，現在他們已經折騰了一個星期試圖實現一些新功能。
正如亞歷山大·科瓦列夫（Alexander Kovalev）在聊天中正確指出的那樣，相關性與因果關係不同。 這是真實的。 也就是說，如果你有持續集成，那麼所有的指標都會很好，這沒有直接的連結。 但存在正相關關係，如果其中一個是，那麼另一個很可能也是。 不是事實，但很有可能。 這只是一種相關性。
看起來我們已經在做一些事情，看起來我們已經在合併，但是我們怎麼能理解我們仍然有持續集成，我們經常合併呢？
Jez Humble 是《Handbook》、《Accelerate》、《持續交付》網站和《持續交付》一書的作者。 他提供了這個測試：
- 工程師的程式碼每天都會到達大師那裡。
- 對於每次提交，您都執行單元測試。
- master中的build失敗了，大約10分鐘就修復了。
他建議使用這樣的測試來確保您有足夠的練習。
我覺得後者有點爭議。 也就是說，如果你能在 10 分鐘內修復它，那麼你就擁有了持續集成，在我看來，這聽起來有點奇怪，但這是有道理的。 為什麼？ 因為如果你經常凍結，就代表你的改變很小。 如果一個小的更改意味著您的主構建被破壞，那麼您可以快速找到示例，因為更改很小。 這裡你有一個小的合併，其中改變了 20-30 行。 而且，相應地，您可以快速了解原因是什麼，因為變化很小，您可以在很小的範圍內搜尋問題。
即使我們的產品在發布後崩潰了，如果我們有持續整合的實踐，我們的行動也會容易得多，因為變化很小。 是的，這會影響規則。 這會受傷。 而且，在這種實踐中，最困難的事情可能是習慣分解任務，也就是說，如何去做，以便你可以在幾個小時內完成某件事，同時通過審查，如果你有一個。 審查是一種單獨的痛苦。
單元測試只是一個助手，可以幫助您了解整合是否成功以及是否沒有任何問題。 在我看來，這也不完全是強制性的，因為這不是實踐的重點。
這是對持續整合的簡要介紹。 這就是這個練習的全部。 我準備好回答問題了。
我再簡單總結一下：
- 持續整合不是 Jenkins，也不是 Gitlab。
- 這不是一個工具，而是我們盡可能頻繁地將程式碼合併到母版中的實踐。
- 我們這樣做是為了避免將來合併帶來的巨大痛苦，也就是說，我們現在經歷一點痛苦，以免將來經歷更多。 這就是重點。
- 另一方面是透過程式碼進行通信，但我很少看到這種情況，但這也是它的設計目的。
問題
未分解的任務怎麼辦？
分解。 問題是什麼？ 能舉個例子，有一個任務，沒有分解嗎？
有些任務無法用「完全」這個詞來分解，例如，那些需要非常深厚的專業知識並且實際上可以在一個月的時間內解決以取得一些易於理解的結果的任務。
如果我理解正確的話，那麼有一些大而複雜的任務，其結果只有一個月才能看到？
恩，那就對了。 是的，最遲可以在一個月內評估結果。
美好的。 一般來說，這不是問題。 為什麼？ 因為在這種情況下，當我們談論樹枝時，我們並不是在談論具有特徵的樹枝。 特徵可能很大而且很複雜。 它們會影響大量組件。 也許我們無法在一個分支中完全完成這些任務。 這可以。 我們只需要分解這個故事。 如果某個功能尚未完全準備好，這並不意味著其程式碼的某些部分無法合併。 例如，您新增了遷移，並且該功能內部有一些階段。 假設您有一個階段 - 進行遷移，新增方法。 你已經可以每天測量這些東西了。
美好的。 那還有什麼意義呢？
每天殺小東西有什麼意義？
是。
如果他們破壞了某些東西，您會立即看到它。 你有一個小部件損壞了某些東西，你更容易修復它。 關鍵是現在合併一小部分比幾週後合併大部分要容易得多。 第三點是其他工程師將使用目前版本的程式碼。 他們會看到這裡添加了一些遷移，然後出現了一些他們可能也想使用的方法。 每個人都會看到您的程式碼中發生了什麼。 修行就是為了這三件事。
謝謝，問題已關閉！
（奧列格·索羅卡）我可以補充一下嗎？ 你說的都對，我只是想補充一句話。
Так。
透過持續集成，程式碼不會在功能完全準備好時合併到公共分支中，而是在建置停止中斷時合併到公共分支中。 而且您可以放心地每天根據需要多次進行掌握。 第二個方面是，如果因為某些原因你不能把每個月的任務分解成至少三天的任務，我沉默了大約三個小時，那麼你就有一個很大的問題。 沒有持續整合這一事實只是這些問題中最小的一個。 這意味著您在架構和零工程實踐方面存在問題。 因為即使這是研究，那麼無論如何也必須以假設或循環的形式來表達。
我們討論了區分成功公司和落後公司的 4 個指標。 我們仍然需要活著才能看到這 4 個指標。 如果你的平均任務需要一個月才能完成，那麼我會先專注在這個指標上。 我首先會把它減少到3天。 從那以後我開始考慮連續性。
我是否正確理解您的意思，您認為如果有任何任務需要一個月才能完成，那麼一般來說投資於工程實踐是沒有意義的？
你有持續集成。 並且有這樣一個主題，在 10 分鐘內你可以修復修復或回滾它。 想像一下你推出了它。 此外，您甚至可以進行持續部署，將其推出到產品中，然後才發現出現了問題。 並且您需要回滾它，但您已經遷移了資料庫。 你已經有了下一個版本的資料庫模式，而且，你還有某種備份，資料也寫在那裡。
你還有什麼選擇呢？ 如果回滾程式碼，則它無法再與此更新的資料庫一起使用。
基地只會向前移動，是的。
工程實務較差的人很可能也沒有讀過關於…的厚書。 備份後該怎麼辦？ 如果您從備份恢復，則表示您會遺失當時累積的資料。 例如，我們在新版本的資料庫上工作了三個小時，用戶在那裡註冊。 您拒絕舊的備份，因為該方案不適用於新版本，因此您失去了這些使用者。 他們發誓，他們不滿意。
為了掌握支援持續整合和持續交付的全方位實踐，僅僅學習如何編寫是不夠的... 首先，它們可能有很多，這是不切實際的。 另外還有許多其他實踐，例如科學實踐。 有這樣一種做法，GitHub一度普及了它。 這是當舊程式碼和新程式碼同時運行時的情況。 這是當你製作一個未完成的功能時，但它可以傳回一些值：作為函數或作為 Rest API。 您執行新程式碼和舊程式碼，並比較它們之間的差異。 如果存在差異，則記錄此事件。 這樣，如果在一段時間內兩者之間沒有差異，您就知道您已經準備好在舊功能之上推出一項新功能。
這樣的做法有數百種。 我建議從 transbase 開發開始。 她並不是100%堅持持續集成，但做法是一樣的，缺一不可。
您是否以 transbase 開發為例，您可以在其中看到實踐，或者您是否建議人們開始使用 transbase 開發？
看看吧，因為他們將無法使用它。 為了使用它們，您需要大量閱讀。 而當一個人問：“一個需要一個月的功能要做什麼時，就表示他還沒有讀過有關 transbase 開發的內容。” 我現在還不推薦它。 我建議只專注於如何在架構上正確地將大型任務分解為較小的任務的主題。 這就是分解的本質。
分解是架構師的工具之一。 我們先進行分析，然後分解，然後再綜合，然後再積分。 這就是我們一切順利的方式。 而我們仍然需要透過分解成長為持續整合。 第一階段就出現了問題，我們已經在講第四階段了，也就是整合的次數越多越好。 現在做這件事還為時過早；最好先砍掉你的龐然大物。
您需要在某些圖表上繪製多個箭頭和正方形。 你不能說現在我展示一個新應用程式的架構圖，展示一個正方形，裡面有一個應用程式的綠色按鈕。 無論如何，都會有更多的方塊和箭頭。 我看到的每張圖表都有不只一個。 即使在圖形表示的層面上，分解也已經在發生。 因此，可以使正方形獨立。 如果沒有，那麼我有一個很大的問題想問建築師。
聊天中有一個問題：“如果審核是強制性的，並且需要很長時間，也許一天或更長時間？”
你的練習有問題。 審查不應持續一天或更長時間。 這與上一個問題是同一個故事，只是稍微溫和一點。 如果審查持續一天，那麼很可能這次審查正在發生一些非常大的變化。 這意味著它需要變得更小。 在Oleg推薦的transbase開發中，有一個故事叫做持續審查。 她的想法是，我們故意提出這麼小的拉取請求，因為我們努力不斷合併，一次一點點。 因此，拉取請求更改了一個抽像或 10 行。 感謝這篇評論，我們花了幾分鐘的時間。
如果審核需要一天或更長時間，則表示有問題。 首先，您可能會遇到一些架構問題。 或者這是一大段程式碼，例如 1 行。 或者你的架構太複雜以至於人們無法理解它。 這是有點偏向的問題，但也是必須解決的。 也許根本不需要審查。 我們也需要思考這一點。 回顧是讓你放慢腳步的事情。 一般來說，它有其優點，但您需要了解為什麼要這樣做。 這是你快速傳達訊息的一種方式，這是你內部設定一些標準的方式還是什麼？ 為什麼需要這個？ 因為審核要嘛需要非常快地完成，要嘛完全取消。 這就像跨資料庫開發——故事非常美麗，但只適合成熟的男人。
關於這 4 個指標，我仍然建議刪除它們以了解這會導致什麼。 看看數字，看看圖片，一切都是多麼糟糕。
（德米特里）我準備好與你討論這個問題。 數字和指標都很棒，實踐也很棒。 但你需要了解業務是否需要它。 有些企業不需要這種變化速度。 我知道有些公司不可能每 15 分鐘就進行一次更改。 並不是因為他們太糟糕了。 這就是這樣一個生命週期。 而要製作分支功能、切換功能，您需要深厚的知識。
情況很複雜。 如果您想更詳細地閱讀有關切換功能的故事，我強烈推薦它 。 Martin Fowler 有一篇關於切換功能的精彩文章：有哪些類型、生命週期等。切換功能很複雜。
你還沒有回答這個問題：“到底需要不需要 Jenkins？”
無論如何，其實都不需要詹金斯。 不過說真的，工具：Jenkins、Gitlab 會為你帶來方便。 您將看到組件已組裝或未組裝。 他們可以幫助你，但不會給你練習。 他們只能給你一個圓圈——好的，不行。 然後，如果你還寫測試，因為如果沒有測試，那麼它幾乎毫無意義。 所以需要它，因為它比較方便，但一般來說沒有它也可以生活，不會損失太多。
也就是說，如果你有練習，是否代表你不需要它？
這是正確的。 我推薦 Jez Humble 測試。 我對最後一點持矛盾的態度。 但總的來說，如果你有三件事，你不斷合併，你在 master 中的提交上運行測試，你快速修復 master 中的構建，那麼也許你不需要任何其他東西。
當我們等待參與者提問時，我有一個問題。 我們剛才討論的是產品代碼。 您是否將其用於基礎設施代碼？ 是相同的程式碼，相同的原理和相同的生命週期，還是有不同的生命週期和原理？ 通常，當每個人談論持續整合和開發時，每個人都會忘記還有基礎設施代碼。 而且最近這樣的事情越來越多。 所有這些規則都應該帶到那裡嗎？
即使不應該如此，但它會很棒，因為它會以同樣的方式讓生活變得更輕鬆。 一旦我們使用程式碼，而不是 bash 腳本，但我們有正常的程式碼。
停止，停止，bash 腳本也是程式碼。 別碰我的舊愛。
好吧，我不會踐踏你的記憶。 我個人不喜歡 bash。 它總是醜陋而可怕。 而且它經常會出乎意料地損壞，這就是我不喜歡它的原因。 但好吧，假設您有 bash 程式碼。 也許我真的不明白，那裡有正常的測試框架。 我只是不知道。 我們得到同樣的好處。
一旦我們使用基礎設施即程式碼，我們就會遇到與開發人員相同的問題。 幾個月前，我遇到了一個情況，一位同事向我發送了 bash 中 1 行的 Pull 請求。 然後你就在評審中閒逛了 000 個小時。 同樣的問題也會出現。 依然是代碼。 而且這仍然是一次合作。 例如，我們被拉取請求所困擾，我們被我們正在同一個 bash 中解決相同合併衝突的事實所困擾。
我現在正在非常積極地關注最美麗的基礎設施編程的整個事情。 我現在已將 Pulumi 引入基礎設施。 這是最純粹的程式設計。 在那裡它甚至更好，因為我擁有程式語言的所有功能，也就是說，我用相同的 if 突然做出了漂亮的切換，一切都很好。 也就是說，我的改變已經在master了。 每個人都已經可以看到他了。 其他工程師也知道這一點。 它已經影響了那裡的一些事情。 但是，並非所有基礎設施都啟用它。 例如，它在我的測試台上打開。 因此，再次回答你的問題，是有必要的。 同樣，作為處理程式碼的工程師，它讓我們的生活變得更輕鬆。
如果還有人有疑問嗎？
我有個問題。 我想繼續和奧列格討論。 總的來說，我認為你是對的，如果一項任務需要一個月才能完成，那麼你的架構就有問題，你的分析、分解、規劃等就有問題。但我有一種感覺，如果你開始嘗試按照持續整合進行即時部署，那麼您將開始透過規劃來糾正痛苦，因為您在其他任何地方都無法擺脫它。
（奧列格）是的，沒錯。 這種做法的努力程度可與任何其他嚴肅的文化變革實踐相媲美。 最難克服的是習慣，尤其是壞習慣。 如果為了實施這種做法，需要嚴重改變周圍的人的習慣：開發人員、管理人員、生產經理，那麼驚喜就在等著您。
還能有什麼驚喜呢？ 假設您決定更頻繁地進行整合。 還有一些其他與整合相關的東西，例如工件。 例如，在您的公司中，有一項政策，即每個工件都必須在某種工件儲存系統中以某種方式進行說明。 這需要一些時間。 一個人需要選中他作為發布經理已測試此工件的複選框，以確保它已準備好在生產中發布。 如果需要 5-10-15 分鐘，但您每週進行一次佈局，那麼每週一次花費半小時就是一筆小稅。
如果每天進行10次持續集成，那麼10次需要乘以30分鐘。 這超出了該發布經理的工作時間。 他只是厭倦了這樣做。 某些做法有固定成本。 就這樣。
並且您需要取消此規則，以便您不再做這樣的垃圾，即您不會手動分配與某些內容相對應的學位。 您完全依賴一些自動化的準備測試集。
如果你需要某人的證明，以便老闆簽字，並且在沒有 Vasya 說他允許的情況下你就不能投入生產，等等 - 所有這些廢話都會妨礙從業者。 因為如果有一些活動與稅收相關，那麼一切都會增加 100 倍。 因此，這種轉變往往不會受到所有人的歡迎。 因為人的習慣是很難改變的。
當一個人做平常的工作時，他幾乎是不假思索地做的。 她的認知負荷為零。 他只是擺弄它，他腦子裡已經有了一個清單，他已經做了一千次了。 一旦你過來告訴他：“讓我們取消這種做法，從週一開始引入一種新的做法”，對他來說，這就變成了一種強大的認知負擔。 它同時降臨到每個人身上。
因此，最簡單的事情，雖然不是每個人都能負擔得起這種奢侈，但這就是我一直在做的事情，這就是下面的。 如果一個新專案開始，那麼通常所有未經測試的實踐都會立即塞入該專案。 雖然這個項目還很年輕，但我們並沒有真正冒任何風險。 還沒有 Prod，沒有什麼可以銷毀的。 因此，可以作為訓練。 這種方法有效。 但並非所有公司都有機會經常啟動此類專案。 雖然這也有點奇怪，因為現在已經有了徹底的數位轉型，每個人都必須展開實驗，才能跟上競爭對手。
在這裡你得出的結論是，你必須先了解你需要做什麼。 世界並不理想，產品也不理想。
是的，這些事情是相互關聯的。
企業也不總是明白他們需要走這條路。
存在著一種根本不可能改變的情況。 這是球隊壓力更大的情況。 團隊已經很疲憊了。 她沒有空閒時間做任何實驗。 他們從早到晚都在開發功能。 而且管理功能也越來越少。 需要的越來越多。 在這種情況下，根本不可能有任何改變。 團隊只能被告知明天我們會做和昨天一樣的事情，我們只是需要多做一點功能。 從這個意義上說，任何實踐的轉變都是不可能的。 這是一種典型的情況，當時沒有時間磨斧頭，需要砍伐樹木，所以他們用鈍斧頭砍樹。 這裡沒有簡單的提示。
（德米特里）我將宣讀聊天中的澄清：「但是我們需要不同程度的大量測試覆蓋率。 分配多少時間進行測試？ 有點貴，而且需要很多時間。”
（奧列格）這是一個典型的誤解。 應該有足夠的測試讓你有信心。 持續整合並不是先完成 100% 的測試，然後才開始應用這種實踐。 持續整合減少了您的認知負擔，因為您親眼看到的每個變化都非常明顯，即使沒有測試，您也知道它是否會破壞某些東西。 您可以在腦海中快速測試這一點，因為變化很小。 即使您只有手動測試人員，對他們來說也更容易。 你翻了個身，說：“你看，有什麼東西壞了嗎？” 他們檢查後說：“沒有，沒有任何損壞。” 因為測試人員知道該往哪裡看。 您有與一段程式碼關聯的一次提交。 這是被特定行為所利用的。
當然，這裡有你的點綴。
（德米特里）我不同意這一點。 有一種實踐——測試驅動開發，可以幫助你避免這種情況。
（奧列格）嗯，我還沒講到這一點。 第一個幻想是您需要編寫 100% 的測試，或者根本不需要進行持續整合。 這不是真的。 這是兩種並行的做法。 而且他們並不直接依賴。 您的測試覆蓋率應該是最佳的。 最佳 - 這意味著您自己對提交後您的 master 所保持的 master 品質充滿信心，讓您可以在醉酒的周五晚上自信地按下「部署」按鈕。 你如何實現這個目標？ 透過審查、透過覆蓋、透過良好的監控。
良好的監控與測試沒有什麼不同。 如果您在預生產上執行一次測試，那麼他們會檢查您所有的使用者腳本一次，僅此而已。 如果您以無限循環運行它們，那麼這就是您部署的監控系統，它會無休止地測試所有內容 - 無論是否崩潰。 在這種情況下，唯一的區別是執行一次還是兩次。 一組非常好的測試……無休止地運行，這就是監控。 正確的監控應該是這樣的。
因此，當你在周五晚上準備好回家時，你究竟如何達到這種狀態是另一個問題。 也許你只是個大膽的渣男。
讓我們回顧一下持續整合。 我們採取了一種稍微不同的複雜做法。
他們說，第二個幻想是 MVP 需要快速完成，因此根本不需要測試。 不一定是這樣。 事實是，當你在 MVP 中編寫使用者故事時，你可以在球上開發它，也就是說，你聽說有某種使用者故事並立即跑去編寫它，或者你可以使用 TDD 進行工作。 根據 TDD，實踐表明，它不需要更長的時間，即測試是一種副作用。 TDD 的實踐與測試無關。 儘管有所謂的測試驅動開發，但它根本與測試無關。 這也是一種架構方法。 這是一種準確地編寫需要的內容而不編寫不需要的內容的方法。 這是一種專注於您在創建應用程式架構方面的下一次思維迭代的實踐。
所以，想要擺脫這些幻想並不是那麼容易的事。 MVP 和測驗並不矛盾。 甚至相反，如果你使用 TDD 練習來獲得 MVP，那麼你會比完全不練習而是在球上做的更好更快。
這是一個非常不明顯且複雜的想法。 當你聽到現在我會寫更多測試，同時我會更快做一些事情時，這聽起來絕對不夠。
（德米特里）這裡很多人，當他們稱呼 MVP 時，人們懶得寫一些正常的東西。 這些仍然是不同的事情。 沒必要把MVP變成一些不起作用的壞東西。
是的，是的，你說得對。
然後突然獲得產品 MVP。
永遠。
當您聽說您編寫測試並且似乎做了更多工作時，TDD 聽起來很不尋常。 聽起來很奇怪，但事實上，這樣速度更快、更漂亮。 當您編寫測試時，您已經在腦海中思考了很多關於將調用什麼程式碼、如何呼叫以及我們期望它產生什麼行為。 你不只是說我寫了一些函數並且它做了一些事情。 起初你以為她有這樣那樣的條件，就會以這樣那樣的方式來召喚她。 您可以透過測試來覆寫這一點，並從中了解您的介面在程式碼中的外觀。 這對建築有巨大的影響。 您的程式碼自動變得更加模組化，因為您首先嘗試了解如何測試它，然後才編寫它。
TDD 發生在我身上的事情是，當我還是 Ruby 程式設計師時，我在某個時候聘請了一位 Ruby 導師。 他說：“讓我們按照 TDD 來做吧。” 我想：“該死，現在我必須額外寫點東西了。” 我們同意在兩週內我將使用 TDD 用 Python 編寫所有工作程式碼。 兩週後，我意識到我不想回去。 經過兩週的嘗試將這一點應用到任何地方之後，您會意識到，即使只是思考，也變得多麼容易。 但這並不明顯，所以我建議大家，如果你覺得TDD很難、耗時、沒必要，試著堅持兩週。 兩個對我來說就夠了。
（德米特里）我們可以從基礎設施運作的角度來拓展這個想法。 在我們推出任何新產品之前，我們會進行監控，然後再推出。 在這種情況下，監控就成為我們的常態測試。 透過監控才能發展。 但幾乎所有人都說很長，我很懶，我臨時寫了一個草稿。 如果我們做了正常的監控，我們就了解CI系統的狀態。 而且CI系統有很多監控。 我們了解系統的狀態，我們了解其中的內容。 在開發過程中，我們只是製作系統，使其達到所需的狀態。
這些做法早已為人所知。 我們大約 4 年前討論過這個問題。 但四年來，幾乎沒有任何改變。
但就此而言，我建議結束正式討論。
影片（作為媒體元素插入，但由於某種原因不起作用）：
來源： www.habr.com