问题标签 [release-management]

我正在处理的项目包括两个我称之为由其他团队开发的代码库。使用 TFS，我们只需将他们的 TFS 文件夹包含在我们的工作区中，并将他们的 Visual Studio 项目包含在我们的解决方案文件中。如果其他团队将文件签入到库中，我们将立即获得他们的更改。

显然，您可以看到这种安排的缺点（我们不知道何时有人会引入重大更改 - 他们也不知道）。

为了更好地隔离这些库的日常更改，我计划对库代码进行分支。我们计划将这些分支视为只读 - 我们永远不会进行自己的更改。

在某些时候，我们希望在每个库都处于稳定点时刷新这些分支。（大多数团队都在使用 SCRUM，所以这将是每个图书馆团队 Sprint 结束时的代码）。我希望每个图书馆团队都会在这些地方标记他们的代码。

第一次分支似乎很容易。但是用每个库的标记版本来刷新分支呢？

我要合并吗？如何指定我只想合并来自某个标签的更改？假设我将在库发布后的某个时间合并，以便“最新的库代码会有我不想要的更改——下一个版本的不稳定更改）。

或者 - 我应该每次都重新分支吗？

或者 - 做其他事情？

我们仍然想自己构建他们的代码——所以我不是在寻找任何关于为每个库的版本签入二进制文件的建议。

我遵循 dev=trunk release=branch 约定。这对源代码很有用，但是 ppl 对文档有什么作用（不幸的是它在 MS Word 中（LaTex 对我们的公司业务/系统分析师来说太多了）。

您是否还将文档保留在分支上并在发布后合并（这很痛苦）？
还是您只在主干上保留文档？

We have two websites for the same client (main www site and another for the ecommerce site which sits on a seperate server) that use shared portion of code (various features/styles/javascript etc.). We currently manage this by having the shared code as seperate projects (in the same repos) in SVN and using svn:externals to pull the branch of each of these into the two website projects.

We have just created two release branches, one each for the two sites. Everything gets commited to trunk for each of the sites as normal when working and when "ready for live" we merge it into the release branch for that site. Works a treat except today we modified the some of the shared code and noticed that the release branch pulled it in straight away when we did an update on the release branch. This is not what we wanted :(

So any ideas how we can iron out this problem. We used externals to DRY up the sharing of the code but is there another way? Notice that in this question (How can I branch in SVN and have it branch my svn:external folders as well?) they mention externals are bad and we should be using a different build process but no mention of what that should be.

We have CruiseControl.net running our builds and are keen to get this nut cracked. Has anyone any ideas on a better process?

Cheers

Pete

UPDATE: We've since moved to using Mercurial (Fogcreek's Kiln) for our source control. Mercurial also has the idea of sub-repos so we followed that route with our project there too. However it comes at a cost, branching is made really difficult as is tagging and simply keeping everything up to date. Our latest method is to bring both projects into one repos including all the shared repos too. This gives us one "mega project" which slows clone time (check out in SVN) but we do that so rarely that the gains of not having to deal with sub-repos makes it well worth while. We now use feature switching/toggling rather than branching which also simplifies our development greatly.

对于新版本，我增加了可执行文件的版本号，即使 dll 根本没有更新，我是否应该让所有 dll 都具有与可执行文件相同的版本号？

假设您在一个大型项目中工作，每个版本都针对多个功能。对于每个功能开发，我们可能有不同的功能分支（在 VCS 中）。但是在合并所有功能分支并完成集成之后，说其中一个功能被删除（这在我们的组织中发生的频率比您想象的要高）。此时有没有办法回滚功能？我们通常所做的就是弄清楚所有代码更改并手动回滚。您是否有任何有助于减少这项工作的流程/最佳实践？作为记录，我们有一个带有 subversion 作为 VCS 的 java 项目。

我们公司需要的是一种用于 Linux/C++ 的发布管理工具。我们的产品由多个库和配置文件组成。在这里，我将列出我们希望此类系统具有的基本功能：

• 跟踪依赖项的能力，轻松增加依赖项的主要版本增加的库的主要版本。它应该在内部构建某种依赖关系图，以便知道谁受到更新的影响。

• 知道如何构建它处理的产品。无论是特定的构建文件，还是更好的——阅读和理解生成文件的能力。

• 使用 SVN，以便它可以从那里检查新版本并进行构建。

• 生成一些安装程序 - 以 rpm 或 tar.gz 格式。为此，它应该能够理解 rpm 规范文件格式。

目前我们正在开发这种已经非常有用的工具。但是我相信我们的任务并不是独一无二的，应该有一些工具可以完成这项工作。

Hudson CI 服务器显示稳定的“天气”，这很酷。它允许一个项目构建基于另一个项目的成功构建而开始。但是，您如何使第二个项目额外依赖于第一个项目的多个构建的稳定性？

具体来说，如果项目“integrate”与版本 8.3.4.1233 已成功构建和测试至少 8 次（连续成功），则项目“stable_deploy”只需启动以将版本提升为“稳定”。在那之前，它仍处于集成模式。

重要提示：对此的一个重要警告是，一组 Hudson 项目被用作处理每个新版本直至发布的“管道”。因此，一个项目可能连续成功构建了 8 次，但最新版本 8.3.4.1233 可能只是最近的 2 次构建。在此之前的版本可能是较早的版本。

我们愿意完全重组它，但管道的想法似乎大大减少了手动项目创建和删除的数量。有没有更好的方法来跟踪版本发布“管道”？特别是，由于对旧版本的修复或补丁，我们将在未来同时在此管道中拥有多个版本。除了为每个版本创建新的管道项目之外，我们还没有看到如何做到这一点，这确实很麻烦。

以下是一些背景细节：

TickZoom 应用程序有一些非常完整的单元测试，其中一些模拟实时交易环境。除此之外，TickZoom 还巧妙地利用并行化来利用多核计算机。不用说，在新版本的开发过程中，在集成测试过程中可能会出现稳定性问题，通过反复运行构建和自动测试会发现这些问题。连续 8 次干净地构建和测试的版本，加上经过用户实际测试的版本可以被视为“稳定”并升级到稳定分支。

我们的 Hudson 项目如下所示：

test - 仅用于测试构建，零用户可见性。integration_deploy - 促进测试项目构建以集成分支，并使其可供公众用于 UA 测试。集成 - 重复构建集成分支以确定它是否足够稳定以提升到稳定分支。这会在每晚每小时运行构建和测试。stable_deploy - 将集成项目构建提升到稳定分支，并将其公开给想要最新和最好的用户。stable - 每晚构建一次 stable 分支。经过 2 周的成功构建（14 个构建）后，它可以进入“候选发布版”。

依此类推......它继续“发布候选”，然后是“发布”。

我正在开发一种产品，该产品依赖于几个不同的项目，每个项目都托管在自己的 Git 存储库中。在发布版本时，我们最好对构建产品所涉及的每个项目进行一致的标记 - 这包括核心代码、库和构建工具。是否有一种明显且明智的方式来一次标记所有项目？

（这可能会让人分心，或者值得注意的是每个项目都在使用 Maven；也许有插件可以管理这个。如果是这样，我还没有找到。）

要发布我的集中式 web 应用程序，我可以让一个虚拟主机指向某个目录，然后在我想要发布时执行“git pull”，更新文件。但是 Rails 有一个不同的部署机制：它将文件复制到一个子目录，然后将一个符号链接（'current'）指向那个新的子目录。

我知道进行类似 Rails 的部署可能更容易接受，因为发布是在某个目录中构建的，然后符号链接指向该目录，所以这要快得多，而且用户不太可能遇到奇怪的问题，同时正在发布。

Rails 方法还有其他优点吗？或者，“git pull”方法实际上是否被更广泛地接受？

我们的小组目前正在分析我们管理正式软件发布和与错误生命周期集成的程序。

您使用什么错误生命周期模型？为什么？

例如，假设每周为 QA 生成一次正式版本。您在什么时候将错误标记为已解决？

• 开发人员何时提交更改？
• 何时审核更改并将其合并到发布分支中？
• 什么时候创建了正式的候选发布版本？

您使用什么过程或错误跟踪软件的功能来跟踪它？

有什么提示/建议/建议可以分享吗？