【发布时间】：2010-10-01 09:27:33
【问题描述】：
我的团队最近收到了外部审计的结果，我们必须更正一项。
他们希望我们改变将代码迁移到生产环境的方式。 我们目前对所有代码更改和移动请求等使用源代码控制和票务系统。
问题在于如何将代码推送到我们的生产网络服务器。 而不是使用 Araxis Merge 或差异工具。他们希望我们使用能够对移动的文件进行全面审核的工具。审核员稍后将检查该工具的日志，以确保只有经过批准的代码才能投入生产。
有人使用过这样的工具吗？
【问题讨论】：
【发布时间】：2010-10-01 09:27:33
【问题描述】：
我会使用MSDeploy。这是Application Center 2000 的继任者。这将允许您构建包（文件、GAC 程序集、DB、COM...）并从 DEV --> QA -- PROD 推送它们。这样，您可以确保完全部署，并且可以归档日志以满足审核要求。
【讨论】：
robocopy e:\src\WebApp \\production_server\wwwRoot\WebApp >> auditme.txt
【讨论】：
我的建议是不要将文件从一个环境移动到另一个环境，而是开始实施候选发布打包。
这些软件包可以使用归档工具（tar、winzip）或更复杂的工具（如 Wise Installer 或 InstallShield）从简单的方式实现。
循环如下：
- 从发布候选标记分支构建发布候选，其中包含准备通过测试挑战的合并变更集，
- 将构建中的所有文件打包到 tar/zip/setup.exe 中
- 通过同一个包部署到各种测试环境
- 如果候选发布通过测试，可以使用相同的包部署到生产；如果没有，请回到第一方，然后将另一位候选人放在一起。
如果候选版本失败，则将该候选版本指定为失败的基准，实施修复，并构建和打包另一个候选版本。
虽然我通常不赞成将构建的对象放入源代码存储库，但从方便和控制的角度来看，可以将包置于控制之下，以确保在使用包的时间之间不会对其进行任何更改从一个环境部署到另一个环境。
应在包和相关代码分支的命名约定中使用发布候选版本 ID，以确保明显的关系。如果可能，将版本 ID 信息放入资源文件有助于确保来自正确构建的文件存在于正确的位置。
我的偏好是构建所有内容并部署所有内容，即使只更改了一个文件。每次都构建、打包和部署所有内容，让脚本和流程变得简单且可重复。
基本上...构建一次，经常部署。
【讨论】：