今天，許多嵌入式開發人員和團隊正在解決的一個問題是如何管理他們的CI/CD管道。持續集成(CI)很有意義，因為它專注于構建、測試和驗證嵌入式軟件。但是持續部署(CD)呢？

 

一開始持續部署嵌入式軟件聽起來很棒，但是你真的想持續向你的客戶部署新軟件嗎？如果你正在構建汽車電子控制單元(ECU)、醫療設備，甚至微波爐或家用電器，你的客戶真的希望頻繁更新嗎？

 

這引發一個有趣的問題：嵌入式產品的持續交付有意義嗎？

 

持續部署的目的

CD是一種軟件開發實踐，其中代碼更改被自動構建、測試并部署到生產中，而無需人工干預。這種方法擴展到了CI之外，在CI中，更改會被自動測試，但不一定會被部署。CD為團隊提供了諸多好處，例如：

l 加速上市時間

l 一致可靠的部署

l 更快的反饋循環

對于軟件行業的許多人來說，持續部署已經改變了游戲規則，例如對于移動和web應用程序。當然，在嵌入式產品中，持續交付很有意義，但是那些只想每季度或每年提供更新的系統怎么辦？

 

嵌入式中的持續交付應該是什么樣的？

連續交付通常被視為向客戶交付新軟件。你可能會把顧客看作是在現場購買和使用你的產品的人。然而，這可能是對客戶的狹隘看法。內部人員或團隊經常使用你創建的軟件工件，并使用它們來驗證產品是否工作，是否滿足整體的項目目標和需求。如果你將這些隊友視為你軟件的客戶，那么持續交付和你如何定義你的管道可能會改變。

 

例如，作為一個軟件團隊，你可能會定義一個類似于下面圖1的連續交付管道：

在這個管道中，你可以看到我們定義了幾個作業。如果CI渠道成功，我們將有一個創建最終交付包的包作業，然后有一個將所有材料集中在一起進行發布的發布作業。從那里，我們有一個體現持續部署的生產開發工作。生產開發作業將被部署到一個內部測試平臺，開發人員可以用它來驗證構建。

從那里，發布可以由質量保證團隊批準。一旦通過審批流程，分階段發布可能會進入現場生產。它們也可能是對每季度或每年在現場推出的更大版本的逐步驗證。

 

結論 

對于嵌入式軟件開發人員和團隊來說，持續交付是一個必不可少的工具。雖然向客戶部署新軟件的傳統方法可能沒有意義，但是部署到生產測試環境中就有意義了。生產測試環境允許開發人員和質量保證人員在向客戶推出新固件之前驗證一切正常。雖然這可能不完全符合持續交付的精神，但它非常適合許多嵌入式產品團隊。那么，持續交付對于嵌入式產品有意義嗎？

 

我想我們可以肯定地說，確實如此；這取決于我們的“持續”時間框架，以及這些版本是部署給內部客戶還是外部客戶。持續部署有很多好處；即使你沒有自動將新固件推送到現場，它仍然可以在內部進行驗證。