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

Question

我是一个小团队(4-5人)中的一员，他们在一个嵌入式linux项目中工作。我们使用Buildroot和Linaro工具链来构建我们的目标。我们使用git进行版本控制，使用Jenkins进行夜间构建。

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

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

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

Answer 1

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

问题所在

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

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

我需要解决的另一个问题，也就是你在问题中概述的问题，是如何让开发人员在软件堆栈的不同部分(内核、根文件系统、用户空间Qt应用程序等)一起工作？

一种解决方案

我通过以下方式解决了这个问题和“版本”问题：

在git repository.

• Liberal中存储根文件系统和系统根目录的

1. 使用git子模块。

将目标的根文件系统和系统根文件存储在git存储库中最初让我很不爽(将输出文件存储在版本控制中，什么！？！)但它提供了以下优势：

1. JFFS2文件系统镜像(rootfs +我们的自定义用户空间应用程序)可以在构建用户空间应用程序所需的时间内构建(即数十秒)。开发人员不再需要首先从头开始构建rootfs (使用OpenEmbedded).
2. All需要几个小时，这具有版本控制的其他优点(随着时间的推移，可以很容易地跟踪对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会将描述当前软件版本的单个环境变量(例如VER_TAG)导出到所有子make进程。版本可以是来自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变量作为编译时常量传递给所有构建(u-boot、内核、用户空间应用程序等)。

在运行时，自定义用户空间应用程序累积来自所有组件的VER_TAG值，如果它们都报告相同的值，那么该字符串将成为产品报告的官方版本。如果一个SHA值与其他值不同，那么软件堆栈不是从相同的顶级VER_TAG构建的，并且不能发布到野外(用于测试的QA，用于生产的生产，等等)。

如果一个软件组件不是从顶层makefile (例如make --directory proj/fs/apps all)构建的，那么该组件的VER_TAG将是未定义的，并且所产生的软件堆栈仅供“内部使用”。也就是说，所有软件组件的“发布”只能通过从顶层makefile构建来实现。

作为参考，linux通过procfs中的自定义文件报告引导，通过linux命令行(/proc/cmdline)报告u- VER_TAG，通过进程间通信报告每个用户空间应用程序。

摘要

一个警告。我一个月前才开发了这个构建环境，所以不能声称它的健壮性，但现在它似乎在一起……

如果你有明确的问题或观点，我很乐意更新我的答案。