持續整合下的軟體開發/簡介

定義

首先，我們需要定義持續整合。維基百科給出了以下定義：

在軟體工程中，持續整合 (CI) 實施了持續的質量控制流程——頻繁地應用少量工作。持續整合的目標是透過在完成所有開發工作後應用質量控制的傳統做法，來提高軟體質量，並減少交付時間。

持續整合一詞最早出現在極限程式設計 (XP) 中。Martin Fowler 和 Kent Beck 大約在 1999 年撰寫了關於持續整合的文章。Fowler 的論文 是經常被引用的資訊來源之一。Beck 的著作《極限程式設計解釋》， 極端程式設計的原始參考文獻，也引入了這個術語。

維基百科中給出的工作定義很好，因為它有助於消除持續整合僅僅是整個圖景中的一項任務的錯誤觀念（即，當人們想到“持續整合”時，他們往往會想到持續整合構建，而不是整個流程）。持續整合是一個涵蓋軟體開發工作的流程，而不僅僅是整合和構建程式碼的行為。這一點非常重要，請注意！

受監管專案中的持續整合

如何將持續整合應用於軟體醫療裝置的嚴格監管領域？讓我從一個故事開始。

在監管環境中，例如 FDA 對軟體醫療裝置實施的監管，我們往往關注標準操作程式 (SOP)。這些 SOP 往往變得如此僵化，以至於束縛了我們的手腳，阻止了敏捷（小寫 a）軟體實施，併為官僚主義而引入了官僚主義。最終，那些花費了很長時間建立和（試圖）執行的標準操作程式變得如此繁瑣，以至於所有其他工作都變成了對萬能流程的次要關注。好訊息是，有人試圖思考流程（如果真有好的訊息的話）。壞訊息是，沒有人（包括作者）記得這些程式的確切內容。這就是所有軟體開發中採用智慧持續整合方法可以成為銀彈的地方。

我第一次參與軟體醫療裝置專案的經歷是在 2002 年。我之前的僱主，一家激動人心的網際網路泡沫時代的企業，未能提供我預期的數百萬美元。我當時還算是剛畢業不久，現實的衝擊讓我措手不及：那 10 萬股股票將一文不值，我還要再開幾年 1998 年的 Dodge Status 了。

面對我人生中第一次在失業隊伍中的屈辱經歷，我渴望接受第一個工作機會，很快我就發現自己在一個血液銀行專案中擔任軟體質量保證工作。我不確定是什麼讓我這個傲慢的年輕軟體開發人員更加屈辱：失業隊伍，還是被迫編寫測試指令碼。但那是一份工作，而且作為成千上萬正在尋找工作的軟體開發人員之一，我接受了這份工作。

在我新工作的第一天，我瞭解到了一些奇怪的事情：我們編寫的軟體將由 FDA 定義的一套標準進行稽核和控制。“FDA，”我問道，“是指食品藥品監督管理局嗎？”是的，就是那個 FDA。我被告知坐在我的隔間裡閱讀一個名為 CFR 的檔案，重點關注第 11 部分和第 820 部分。內容很長，很無聊，很奇怪，我感到很惱火。我一直在打哈欠，強迫自己閱讀。

我接下來的任務是閱讀一大堆標準操作程式 (SOP)。讀完一個 SOP 後，我會進行測試，回答關於 SOP 的幾個簡單問題。測試結果會被評分、簽字，並存放在某個地方的永久檔案中，作為我瞭解 SOP 的證明。在這一點上，我很快就忘記了 SOP 的內容。

我的工作很簡單。我需要審查用例，為這些用例編寫測試指令碼（手動和自動），並執行這些指令碼。完成一項任務後，我就會繼續進行下一項任務（這項任務就是我的老闆讓我做的任何事）。很快，我在入職前幾周閱讀過的 SOP 就成了遙遠的記憶。我沒有理由重溫它們。

但也許我應該重溫一下。還記得我簽署了一份測試，表明我閱讀並理解了 SOP 嗎？在我入職大約 6 個月後，專案開始進行內部審計。這次審計的目的是執行類似於 510k 實際 FDA 審計期間可能進行的活動。我被帶到一個房間，接受審計人員的詢問。

審計人員問我第一個問題，“所以 Matt，你做你的 were 時，你是怎麼知道該做什麼的？”

這個問題聽起來很奇怪，但我禮貌地回答道，“嗯，我想，我做我的老闆讓我做的一切。”

錯誤的答案。

審計人員繼續說道，“不，我的意思是，你怎麼知道你應該建立什麼？”

我開始有點坐立不安，“嗯，因為我的老闆告訴我該怎麼做……我閱讀用例和需求，並編寫測試。”

情況不太妙。

奇怪的詢問持續了很長一段時間，直到最後審計人員放棄，告訴我我可以回到我的隔間。在短暫的一段時間裡，我鬆了一口氣。然後，專案經理知道了我在詢問和回答時的口齒不清。

我有麻煩了。

我們是在談論標準操作程式還是持續整合？

持續整合就是過程

我是在談論兩者！持續整合不僅僅是貢獻到共享倉庫並確保軟體構建完整性。持續整合是一個流程，它會打造一個具有邏輯程式的協調一致的團隊。持續整合意味著團隊中的任何成員，從管理層到開發人員，都不能在真空中工作。工程高質量軟體的流程是一個涉及所有角色的流程，它需要的不僅僅是簡單地記憶曾經閱讀過的一些程式。這些程式是日常工作活動中不可或缺的一部分。更重要的是，這些程式是有意義的。