嵌入式最大的趨勢之一是采用和改進持續集成/持續部署（CI/CD）實踐。CI/CD背后的思想是團隊需要盡可能多地自動化他們的嵌入式開發過程。

今天的嵌入式系統對于人工工作來說已經變得過于復雜和精密。當然，你無法擺脫它，但是在開發周期中有太多可以自動化的東西。如果利用得當，自動化可以簡化開發、降低成本和縮短上市時間。

在今天的文章中，我們將探討三種簡單的方法來幫助你開始使用嵌入式軟件的CI/CD。

 

技巧1：量化價值

開始你的CI/CD之旅時，先量化開始這項工作需要花費的時間和成本，然后再量化它將帶來的好處。例如，你可能會考慮實施成本，例如：

每個用戶的工具成本

每位用戶的培訓成本

管道設計和安裝成本

每年的維護成本

每個用戶的時間投資

 

一旦你了解成本，你必須問自己：你有投資CI/CD開發的預算嗎？你的團隊是否有足夠的資源來實施新流程、接受培訓等？

 

然而，上述問題并不能讓你了解全貌。你還需要量化收益，例如：

在bug到達客戶手中之前將其捕獲

利用TDD和模擬等現代技術

通過利用自動化和提高產品質量來降低成本和縮短上市時間

 

如果你預先花一些時間分析你從CI/CD中獲得的收益與成本，你會發現它提供了很好的投資回報。

 

技巧2：構建自動化

開始使用CI/CD最簡單和最容易的方法是讓你的軟件自動構建。構建自動化是關鍵的第一步。它為你提供了設置可重用構建環境和腳本來控制管道的經驗。

可重用的構建環境通常是使用Docker之類的容器工具來實現的。Docker允許你打包構建軟件所需的環境和工具。該容器可用于在服務器上構建你的軟件，但開發人員也可以在開發過程中使用它來構建軟件！

 

由于開發人員在他們的計算機上有不同的構建環境，bug突然出現并不罕見。容器有助于確保每個人在完全相同的環境中使用完全相同的工具。這包括你剛剛起步的CI/CD渠道！

相同的環境非常重要，因為當你在CI/CD管道中運行一個作業來構建最新的固件時，服務器上的環境應該與你開發代碼的環境相同。否則，管道可能會說你的代碼無法構建，而實際上，這可能只是一個服務器配置問題。

 

構建自動化是很好的第一步，因為它允許你和團隊驗證你最近的提交實際上構建成功了。你可能會想，誰會提交不起作用的代碼呢？它確實發生了。對看起來很好的代碼做一點小小的調整，卻發現它無法構建，這種情況并不罕見。

 

技巧3：自動化代碼度量報告

一旦有了可以在服務器上構建固件的容器，下一步就是自動化代碼度量報告。分析源代碼中的問題有很大的價值。它幫助你跟蹤你的進度，以及許多問題，這些問題通常不會被發現，除非進行手工代碼審查。

 

例如，每個團隊都努力遵循一個編碼標準，這樣所有的代碼看起來都一樣。我們創建編碼風格指南和各種其他流程。然而，開發人員偏離這些風格的頻率有多高？一直都是！審查每一行代碼并確保它符合標準的工作量太大了。這就是自動化的用武之地！

 

你可以設置管道，以便對軟件進行分析。分析可以有很大的不同，比如這些內容：

堅持編碼風格

功能復雜性

連接

內聚力

代碼行

代碼覆蓋率

等等。

 

這個清單可以一直列下去。然后可以使用代碼度量的報告來發現開發代碼中的問題。大多數團隊忽略了基本的軟件度量。不幸的是，這使得團隊對潛在的問題和他們積累的技術債務視而不見。如果你盡早將報告構建到你的管道中，它將為你提供及早發現問題并在變革成本仍然較低時修復它們所必需的洞察力。

 

結論

CI/CD是一種現代技術，幾乎每個嵌入式軟件團隊都應該采用。如今，工具的存在使得采用變得非常經濟。事實上，它非常容易上手，并且不需要花費大量的時間和金錢來建立一個基本的管道。

正如我們所討論的，最好的開始方式是首先建立一個容器構建系統。然后，你將能夠在管道中設置一個構建作業，以驗證代碼至少編譯成功。此后，分析你的軟件的度量、靜態分析等等就沒有更多的工作了。

從那里，你會發現你已經對你的開發過程有了很多的可視性。自動化有助于確保你可以繼續獲得洞察力，而無需團隊付出太多努力。

這兩個首要的技巧可以幫助你形成一個基線CI/CD過程，為你的團隊和客戶提供大量的價值，并且可以擴展到更復雜的自動化形式。