问题标签 [change-management]

我正在寻找一种方法来设置拉部署，与 Windows 下的传统推送部署模型相反。

最佳情况是：

• 将文件部署到主服务器
• 子服务器将检查主服务器是否在给定时间或时间间隔有更新。
• 如果主服务器包含更新，那么它将下载更新和/或执行脚本（类似于 nant？）

该解决方案需要尽可能轻巧，并且必须在 Windows 环境下运行。

我看过Chef和SmartFrog但不适合这种特殊情况。

编辑：正在部署多个软件。这些是数据库脚本、Windows 服务和网站。每个孩子都有自己独特的脚本，因为它的要求和身份验证细节与其他的不同。

编辑2： 到目前为止，人们已经提出了很好的答案，但最终的解决方案确实需要安全、内部运行并且同时发生。这是由于合规性、行业法规和版本问题（例如，数据库服务器与服务不同步）。我想到的最终解决方案类似于主服务器上的 FPT 服务器和子服务器上运行的 Nant 以执行安装例程（启动、停止服务、安装 sql 脚本、记录安装）。这是目前可用的最接近的东西，但并不理想，因为 nant 以推送为基础工作（仅在某人或程序（例如 Cruisecontrol）运行脚本时执行）。我确信必须有一个解决方案来为 Windows 进行正确的 PULL 部署。

我应该把我的 NHibernate SchemaExport 方法放在哪里，当我决定重新创建数据库时应该如何调用它？

我应该把它留在我的启动项目（一个 asp.net mvc 项目）中吗？我应该创建一个单独的控制台项目来导出我的架构吗？

我认为这些问题都源于我不希望每次 Web 应用程序启动时都运行架构导出这一事实。

如果这有所作为，我正在使用流利的 nhibernate。

我可能很快就会使用 Siebel CRM，我正在寻找有关使用现代开发实践和企业最佳实践的建议。

具体来说，我想就以下领域提出建议：

• 我们应该如何设置版本控制（特别是使用 Subversion）？我们的存储库应该有什么样的结构？我们应该如何处理分支和标签？
• 我们如何进行代码审查？我们如何对通过 Siebel Tools 所做的不一定有任何“代码”的配置更改进行同行评审？我们希望审查这些变更，以确保质量保证和知识转移，以及遵守变更管理政策。
• 什么样的变更管理适用于 Siebel？当我们进行新的部署时，我们如何验证只有更改日志中列出的内容才会真正更改？
• 我们如何自动测试我们的应用程序？甚至可以使用 Siebel 进行单元测试吗？我看到另一个建议使用 QTP 进行 Web 测试的问题，但是还有其他可行的选项吗？
• 我们还可以做些什么来通过我们的 Siebel 开发工作来实施持续集成实践？
• 对于命名约定和其他传统上属于“编码风格”指南的内容，您有什么建议？
• 我们应该如何将开发角色与 Siebel 管理员角色分开？我们的构建/测试/部署周期应该是什么样的？

我不太可能为此获得任何新的昂贵工具，但如果有一个付费工具可以提供非常好的投资回报率，请随时提及。

如果您在这些方面有其他建议，但我的一个问题没有具体解决，请随时添加。

我正在寻找与 SQLite 一起使用的良好变更管理应用程序。过去我使用过 Redgate 的 SQL 数据比较，但我找不到任何类似的支持 SQLite 的东西。

我需要更新一个相当大的加密SQLite 数据库（约 1,000,000 行和 74MB）。如果可能的话，我想生成一些脚本来更新更改，而不是强制用户下载数据库的全新副本。我们使用的 SQLite 版本是 3.6.23.1。提前感谢您的任何建议:)

I am working on an application, for which a temporary change request has come in to a given feature. Specifically, the business currently only wants to manage a Physical address for a given customer, and wants us to remove the option to add a mailing address.

This feature will most likely need to be re-introduced in the future, so, I am wondering what the best way to handle the removal would be for now. Having additional properties on the ViewModel is not necessarily a problem, but, it's messy. And there is even more of a problem when it comes to the View itself. We need to remove the UI elements, but, we need to make it easy to bring it back in the future.

So...do I comment out the unneeded code bits? This is the simplest approach, but, it's messy.

Do I create a new View and ViewModel? If so, where is the appropriate place to store the original for safe-keeping? Our application is under source control (SVN), so, we could theoretically come back to this revision, but, it seems like overkill for such a small change.

Has anyone else run into a similar situation? Any recommendation on how to best handle this?

过去几年我一直在使用分布式版本控制系统，但现在我将不得不使用 CVS。我想要的过程是这样的：

1. 每个错误/功能在票务系统中都有一张票
2. 开发人员被分配到错误/功能（如有必要，票证将被分解成更小的票证，以便开发人员与票证的关系是一对一的）
3. 开发人员进行更改并将其与工单相关联
4. 在固定时间点为候选发布者选择一组票 发布候选者将被测试
5. 使用来自候选人的票的子集构建发布
6. 循环又开始了

我目前的幼稚计划是

1. 把每张票放在它自己的树干分支里
2. 为每个发布候选者创建一个分支
3. 将工单分支合并到候选发布
4. 当一个发布候选被认为足够好时，将其合并到主干中

我已经忘记了我过去所知道的关于 CVS 的一切，但我有一种直觉告诉我这将是一个错误。我会遇到什么性能或其他类型的问题？有没有更好的方法可以根据在给定时间段内完成的工作子集有选择地创建构建？

将项目相关文档保存在 svn 中是个好主意吗？您可以为此推荐任何文档管理应用程序（sharepoint？）吗？问题是针对一个中等规模的软件公司（20 个开发人员）。

我们的服务环境由大约 16 台服务器组成。每个环境（即开发、测试和生产）都有自己的 16 台服务器。我们正在考虑对这些服务器进行平台升级，这将需要重建和重新部署每个服务。没有代码更改，但所有服务都需要重建。情况听起来很简单。但是，我们在这些环境中（从开发到测试再到生产）不断地进行错误修复和新版本 - 这个过程不能长时间中断。这意味着几乎不可能出现“代码冻结”情况。因此，我们可能会遇到开发和测试处于版本 N 和生产处于 N-1 的情况，这是不可接受的。

升级后的软件平台可以与现有版本并行安装在同一台服务器上。鉴于此，执行此平台升级的替代方案是什么？

我们正在考虑将Terracotta用于我们的下一个项目。我对它在不需要单独的 DBMS 的情况下提供数据持久性的潜力很感兴趣。（另见 关于使用 Terracotta 作为持久性解决方案）

软件演进的一大痛点是使现有的生产数据符合新的数据模型。对于 RDBMS，您可能会在部署时使用 SQL 更改脚本。对于 Terracotta 支持的数据，我并不清楚如何处理非平凡的进化。

Terracotta 文档中有几段关于 Class Evolution 的段落，但它似乎是特定于 DSO 的，而且相当肤浅。

1. 有哪些可能的方法来处理存储在 Terracotta 中的持久数据的数据模型演化？我对非 DSO 场景（即通过 Terracotta Toolkit API）特别感兴趣。
2. Terracotta DSO 和 Toolkit API 对进化类定义的反应是否不同？
3. 要了解类进化的局限性，了解 Terracotta 如何表示/传达对象数据会有所帮助；有规范吗？
4. 也许 OODBMS 世界中存在适用于 Terracotta 的模式演化技术？

作为一个简单的例子，假设我Car存储了一堆对象，并且我已经将类的modelYear字段Car从 aString更改为 an int。根据文档，这不是开箱即用的。我可以想象一个解决方案，Car在应用程序启动期间我的旧类加载器由单独的类加载器加载，然后转换为新的Car. 这会是一个好方法吗？为什么（不是）？

我是 D3 的新用户，我正在尝试思考如何最好地实现我们的配置项的映射。

我正在寻找的本质上是一个树图（我认为），但具有相互关联的依赖关系。

数据

我正在使用 ITIL 风格的配置项，如逻辑服务、应用程序、机器等，它们构成了我们为客户提供的 IT 服务。

我将提供的 JSON 数据将来自我正在定义的 WebAPI 服务，因此可以返回数据，但这是必要的。

目标

我需要克服：

• 配置项的名称（“服务 A”、“服务器 1”、“数据库 XYZ”等）
• 配置项类型（用图标或颜色表示——现在不太重要）
• 那些依赖最少的东西在顶部
  • 即，服务由构成它的所有事物表示——应用程序、数据库等，我希望按照从服务向下的顺序排列层次结构。
• 所有元素之间的关系，不是严格分层的。
  • 多个服务可能依赖于一个应用程序
  • 多个应用程序可能依赖于多个数据库，而这些数据库可能依赖于一个数据库服务器。
• 如果可能的话，可以通过单击从上到下关注树的一个分支（尽管这可能会在以后出现）

一旦我开始了解它，我想在 GitHub 上设置一些简单的东西，看看我是否可以使用 D3 为 IT 服务管理世界做出贡献。

问题

从哲学上讲，D3 是否旨在支持这种性质的可视化，实现它的最佳途径是什么？

谢谢！