问题标签 [release-management]

我在 Pypi 上维护了几个鸡蛋，但到目前为止，我一直专注于 Python 2.5x。我想以自动化方式在 Python 2.5 和 Python 2.6 下发布我的鸡蛋，即

1. 运行测试
2. 生成文档
3. 准备鸡蛋
4. 上传到 Pypi

你们是如何做到这一点的？

一个相关的问题：我如何将鸡蛋标记为“版本独立”？可以在所有版本的 Python 下工作吗？

我正在将一个 ant 项目转换为一个 Maven 项目。这个项目与我通常转换的项目不同，因为它的发布非常频繁，通常每天 8-10 次。

通过发布，我的意思是生成的 jar 被打包并包含在生产环境中。这个项目是一个叶子项目，所以它不发布任何 API，它只使用它。它最多也是另外两个项目的运行时依赖项。

我想要一个版本控制方案，其中：

• 它很容易部署，而无需强迫开发人员考虑分配给项目的版本号，因为该数字没有意义；
• 很容易将这个项目的最新版本包含为依赖项，而不会不断地增加依赖项版本；

依赖版本很可能不是 a -SNAPSHOT，因为这会与maven-release-plugin我们用于其他项目的冲突，但我愿意接受建议。

我们有一个项目，它有几个独立开发的组件。然而，我们有许多版本都被命名为具有不同时间表的不同产品。当组件有新版本（可能与错误修复相关）时，我们希望立即获得反馈，因此所有依赖于该版本的产品也将得到更新。

当然这只是一个简单的例子。应该有专门针对这种情况的项目，但我找不到。您如何处理此类情况？首选（简单但强大）的方式是什么？

与“正常”的 svn 目录结构相反，我使用以下结构：

如您所见，每个项目我都没有单独的三元组（主干/分支/标签）。

对于开发，我会检查包含我需要的所有项目的主干（有时是稀疏检查）（项目之间存在依赖关系，有些项目只是库）。

我看到的好处是：

• 更新和签入很容易，因为我有一个所有项目的公共根目录（主干）。一个简单svn update或svn commit全部完成。

• 创建标签或分支很简单，因为这只是我必须要做的主干svn copy。（分支和标签实际上包含比需要更多的项目，但是 asvn copy很便宜，如果需要，我仍然可以在分支或标签上进行稀疏检查。）

• 将资源从一个项目转移到另一个项目很容易，因为它们都存在于同一个存储库中。

• 当我对主干进行全面检出时，全局重构（例如更改常用类的包）很容易，因为我可以确定我不会错过任何项目。

• 合并很容易，因为即使从一个项目到另一个项目的重构移动，我也总是可以一次合并整个分支。

我打算迁移到 maven 并将所有项目从主干项目拆分为 maven 项目。我想从 maven 依赖管理和可用插件中受益（现在我正在使用巨大的自定义 ant 文件）。

现在我的问题是：

• 我是否必须更改 svn 目录结构以赋予每个项目自己的三元组（主干/分支/标签）？我想答案是“是”。

• 如果我改变结构，我会失去上面提到的哪些好处（我的意思是用 maven 做会更复杂）？

• 使用 Maven 的等效方法是什么？

我们需要增加对 ASP.NET 网站/Web 应用程序部署的了解。我们越来越大，流量越来越大，需要更专业的方法。更不用说，我们也正在升级到多个数据库/多个后端/多个前端服务器部署，我们只是不想把它搞砸。

我们应该寻找什么类型的技能，拥有这些技能的人是否有一个典型的头衔？

谢谢，

实际上，我们拥有两个答案提到的大部分人才，我们正在寻找的是我猜戴夫所说的网络服务器大师。我只是希望有人来处理部署方面。我们的开发人员需要在他们的最终目标上工作，而不是试图找出部署最佳实践。此外，我们最终可能会有多个项目和团队，我不认为每个团队都有一个单独的人来滚动他们自己的解决方案会像所有团队的一个专用资源一样好。

我的上一位雇主开发了一个精心设计的系统，该系统位于 SVN 之上以处理正在进行的开发：（变更管理）查看错误/问题，并在提交时通过标记错误 ID 号和（发布管理）标签将它们与提交相关联SVN 中的项目作为基于错误/问题跟踪系统的特定版本的一部分。第二部分有一个与之相关的工作流程，以从用户/管理层获得签字。然后，到了发布的时间（通常是每个星期四晚上），他们可以运行一个命令来检查所有标记的代码并进行部署。

我的新公司要小得多，我有兴趣找到一个低成本/低维护的等价物，即使它只是意味着直接与 SVN 打交道。特别是，我经常发现在游戏后期提交会破坏我们的构建，并且很难理清我们可以包含的内容。（就管理 SVN 而言，我倾向于使用标签而不是分支的想法，因为它需要更少的深谋远虑，但我很高兴被说服。）

人们使用什么来标记发布的提交并进行后续部署？是否有任何好的开源解决方案来管理发布周期，允许您从 Web 浏览器浏览 SVN 并标记发布的问题/提交？到目前为止我看到的最好的东西是Jira，但它看起来像一个非常大的工具（很难配置/维护吗？）。Apache 基金会为此目的充分利用了 Jira（例如，参见Mahout 路线图）。

更进一步的做法是让这个相同的系统还包括持续集成，以便我们的单元测试可以在每次提交时运行，然后每个错误/问题也将与这些信息相关联。

注意：关于 stackoverflow 有一些稍微相关的问题，但我没有看到任何涉及部署周期和发布管理这方面的内容（请参阅release-management-in-svn、manage-your-project-life-cycle和best -处理变更管理的方式）。

我正在构建一个 Android 应用程序，并希望维护一些环境变量，我可以根据我是处于开发模式还是发布模式来调整它们。例如，我需要调用一个 Web 服务，并且 URL 在任何一种模式下都会略有不同。我想将此设置和其他设置外部化，以便可以根据我的目标部署轻松更改它们。

SDK 中是否有任何最佳实践或任何内容来帮助满足此需求？

我们有一个较大的独立（即不是 Java EE）商业 Java 项目（10,000 多个类、四到五个 SVN 存储库、十或二十个第三方库）正在切换到 Maven。不幸的是，只有一名工程师（分布在三个国家的十几名工程师的团队中）有任何先前的 Maven 经验，所以我们在进行过程中会弄清楚这一点。

在旧的 Ant 做事方式中，我们会：

1. 从三个或四个存储库中查看源代码
2. 将它们全部编译成一个单一的 JAR
3. 发布它（作为带有库 JAR、安装程序、各种配置文件等的 ZIP 文件的一部分）
4. 将 JAR 检查到 SVN 中，这样我们就有了客户实际得到的记录。

现在，我们有一个充满工件的 Maven 存储库，以及一个依赖于 Maven 访问该存储库的构建过程。因此，如果我们需要复制我们实际交付给客户的内容，我们需要针对具有所有正确版本的 Maven 存储库进行构建。我猜，如果在（某些版本的）（SVN 控制的）POM 文件中，我们将所有依赖项设置为已发布版本，这是可行的？

但它让我们的发布工程师感到毛骨悚然，因为似乎没有任何办法：

1. 确保有人不会错误地破坏 WebDAV 服务器上的 foo-api-1.2.3.jar 副本（WebDAV 服务器具有访问控制，但这不会阻止错误的构建脚本）
2. 检测它，如果他们这样做
3. 之后恢复

他的想法是，对于发布版本，使用本地文件系统作为存储库而不是 WebDAV 服务器，并将本地存储库置于 SVN 控制之下。

我们的一位 Maven 经验丰富的工程师不喜欢这样——我猜是因为他不喜欢将二进制文件置于版本控制之下？- 并建议也许专业版的 Nexus 服务器可以解决破坏或破坏跟踪/恢复问题。

就个人而言，当我们甚至还没有看到免费版本的任何好处时，我不高兴（对不起，Sonatype 读者）为非免费构建系统掏钱，并且不能保证它会真正解决问题。

所以我们的选择似乎是：

1. WebDAV 服务器
   • 优点：只有一台服务器，开发人员也可以访问，...？
   • 缺点：容易破坏，没有破坏跟踪/恢复
2. 本地文件系统
   • 优点：可以置于修订控制之下
   • 缺点：仅适用于分发脚本

坦率地说，这两个对我来说似乎都是黑客，我不得不怀疑是否有更好的方法来做到这一点。

所以：这里有正确的做法吗？

我在工作中发现了一个奇怪的情况，我正试图找出从哪里开始解决问题。

我们有一个定制的硬件/软件设备，其中包含多个板，每个板都有自己的功能和软件风格（CPLD、引导加载程序、应用程序等）。此外，该设备还与特定的 Web 应用程序和 PC 应用程序进行交互。

这些组件中的每一个都有一个修订历史记录，单独跟踪。特定设备（当然都是无特色的黑匣子）可能具有任何和所有组件、硬件和软件的不同版本——我们仍处于原型和测试阶段。

我想要的是某种统一的版本跟踪，我可以在其中跟踪针对错误和功能请求的软件构建，有板的历史/原理图，以及 - 最重要的是 - 哪些版本的组件已针对哪些其他版本进行了测试成分。换句话说，我知道引导加载程序版本 1 与板版本 A 一起通过了测试，但不一定针对同一板的版本 B 进行测试，即使它当时还存在。

单独的转速跟踪相对容易；我们有少数开发人员在开发不同的软件组件。它将它们捆绑在一起，并且能够说“产品版本 1.0”由这一袋组件组成，相互测试，仅此而已。这样，当我们更新引导加载程序时，我可以让它针对所有其他组件的当前版本进行回归测试，标记整个“PRODUCT VERSION 1.1”，并知道那个快照是什么，即使有人提出了版本1.4 当天申请代码。

理想情况下，我希望单独跟踪所有组件的修订历史，以及用户能够针对特定组件或整个产品记录错误，之后开发人员可以将错误重新分配给任何合适的子系统。基于网络的东西将是理想的，因为开发人员不是物理上的。

我们目前正在使用 Bugzilla，它远不能胜任这项任务。我在看 Trac，但我不确定它是不是工作中的正确工具。似乎有很多源代码控制系统、很多修订历史系统和一些项目管理系统，但我还没有找到任何可以处理我需要的一切的东西。

听起来可能更复杂，但是当我们陷入困境时，它就相当复杂了。必须有一个解决方案！

有任何想法吗？

我认为一种方法是保留一个代码库，在导出时，根据发布要求手动添加或不添加这些附加文件。但它要求您每次导出副本时都要记住这样做，这很容易忘记。

我在 SVN 中为包含这些文件的项目创建了一个分支，但问题是每次我更改主干时，我都需要在分支中再次执行此操作，或者合并。如何在不需要维护两个代码库的情况下获得所需的版本？或者有没有办法自动同步两个项目（主干，分支）的指定部分文件？有什么建议吗？