Protect Global Subroutines

[Sholmes]

As build master/software configuration manager for an International company, it's my responsibility to ensure the build scripts for all applications are secure and up to date. One problem we have is that several people use Visual Build to deploy files/applications due to it being an International company.

We have a sister team in Europe that uses the same development environment and support the same applications in production. Various people are responsible for deploying applications from the development server. This can cause a problem for everyone if one person makes a change to the global subroutines. Is there a way to protect them? Or better yet, allow someone to change them for their script but default back to the settings when they close the session of Visual Build...

I do have all scripts stored in SourceSafe but it would be nice to protect the global subroutines.

Thanks!

[kevina]

A couple options come to mind:
1) use NT security to only provide "write" access for these global files to the appropriate individuals
2) Use a Copy Files Action and the suggestions here (http://www.kinook.com/Forum/showthread.php?threadid=36) to copy the common global file(s) to a temp (local) location then load them from that alternate location at the start of every build. Then changes will only be persisted to the temp copy and not the global master(s)...

[pjaquiery]

This is a "can't win" problem. We faced the same issue a number of years ago and settled on an approach where we have a build context for each version of each project. Nothing is shared between contexts except global macros which only provide machine specific information. That means no global subroutines (it was a great and important feature when I asked for it, but now we don't use em).

The benefit is that each project is completely isolated from all other projects so we can fix build issues in one project without affecting any other project. The down side is that issues that are common across projects have to be fixed in each active project.

Where we have a similar class of projects we use a template context and keep that updated with any fixes. We create new projects from the context (using a Perl script to "edit" the files involved as appropriate). When we have to revisit a project, for example when there is a new version to build, we copy the most recent context and update it against the template context. Araxis Merge is a very good tool for merging the changes from the template context.

We arrived at this process after some fraught releases against deadlines where changes happening in other (at the time unimportant) projects broke the important build process in very nasty ways.

[kinook]

Store the global subroutines in SourceSafe as well. Use on of these techniques http://www.kinook.com/Forum/showthread.php?threadid=36 to load them.