问题标签 [maintenance]

您应该在代码库中将旧代码注释掉多长时间？承包商通过将旧代码转换为注释来继续将旧代码保留在代码库中。这真的很令人沮丧，我希望他们只删除旧代码而不是将其注释掉。

是否有正当理由将代码库中的旧代码作为注释保留？我正在使用 Visual Sourcesafe 的版本控制

我想更好地了解应用程序正在做什么。我们正在监视 ASP.NET 和 .NET 计数器，但我们需要更深入地了解正在发生的事情以及发生的速度。这方面的最佳做法是什么，是否有适用于 Microsoft.NET 环境的特定指导或文档？我会为此使用企业库吗？我们已经在使用库的一部分来将数据导入我们的应用程序。

在这一点上我们最大的痛苦：

• 对应用程序进行故障排除的方式很少

  _{（有日志，但日志记录过多，以至于日志由于大小而变得几乎无用）}

• 对现有性能的影响最小
• 看不到 Enjim 客户在做什么，比如命中未命中等。
• 监控非常独特的性能（如内存缓存服务器死机）

奖金

• 使用 MOM 中收集的数据
• 使用这些数据来优化应用程序，在那里它会产生最好的影响
• 增加系统的可维护性，让我们的运维人员可以更轻松地维护这个系统。

我有兴趣为我的组织维护一个Maven 2 存储库。有哪些有用的提示和陷阱。

在发布代码时，用户在设置从存储库下载或发布自己的工件到存储库的标准时应遵循哪些准则？你对这类事情有什么样的治理/规则？您在开发人员指南/文档中包含了哪些内容？

更新：我们已经建立了 Nexus 并且对它非常满意 - 遵循了 Sal 的大部分指导方针并且没有遇到任何问题。此外，我们通过 Hudson CI 服务器限制了部署访问和自动构建/部署快照工件。Hudson 可以分析所有上游/下游项目的依赖关系，因此如果编译问题、测试失败或其他一些违规行为导致构建中断，则不会发生部署。不要在 Maven2/Maven3 中进行快照部署，因为元数据在两个版本之间发生了变化。“仅 Hudson”快照部署策略将缓解这种情况。我们不使用发布插件，但围绕版本插件编写了一些管道当要移动快照以释放时。我们还使用 m2eclipse，它似乎与 Nexus 配合得很好，因为从设置文件中它可以看到 Nexus 并且知道从那里索引工件信息以进行查找。（尽管我不得不调整其中一些设置以使其完全索引我们的内部快照。）如果您有兴趣这样做，我还建议您将带有工件的源 jar 部署为标准做法。我们在超级 POM 中配置它。

更新2：我遇到了这个 Sonatype 白皮书，其中详细介绍了采用/成熟度的不同阶段，每个阶段都有不同的 Maven 存储库管理器的使用目标。

我需要在下午 6 点到早上 7 点之间禁用对 SharePoint 应用程序的访问。SharePoint 2007 似乎没有开箱即用的“维护模式”，因此我正在寻找解决方案。目前有人将用户移出安全组以限制对应用程序的访问，因此至少自动化该过程是可行的。

是否有 PowerShell 脚本或 SharePoint 功能或我可以添加到我的服务器以启用应用程序的维护模式的东西？也许是 SPJobDefinition 的示例代码？

任何人都可以建议可以提高 sql server 2008 中数据库可用性和性能的工作吗？

我想确保所有存储过程在语法上仍然有效。（如果有人重命名/删除表/列，就会发生这种情况）。

现在我检查所有存储过程语法的解决方案是进入企业管理器，选择列表中的第一个存储过程，然后使用该过程：

1. 进入
2. Alt+C
3. 逃脱
4. 逃脱
5. 向下箭头
6. 转到 1

它有效，但它非常乏味。我想要一个名为的存储过程

语法CheckAllStoredProcedures

就像我编写的另一个存储过程一样，它对视图执行相同的操作：

刷新所有视图

为了大家的利益，RefreshAllViews：

RefreshAllViews.prc

为了每个人的利益，将所有存储过程标记为需要重新编译的存储过程（将存储过程标记为重新编译不会告诉您它是否在语法上有效）：

重新编译AllStoredProcedures.prc

为完整起见，UpdateAllStatistics过程。这将通过执行完整的数据扫描来更新数据库中的所有统计信息：

RefreshAllStatistics.prc

我已经检查了一个外部 svn 存储库，我已经应用了几个补丁。
（由于冲突，只能手动应用补丁。）

现在我希望能够以适当的方式维护远程存储库的本地副本。
（除了在远程存储库上读取之外，我没有任何其他访问权限。）

首先，我需要能够在某种源代码控制系统中签入我的本地更改，因为在应用补丁时涉及手动步骤。

其次，我仍然希望能够从远程存储库接收更新。

实现这一目标的最佳方法是什么？

我最近在我正在处理的一个站点中发现并修复了一个错误，该错误导致表中存在数百万行重复的数据，即使没有它们也会非常大（仍然是数百万行）。我可以很容易地找到这些重复的行，并且可以运行一个删除查询来将它们全部杀死。问题是尝试一次删除这么多行会长时间锁定表，如果可能的话，我想避免这种情况。我可以看到摆脱这些行的唯一方法是：

1. 编写一个脚本，将循环执行数千个较小的删除查询。从理论上讲，这将解决锁定表问题，因为其他查询将能够使其进入队列并在删除之间运行。但它仍然会大大增加数据库的负载，并且需要很长时间才能运行。
2. 重命名表并重新创建现有表（它现在为空）。然后对重命名的表进行清理。重命名新表，重新命名旧表并将新行合并到重命名的表中。这种方式需要更多的步骤，但应该以最小的中断完成工作。这里唯一棘手的部分是有问题的表格是一个报告表，所以一旦它被重命名并且空的那个放在它的位置，所有历史报告都会消失，直到我把它放回原位。另外，由于存储的数据类型，合并过程可能会有点麻烦。总的来说，这是我现在可能的选择。

我只是想知道以前是否有其他人遇到过这个问题，如果有，你是如何在不关闭网站的情况下处理它的，并且希望对用户的干扰最小？如果我采用 2 号或其他类似的方法，我可以安排这些东西在深夜运行，并在第二天一大早进行合并，并提前让用户知道，所以这不是什么大不了的事。我只是想看看是否有人对更好或更简单的清理方法有任何想法。

我试图安装此 .htaccess 以通知我的用户进行站点维护。似乎第一个 [L] 不起作用，第二个重写正在做所有事情。

你们如何做网站维护消息？

在大型组织现场安装应用程序并支付支持费用的情况下，我的公司正在努力解决维护版本与“正常”版本的问题。首先让我定义我的术语：

• 假设我们已经发布了产品的 1.0、1.1 和 1.2 版本。这些是我所说的“正常”版本，即它们是主要开发分支的下一个版本，包含所有最新和最强大的错误修复和增强功能（每个版本可能有数十个）。
• 现在想象一下 1.0 上的一些大客户报告了一个以前没有人遇到过的令人震惊的问题。这个问题在 1.2 中仍然存在，不幸的是 1.3 不会在几周或几个月后发布。因此，我们在 1.0 分支代码以创建 1.0.1“维护”版本，其中仅包含解决问题的一项更改。

这种方法让客户很高兴，因为我们在一天左右的时间内解决了他们的问题，而不是让他们等待数周直到下一个正常版本。此外，由于维护版本只包含一个小的更改，他们不需要经过广泛的 UAT 过程，而如果他们升级到下一个正常版本，可能会有几个版本，他们可能会收到 30 或 40 （在他们厌恶风险的观点中）需要大量 UAT 的产品变更。

问题是：

• 创建和支持我们软件的多个版本对我们来说成本很高
• 它允许顽固的客户远远落后于最新版本
• 它使将来最终升级这些客户的过程变得复杂，因为他们的安装与所有其他 1.0 客户略有不同（如果维护版本以某种方式对其进行了更改，则升级他们的数据库特别复杂）

所以我想知道其他人在这个问题上的立场是什么？您如何在不通过大量维护版本为您自己背锅的情况下让客户满意？例如，您是否允许某些类别的修复作为维护版本完成，但坚持其他类型的修复在下一个正常版本中完成？

澄清：编写没有错误的软件并不是一个完整的解决方案，因为上述上下文中的“问题”可能是我们产品所依赖的外部系统行为的不可预见的变化。