Take the 2-minute tour ×

What's the best practice for setting up a scheduled job (like a software build) so that it's not tied to a single user?

Our situation is that we need to schedule a job that runs overnight on a Windows 7 box, and we want anyone in our group to make changes or restart the job as necessary (i.e. in case the owner is on vacation or out sick). I can make the files themselves accessible to multiple users, but the problem is the job itself. I'm guessing our security group would balk at a local account with a known password, and our group policy seems to not allow jobs that auto-log-in as a user.

share|improve this question
add comment

2 Answers

I think you should manage the two aspects separately, but you could solve it all with my first recommendation.

Restarting the job

You could make everyone who needs to be able to restart the job an administrator on the build box.

Making changes to the job

Keep your build scripts in version control and have your job check out the build scripts before each run. Then you can grant commit access to anyone who should be allowed to modify the build job.

share|improve this answer
add comment

If you're trying to do Software builds (as mentioned in the OP) check out a system designed for this fuctionality such as CruiseControl.Net (http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NET) or Hudson. These will even provide nice easy restart functionality.

If you're doing software dev and don't have a Source Control system, get one NOW!!! CVS, SVN and Git are all relatively simple to use source control systems that are open source and freely available.

share|improve this answer
add comment

Your Answer


