嵌入式Linux開發模型與Jenkins

Question

我是一個從事嵌入式Linux項目的小團隊（4-5人）的一員。 我們正在使用Buildroot和Linaro工具鏈為我們的目標構建。 我們使用git進行版本控制，使用Jenkins進行夜間構建。

這是我們第一次參加這樣的項目，而且我找不到任何用這種環境描述開發模型的資源是不成功的。

現在在每晚構建之后，我創建了一個Buildroot'output'目錄的tarball，其中包含u-boot映像和根文件系統。 這可以直接從Jenkins'archive'頁面下載，以便上次成功構建。

我們中的一些人將致力於低級開發，一些用於用戶空間開發（QT）。 我們的問題是決定什么是最有效/簡化的方法是在這樣的環境中開發，因為人們將在項目范圍內的不同領域開展工作。 用戶專家可以下載所有內容的tarball並將他們的應用程序合並到rfs中以在板上運行並進行調試，但是我們應該如何處理在較低級別開發上完成的工作？ 基本上，我們應該如何將工件分發給團隊？ 我非常感謝任何想法。

Answer 1

我最近花了一些時間來重構基於OpenEmbedded的linux項目的構建環境。 我沒有使用Buildroot的直接經驗，但我希望OpenEmbedded與你正在使用的相似。 我將描述我的設置，如果運氣好，你會發現這里有用的東西......

問題

有三個軟件組件可以單獨安裝（即彼此獨立）：引導加載程序（u-boot）; 內核（linux）; 和文件系統映像。 我們的最終產品隨附這三個組件的打包版本。 也就是說，u-boot，linux和文件系統映像的一個版本經過QA測試並且已知可以協同工作。 但是，可以獨立升級任何一個組件（例如，安裝新的內核映像）以創建未經過一起測試的軟件組件的組合。

用戶空間應用程序也存在此問題。 一旦將文件系統映像安裝到目標中，就可以獨立於其他文件系統對象更新一個或多個用戶空間二進制文件（假設您的文件系統不是只讀的）。 您如何知道現在安裝的用戶空間應用程序的特定組合可以一起工作？ 我怎樣才能確定在這個特定單元中運行的二進制文件的組合是否經過QA認證的二進制文件的組合？ 我怎么知道軟件的“版本”是什么？

我需要解決的另一個問題，就是你在問題中提出的同樣問題，是如何允許開發人員在軟件堆棧的不同部分（內核，根文件系統，用戶空間Qt應用程序等）一起工作？

一個辦法

我通過以下方式解決了這個問題和“版本”問題：

1. 將rootfs和sysroot存儲在git存儲庫中。
2. 自由使用git子模塊。

將目標的根文件系統和系統根文件存儲在git存儲庫中最初是以錯誤的方式（在版本控制中存儲輸出文件，什么！？！）但是它提供了以下優點：

1. 只要構建用戶空間應用程序（即數十秒），就可以構建JFFS2文件系統映像（rootfs +我們的自定義用戶空間應用程序）。 不再需要開發人員首先從頭開始構建rootfs（使用OpenEmbedded需要幾個小時）。
2. 版本控制的所有其他優點（rootfs的更改可以隨着時間的推移輕松跟蹤，標簽用於發布，分支等）。
3. 我最初考慮將rootfs和sysroot存儲為tarball，但我喜歡基於每個文件的git跟蹤更改的想法。

目錄結構看起來像這樣（一些名稱已被更改以保護無辜者）：

\---proj [*]             # Name of your project
    +---u-boot [*]
    +---linux [*]
    +---toolchain [*]
    \---fs [*]           # Filesystem stuff.
        +---oe [*]       # OpenEmbedded.
        +---qt [*]       # Qt framework.
        +---apps [*]     # Custom user-space applications.
        \---bin [*]      # Revision controlled binaries
            +---rootfs   # Target root filesystem, output of OpenEmbedded.
            \---sysroot  # System root, output of OpenEmbedded (headers, etc).

每個星號目錄[*]都是一個git存儲庫，每個git存儲庫都是其父級的子模塊。

構建環境是從頂級Makefile初始化的，它基本上執行遞歸git submodule init和git submodule update 。 所有開發人員都會：

$ git clone git@your.url:proj proj
$ cd proj
$ make git-init

然后，用戶空間開發人員可以立即構建：

$ make --directory proj/fs/apps all       # Build apps
$ make --directory proj/fs install        # Create JFFS2 image

文件系統維護者可以更新rootfs：

$ cd proj/fs/oe
$ # Modify build recipes and other OpenEmbedded black magic stuff.
$ make
$ # Go make coffee while oe builds every package on the planet.
$ cd proj/bin    # OE writes output files here.
$ git commit     # Commit latest rootfs and sysroot.

軟件版本控制

從頂級makefile（ proj/Makefile ）可以構建所有軟件組件（內核，u-boot，文件系統映像）。 使用以下git命令，makefile向所有子make進程VER_TAG描述當前軟件版本的單個環境變量（例如VER_TAG ）。 的版本是無論是從git倉庫或SHA一個標簽（例如v1.0 ， 471087ec254e8e353bb46c533823fc4ece3485b4或471087ec254e8e353bb46c533823fc4ece3485b4-modified ）。

git rev-parse HEAD                 # Get current SHA
git status --porcelain | wc -c     # Is working copy modified?
git describe --exact-match HEAD    # Is the working copy a tag?

如果甚至修改了任何項目子目錄中的單個文件，那么VER_TAG將始終是xxxx-modified 。 然后，將單個VER_TAG變量作為編譯VER_TAG量傳遞給所有構建（u-boot，內核，用戶空間應用程序等）。

在運行時，自定義用戶空間應用程序會累積所有組件的VER_TAG值，如果它們都報告相同的值，則該字符串將成為產品報告的正式版本。 如果即使一個VER_TAG值與其他VER_TAG值不同，那么軟件堆棧也不是從相同的頂級SHA構建的，並且不能被釋放到野外（用於QA以進行測試，生產用於制造等）。

如果軟件組件不是從頂級makefile構建的（例如make --directory proj/fs/apps all ），那么該組件的VER_TAG將是未定義的，並且生成的軟件堆棧僅用於“內部使用”。 也就是說，只能通過從頂級makefile構建來“釋放”所有軟件組件。

作為參考，linux通過procfs中的自定義文件報告VER_TAG ，通過linux命令行（ /proc/cmdline ）報告u-boot報告，並通過進程間通信報告每個用戶空間應用程序。

摘要

一個警告。 我只在一個月前開發了這個構建環境，所以不能聲稱它的穩健性，但是現在它似乎在一起......

如果您有特定的問題或要點，請澄清我很樂意更新我的答案。