Tool to Audit Code Moves to production Web Servers?

Question

My team recently received the results of an External Audit and we must correct one item.

They want us to change the way we move code to our production environment. We currently use source control and a ticketing system for all code changes and move requests etc..

The problem comes in with how the code is pushed to our production webservers. Instead of using Araxis Merge, or a diff tool. They want us to use a tool that enables full auditing of the files moved. Auditors at a later date will examine the logs from that tool to ensure only approved code made it to production.

Anyone using a tool that does this?

Answer 1

I would use MSDeploy. This is the successor to Application Center 2000. This will allow you to build packages (files, GAC assemblies, DB, COM...) and push them from DEV --> QA -- PROD. This way, you would ensure a full deployment, and you could archive the logs to meet the audit requirements.

Answer 2

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

Answer 3

My advice would be to get away from moving files from one environment to another and begin implementing release candidate packaging.

These packages can be achieved from the simple using an archiving tool (tar, winzip) or more sophisiticated such as Wise Installer or InstallShield.

The cycle would be something like the following:

• build the release candidate from a release candidate tag branch that includes the merged changesets ready to go through the testing gauntlet,
• package ALL of the files from the build into a tar/zip/setup.exe
• deploy to the various testing environments via the same package
• if the release candidate passes testing, the same package can be used to deploy to production; if not, go back to square one and put together another candidate.

If the release candidate fails, then the candidate is designated as a failed baseline, the fixes are implemented, and another release candidate is built and packaged.

While I am generally not in favor of putting built objects into a source code repository, from a convenience and control perspective, the package can be placed under control to ensure that no changes are made to it between the time package is used to deploy from one environment to another.

The release candidate version ID should be used in the naming conventions for the package and the associated code branch to ensure the obvious relationships. If possible, putting the version ID information into the resource files helps to ensure that the files from the correct build exist in the correct place.

My preference is to build everything and deploy everything, even if only one file changed. Building, packaging, and deploying everything each time keeps scripts and processes simple and repeatable.

Basically...build once, deploy often.