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

时间:2009-01-14 15:12:17

标签: asp.net migration audit

我的团队最近收到了外部审核的结果,我们必须更正一个项目。

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

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

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

3 个答案:

答案 0 :(得分:1)

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

答案 1 :(得分:1)

我的建议是远离将文件从一个环境移动到另一个环境并开始实施候选发布包装。

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

循环将如下所示:

  • 从发布候选标记分支构建发布候选版本,其中包含已准备好通过测试手套的合并变更集,
  • 将构建中的所有文件打包到tar / zip / setup.exe
  • 通过相同的软件包部署到各种测试环境
  • 如果候选发布者通过测试,则可以使用相同的包来部署到生产中;如果没有,请回到原点并将另一名候选人放在一起。

如果候选版本失败,则将候选项指定为失败的基线,实施修复程序,并构建和打包另一个版本候选版本。

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

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

我的首选是构建所有内容并部署所有内容,即使只更改了一个文件。每次构建,打包和部署所有内容都可以使脚本和过程变得简单和可重复。

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

答案 2 :(得分:0)

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