「本地持續集成系統」可能不是正確的術語，但我希望找到的是一個持續集成系統，可以配置爲監視對本地文件（特別是C++文件）的更改，並且1）嘗試編譯受影響的目標文件（在第一次失敗時停止），並且如果成功並且沒有新的源文件更改2）鏈接受影響的二進制文件，如果成功並且沒有新的源文件更改3）運行受影響的測試。用於C++的本地持續集成系統？
通過監視器對本地文件的更改，我不是指監視器向修訂控制系統提交，而是保存本地文件的狀態。理想情況下，系統將提供到源編輯器的集成，以便它可以監視編輯器中尚未保存到磁盤的更改。
理想情況下，它還會提供當前和最近狀態的圖形指示（最好在Windows 7上），以便在需要時快速鑽入故障。
我發現的最接近的東西是nose，如here所述，但只涵蓋運行Python測試而不構建C++文件。
最接近你要找的是cdash和Boost test bench;我認爲像C++這樣的工具對於C++來說永遠不會存在，因爲在編輯單個文件之後編譯每個項目在高效的C++工作流程中只是浪費時間。
繼續整合今天是一個上升的概念，所以你並不孤單。
假設你正在開發Windows，如果您正在使用微軟的Visual Studio
工作，你可能會考慮微軟的Visual Studio Team Foundation Server (TFS)
（以前Visual Studio Team System）。
這會給你源代碼控制，在一個包構建的自動化，
以極大的整合，微軟的產品，當然
的（我認爲這是對MSDN用戶提供免費的版本）。
如果不是熱衷於微軟的產品，或只是爲了尋找構建自動化，
我會推薦一個偉大的開源繼續整合工具：
Jenkins CI。
祝你好運！
我會看Jenkins CI - 它是一個很好的工具，可以在任何平臺上工作，並且可以配置爲幾乎可以做任何事情。我用它來運行與移動電話交談的Python代碼，打電話並記錄這些電話（並測試了電話的「質量」，儘管我的項目從未獲得英鎊×××的真實質量軟件，因爲我們只是在展示一個概念），然後詹金斯會生成「它的工作效果如何」的圖表。
你也可以做你所描述的「鏈接」 - 所以它會發現你的源碼已經改變了，試圖建立它[通常這是使用make完成的，所以它會自動停止在第一個錯誤的文件（儘管它可能在一個文件中有數百個錯誤！）]。編譯並建立成功，然後鏈接到運行測試。不完全確定你如何確定什麼是「相關」。如果你的測試周期不是很大，我會把它們全部運行起來！
我贊成通過分享鬆散的相關鏈接來增加討論的內容，但我不同意這樣的評估：它永遠不會存在。我認爲在最近的變化情況下重新啓動建築應該是可行的。此外，我的目標是通過最小化開發人員（即我）需要等待構建完成的時間來爲開發人員交易機器時間。 –
將您的代碼庫拆分爲多個庫，這是在整個工作流程中花費更少時間的有效方法，請記住，您的每一次更改都會引入錯誤，並且您有一個單一的方法，您會後悔的。 – user1849534
從我的經驗來看，這種方法仍然沒有像Python或C＃一樣使用等待時間。當我最近回到一個Python代碼庫時，這個驚人的差異真的讓我感到震驚，這個代碼庫比我剛剛研究的C++代碼庫更大，我注意到花費更少的時間來解釋Python代碼並且在4次不同的時間運行測試（CPython，帶有2個不同標誌的IronPython和Jython），那麼只需構建一個較小的C++代碼庫即可完成一個平臺的調試配置。 –