I guess it depends on your team. If you have high developer churn or a large number of devs contributing to the project then the risks might be higher but I've never really considered it an issue. I'd always advocate your build server should be a virtual machine so that you can a) easily isolate it from the rest of your environment, and b) recreate or replicate it quickly from a sys-prepped copy of the VHD file. In essence your build server is a developer workstation in that it needs all dependencies on it required to build your solution.
Using security (ACLs, CAS, drive quotas, etc.) to lock down your build server is certainly good practice and doing so would force your devs to author unit tests in such a way that they can't do too much damage. Another measure would be to enforce the unit test check-in policy so that at least all members of the team are running the tests regularly reducing the chance that something nasty gets through. Setting up unit testing as part of the CI team build is one of my "day zero" tasks along with configuring automatic deployment. I'd much rather have it and deal with any potential operational issues than not have it running as another measure of code quality. Regards, Damian Edwards Microsoft MVP<https://mvp.support.microsoft.com/profile/Damian.Edwards> | ASP/ASP.NET Readify | Senior Consultant M: 0448 545 868 | E: [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]> | C: [EMAIL PROTECTED]<sip:[EMAIL PROTECTED]> | W: www.readify.net<http://www.readify.net/> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William Bartholomew Sent: Saturday, 9 August 2008 11:27 To: [email protected] Subject: [OzTFS] Running Unit Tests on Your Build Machine I've been pondering something recently and I want to pose a question to you all... Do you run unit tests on your build machine? I've always been paranoid about doing this because you don't have that much control over what code a developer writes in their unit test. While you can limit the damage that can be done by running your builds as a non-privileged user and using ACLs to restrict what the user can do, there is still the issue of stability, unit tests filling the hard drive with temporary files, launching processes and not cleaning them up and the like. I've looked at a few solutions: 1. When the build completes queue the unit tests to run on another machine. At least this way the build machine is maintained in a clean state and it's only the unit test machine that is affected. 2. Run the unit tests in a virtual machine, at the end of the test run rollback the virtual machine to the previous state. 3. Go nuts with ACLs and CAS to ensure unit tests can't do anything bad. Is this something that bothers you? Am I just being pedantic? If it was easier to run your unit tests in a protected sandbox would you? Are you using any of these solutions? William Bartholomew Productivity Specialist - Software Engineering Financials | Human Resource & Payroll | Supply Chain | Business Intelligence | Budgeting | Property & Rating | Performance Planning | Student Management | Works & Assets | Enterprise Content Management | Custom Software Development | Consulting Services Phone: +61 7 3377 7566 | Fax: +61 7 3377 7301 | Mobile: +61 403 828 029 Address: 67 High Street, Toowong QLD 4066 (PO Box 1078 Toowong QLD 4066) Email: [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]> Web: www.TechnologyOneCorp.com<http://www.technologyonecorp.com/> TechnologyOne (ASX: TNE) is a leading enterprise software solutions provider with offices in each State and Territory of Australia, New Zealand, Malaysia and the United Kingdom. For more than 20 years we have been providing comprehensive and deeply integrated enterprise software solutions used by business, government, health and community, education, financial services and the utilities sectors. We develop, implement and support our own world class solutions which are based on leading edge, state of the art technology and backed up by a substantial research and development program to ensure we continue to provide our customers with long term security. TechnologyOne accepts no liability for any damage caused by this email or its attachments. The information in this email is only for the intended recipient and may contain confidential and/or privileged material. If you received this in error, please kindly notify the sender by return email and delete this email and any attachments from your system. Opinions, conclusions and other information in this message that do not relate to the official business of the company shall be understood as neither given nor endorsed by it. If you believe that you have been spammed please email [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]> to report your complaint. OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. View the web archives at http://www.mail-archive.com/[email protected]/ Powered by mailenable.com, supported by www.readify.net OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. View the web archives at http://www.mail-archive.com/[email protected]/ Powered by mailenable.com, supported by www.readify.net
