1

我的团队最近收到了外部审计的结果，我们必须更正一项。

他们希望我们改变将代码移动到生产环境的方式。我们目前对所有代码更改和移动请求等使用源代码控制和票务系统。

问题在于如何将代码推送到我们的生产网络服务器。而不是使用 Araxis Merge 或差异工具。他们希望我们使用能够对移动的文件进行全面审核的工具。审核员稍后将检查该工具的日志，以确保只有经过批准的代码才能投入生产。

有人使用这样做的工具吗？

4

3 回答 3

1

我的建议是不要将文件从一个环境移动到另一个环境，而是开始实施候选版本打包。

这些软件包可以使用归档工具（tar、winzip）或更复杂的工具（如 Wise Installer 或 InstallShield）从简单的方式实现。

循环将类似于以下内容：

  • 从发布候选标签分支构建发布候选，其中包括准备通过测试挑战的合并变更集，
  • 将构建中的所有文件打包到 tar/zip/setup.exe
  • 通过同一个包部署到各种测试环境
  • 如果候选发布通过测试，则可以使用相同的包部署到生产环境；如果没有，请回到第一方并组合另一位候选人。

如果候选发布失败，则将候选发布指定为失败的基线，实施修复，并构建和打包另一个候选发布。

虽然我通常不赞成将构建的对象放入源代码存储库，但从方便和控制的角度来看，可以将包置于控制之下，以确保在使用包从一个部署的时间之间不会对其进行任何更改环境到另一个。

候选发布版本 ID 应用于包和相关代码分支的命名约定中，以确保明显的关系。如果可能，将版本 ID 信息放入资源文件有助于确保来自正确构建的文件存在于正确的位置。

我的偏好是构建所有内容并部署所有内容，即使只更改了一个文件。每次构建、打包和部署所有内容都可以使脚本和流程保持简单和可重复。

基本上...构建一次，经常部署。

于 2009-01-23T19:52:30.863 回答
1

我会使用MSDeploy。这是Application Center 2000的继任者。这将允许您构建包（文件、GAC 程序集、DB、COM...）并从 DEV --> QA -- PROD 推送它们。这样，您将确保完全部署，并且可以归档日志以满足审计要求。

于 2009-01-14T15:23:01.877 回答
0

robocopy e:\src\WebApp \\production_server\wwwRoot\WebApp >> auditme.txt

于 2009-01-21T04:20:06.253 回答