隔夜构建和发布之间的依赖关系 - 测试问题
这是一个发布构建过程问题，我需要为我们的软件团队解决。
我们正在开发基于几个通用库的嵌入式系统应用程序。我们还引入了连夜构建和自动软件测试，以便能够尽快追踪错误。应用程序和库是同时开发的。我们的开发处于BETA阶段，因此我们不会引入新功能，主要是纠正错误。
开发过程如下：当应用程序中的错误得到纠正后，夜间构建就完成了。这个隔夜构建采用最后发布的稳定库，编译应用程序并在硬件模块上进行 BlackBox 测试 - 结果可执行文件被提交到版本控制系统并具有唯一的构建版本。
有时会发生需要在库中纠正错误的情况。在这种情况下，会为库创建一个夜间构建。但我需要知道库中纠正的错误是否没有在应用程序中引起新的错误。在这种情况下，应用程序需要采用“不稳定”的构建库，进行编译、测试 - 结果是应用程序和库的可执行提交、uniq 构建版本。
有时我们需要从应用程序中为客户发布版本，但库仍然不稳定（它是一个构建版本）。在这种情况下，我们采用该库的最新发布版本。但是，如果前一天晚上库也得到纠正，我们的测试就在构建 APP、构建 LIB 配置上运行。所以配置构建APP、发布LIB没有测试。
总而言之，我们有以下可能性：
APP LIBRARY
build release
build build
release release
release build
但始终只有 1 个组合被编译，并通过我们的过夜构建进行测试。
我的问题是这样的情况该如何处理？从 1 个通宵构建开始，我只能获得 1 个独特的 SW 版本，但我想实际上知道其他组合是否有效？
有人可以建议改进我们的流程吗？还是我们做的事情完全错误？任何回应都非常受欢迎。谢谢。
问候 阿提拉
this is a release-build process question which I would need to solve for our SW Team.
We are developing embedded system applications that are based on several common libraries. We also introduced overnight builds and automatic SW testings in oder to be able to track down errors as soon as possible. The applications and libraries are developed simultaneously. Our development is in BETA phase so we don't introduces new features but mainly correct bugs.
The development is following: When a bug is corrected in an application then an overnight build is done. This overnight build takes the last released stable library, compiles the application and does BlackBox tests on a HW module - result executable is commited to versioning system and has an unique Build version.
Sometimes it happens that the bug needs to be corrected in the library. In such case an overnight build is created for the library. But I need to know if the bugs corrected in the library havent caused new bugs in the applications. In this case it is required that the application takes the "unstable" build library, does the compilation, tests - result is an executable commited, uniq build version for application and also library.
It can happen that we need to do a release for the customers from the application but the library is still not stable it is a build. In such case we take the last released version of the library. BUT if the night before the library was also corrected our tests ran on the build APP,build LIB configuration. So the configuration build APP, release LIB was not tested.
To sum up we have the following possibilities:
APP LIBRARY
build release
build build
release release
release build
But always only 1 combination is compiled, tested with our overnight build.
My question is how to handle such a situation? From 1 overnight build I can get only 1 unique SW version, but I would like to actually know weather also the other combinations has worked?
Could somebody suggest an improovement in our process or are we doing something completly wrong? Any responses are very welcome. Thank you.
greetings
Attila
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您是否有足够的系统资源来构建/测试所有 4 个？您不一定需要每天都这样做，只有在代码更改后才需要这样做。
Do you have sufficient system resources to build/test all 4? You don't necessarily need to do it daily, only after code changes.
每个源文件和库都受版本控制，当您进行新构建时，它是由您使用的每个源文件和库的版本定义的。例如，今晚的构建可能是 {App1_3.0、App2_3.2.5、...、Lib1_2.0、Lib2_2.1、...}。如果此构建通过了您的测试，您可能会认为您已经成功修复了 App2 中的错误，并声明 App2_3.2.5 稳定且受祝福。但是根本没有理由将构建检查到版本控制中。所需要做的就是记住其中包含哪些版本（版本号向量）以及构建是否通过了测试。 （您可能会发现自动化构建过程很有用，可以轻松地从这个“配方”重新创建旧的构建，如果您还没有这样做的话。）如果由于某种原因您想为此分配一个唯一的编号构建，有多种方法可以实现。
Each source file and library is under version control, and when you make a new build it is defined by which version of each you use. For example, tonight's build might be {App1_3.0, App2_3.2.5, ..., Lib1_2.0, Lib2_2.1, ...}. If this build passes your tests you may decide that you have succeeded in fixing a bug in, say, App2, and declare App2_3.2.5 stable and blessed. But there is no reason at all to check the build into version control. All that is necessary is that you remember which versions of things went into it (the vector of version numbers) and whether the build passed the tests. (You may find it useful to automate the build process to the point where it is easy to recreate an old build from this "recipe", if you haven't already.) If for some reason you want to assign a unique number to this build, there are several ways to do it.