问题标签 [release-management]

我对构建不是很有经验 - 这可能真的很容易！我有一个简单的应用程序和一个简单的部署项目。我进入了 DLL 的发布编译版本所在的目录，对它们进行了签名（verisign），然后进入部署项目，选择了构建（而不是重新构建），它重新编译了我所有的程序集，现在它们不是t 签了。我可以保留很好的简单部署项目并且仍然有签名的程序集，还是我必须以不同的方式创建 MSI？谢谢！

In organisations where you have large numbers of applications, written in a myriad of languages running on innumerable platforms and databases how do folks manage the release of builds and patches, particularly when some of the releases are 3rd party? I know there a whole bunch of "Release Management" applications out there, but I'd be interested to know what experiences people have had.

To clarify, this isn't a question on configuration management, although that might be a small part of it. I'm more interested in managing software releases and the interdependencies and prerequisites that stem from that.

在我的项目中，我有责任开发具有以下要求的设备跟踪工具

1. 管理员可以将新设备添加到特定用户
2. 一旦设备被分配给一个人，他将请求接受该请求，因此他将负责
3. 用户可以将他的设备转让给其他用户。
4. 同时，只要状态发生变化，应向管理员发送邮件或消息。
5. 它应该本地部署在 PC 上（所以它实际上不是一个 Web 应用程序），它连接到每个人都可以访问的网络

我以为我可以为此使用 Django（我是新手），但我对本地 PC 上的部署知之甚少，我该怎么做，或者有什么更好的主意吗？

我想知道在依赖关系方面什么是最佳实践以及应该如何完成发布。就我而言，我有一个依赖于 log4net 的库，我想知道是否应该将 log4net.dll （将 log4net 引用设置为复制本地）与发行版一起分发？

我可以简单地说 log4net 应该安装在 GAC 中吗？

背景故事

我在 Rails 2.1 上，需要将 Capistrano gem 冻结到我的供应商文件夹（因为我的主机已经破坏了他们的 cap gem 依赖项，我想让自己尽可能独立）。

在我的本地 Windows 机器上，我将以下内容放在了 environment.rb

宝石已经安装，所以我冻结了它们。检查...

然后我在本地提交到 SVN 并在 prod Linux 机器上进行更新。

问题

当我尝试运行 Capistrano 的冻结版本时，出现以下错误。

任何想法我做错了什么？

更新

查看新的相关问题

直接从 Visual Studio 将新报告部署到报告服务器似乎很容易，但是当这些报告被推送到我们的网络场（开发人员无权访问）时，这需要手动完成，通过报告逐个报告，通过微软的Web 前端，或进入 MSI。

但是，有时我们可能希望重新配置报表服务器上的报表选项，例如更改所有报表的数据源或更改它们的缓存选项。与其为每组更改创建一个全新的 MSI 或手动执行此操作，我想知道是否有人知道任何替代工具可以一次更新多个报告，甚至能够将文件夹的内容部署到报告服务器上的文件夹中.

干杯，克里斯

不久前，杰夫阿特伍德在推特上说：

看，我喜欢快速发布新软件，但 WordPress 发布的频率实在是太荒谬了。

这让我想到，您应该多久发布一次软件更新？

• 日常？
• 每周？
• 每月？
• 每年？

最好的发布策略是什么？

关于发布管理的主题，我正在研究我的软件选项，这些软件将基本上执行 WSUS 提供的功能，据我所知（远程安装、版本查询、每台机器/组设置等），但对于我的自定义软件。它还需要能够运行第三方可执行文件（例如图形驱动程序安装程序），在更新之前通知软件当前是否正在运行等。

更新：我主要查看要安装的 C#/C++.NET 代码，但我正在寻找一种解决方案，用于同时将更新从一台服务器推送到十几个客户端。这是我必须包装的东西，比如说，一个 NSIS 安装程序构建脚本，还是有混合管理/管理/安装工具？我目前正在将 NSIS/WiX 视为我的主要竞争者，并使用某种脚本来填补空白（关于语言的建议，也是吗？Windows PowerShell？）。

您首选的软件版本命名方法是什么？像 Microsoft：alpha - beta - final - service pack... 像 Google：gmail beta - beta - beta - beta - :) 像一些软件：0.2 - 0.3 - 0.9999 ...

我认为最好发布您的开发人员实际测试过的软件版本；因此，我倾向于从项目/makefile 中删除“调试”目标，以便只有一个版本可以构建（并测试、调试和发布）。

出于类似的原因，我不使用“断言”（另请参阅断言总是不好的吗？ ...）。

那里的一个人争辩说，“调试”版本的原因是它更容易调试：但是，我反驳说，您最终可能希望支持和​​调试您发布的任何内容，因此您需要构建一个发布您可以在必要时进行调试……这可能意味着启用调试符号并禁用某些优化，即使在“发布”版本中也是如此。

有人说“这是个坏主意”；这是我几年前制定的一项政策，被以下因素烧毁：

• 一些开发人员正在测试他们的调试版本而不是发布版本
• 一些开发人员的编写错误，仅在发布版本中出现
• 该公司在测试不充分后发布了发布版本（它是否完全足够？）
• 被要求调试发布版本

从那时起，我看到不止一个其他开发商店遵循这种做法（即没有单独的调试和发布版本）。

你的政策是什么？