审计代码转移到生产Web服务器的工具？

Question

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

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

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

有没有人用过这样的工具？

Answer 1

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

Answer 2

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

这些软件包可以通过使用归档工具(tar、winzip)或更复杂的工具(如Wise Installer或InstallShield )来实现。

循环将类似于以下内容：

• 从release candidate标记分支构建发布候选版本，该分支包括准备通过测试挑战的合并变更集，
• 将构建中的所有文件打包到一个包中，通过相同的tar/zip/setup.exe
• deploy
• 进入各种测试环境。如果发布候选版本通过测试，则可以使用相同的包将其部署到生产环境中；如果没有通过，请回到原点并将另一个候选版本放在一起。

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

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

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

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

Basically...build一次，经常部署。

Answer 3

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