基于Jenkins的嵌入式Linux开发模型

我是一个小型团队（4-5人）的成员，该团队致力于一个嵌入式linux项目。我们正在使用Buildroot和Linaro工具链为我们的目标进行构建。我们使用git进行版本控制，使用Jenkins进行夜间构建

这是我们第一次尝试这样的项目，我没有找到任何描述这种环境下开发模型的资源

现在，在夜间构建之后，我创建了Buildroot“output”目录的tarball，其中包含u-boot映像和根文件系统。这可以直接从Jenkins'archive'页面下载，用于上一次成功构建

---

我们中的一些人将致力于较低级别的开发，另一些人将致力于用户空间开发（QT）。我们的问题是，考虑到人们将在项目范围内的不同领域工作，决定在这样的环境中开发最有效/优化的方法是什么。userland的家伙可以下载tarball和所有东西，并将他们的应用程序合并到rfs中，以便在板上运行和调试，但是我们应该如何处理在较低级别开发上完成的工作呢？基本上，我们应该如何将工件分发给团队？我非常感激你的任何想法

我最近花了一些时间为一个基于OpenEmbedded的linux项目重新构建构建环境。我没有Buildroot的直接经验，但我希望OpenEmbedded与您使用的非常相似。我会描述我的设置，如果幸运的话，你会在这里发现一些有用的东西

问题 有三个软件组件可以单独安装（即相互独立）：引导加载程序（u-boot）；内核（linux）；和文件系统映像。我们的最终产品附带了这三个组件的打包版本。也就是说，u-boot、linux和文件系统映像的一个版本已经过QA测试，并且已知可以协同工作。但是，可以独立升级任何一个组件（例如，安装新的内核映像），以创建未一起测试的软件组件组合

用户空间应用程序也存在此问题。一旦将文件系统映像安装到目标中，就可以独立于其他文件系统对象更新一个或多个用户空间二进制文件（假设文件系统不是只读的）。您如何知道现在安装的用户空间应用程序的特定组合可以协同工作？我如何确定在这个特定单元中运行的二进制文件的组合与经过QA认证的二进制文件的组合相同？如何知道软件的“版本”

我需要解决的另一个问题，与您在问题中概述的问题相同，是如何允许开发人员在软件堆栈的不同部分（内核、根文件系统、用户空间Qt应用程序等）上协同工作

解决办法 我通过以下方式解决了此问题和“版本”问题：

将rootfs和sysroot存储在git存储库中

git子模块的自由使用

在git存储库中存储目标的根文件系统和系统根文件一开始让我感觉不对劲（在版本控制中存储输出文件，什么！？！），但它提供了以下优点：

JFFS2文件系统映像（rootfs+我们的自定义用户空间应用程序）可以构建，只要构建用户空间应用程序（即数十秒）。开发人员不再需要从头开始构建rootfs（使用OpenEmbedded需要几个小时）

版本控制的所有其他优点（rootfs的更改可以随时间轻松跟踪，发布标签，分支等）

我最初考虑将rootfs和sysroot存储为tarball，但我喜欢git基于每个文件跟踪更改的想法

目录结构如下所示（一些名称已更改以保护无辜者）：

每个带星号的目录[*]都是git存储库，每个git存储库都是其父目录的子模块

构建环境是从顶级Makefile初始化的，该Makefile基本上执行递归的

git子模块init

和

git子模块更新

。所有开发者都会做：

$ 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\u TAG

）。该版本要么是来自git存储库的标签，要么是SHA（例如，

v1.0

，

471087ec254e8e353bb46c533823fc4ece3485b4

或

471087EC254E8E353BB46C533823FC4ECE33485B4已修改

）

如果任何项目子目录中的单个文件都已修改，则

VER\u TAG

将始终被

xxxx修改

。然后，这个

VER\u标记
变量作为编译时常量传递给所有构建（u-boot、内核、用户空间应用程序等）

在运行时，自定义用户空间应用程序累积来自所有组件的
VER\u标记
值，如果它们都报告相同的值，则该字符串将成为产品报告的正式版本。如果哪怕一个
VER_TAG
值与其他值不同，那么软件堆栈也不是从同一个顶级SHA构建的，不能发布到野外（用于测试的QA、用于制造的生产等）

如果软件组件不是从顶级makefile（例如，
make--directory proj/fs/apps all
）生成的，则该组件的
VER\u标记将被取消定义，并且生成的“internal”软件堆栈
$ 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.

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?