On 10/1/2011 8:26 PM, Grant wrote:
Ouch. If testing is done on the developer's local machine, he will need a
full working copy and it will be impossible to restrict read access to one
or a few files as I had planned to do with path-based authz. Instead, could
I check out a working copy of the repository to a staging machine of mine
and allow the developer to check out only one or a few files as defined via
path-based authz, thereby requiring him to commit his changes and update the
staging machine's working copy in order to test his changes and debug? I
suppose each developer would require a separate staging machine to work this
way.
If a developer has access to only part of the Web site, he/she will be able
to test only part of the Web site. That is not scalable in the long run.
As soon as one part of the Web site relies on another for functioning, your
development methodology will break.
Your post has given me a lot to think about, but I don't agree that
one part of the website relying on another part means the development
methodology will break. Whenever something needs to be worked on, I
would give the developer access to all necessary files. If it turns
out I didn't grant access to enough files, I can always add one or
more files to the accessible list. Can you give me an example of a
situation that would break my proposed development methodology?
Easy: you go out to lunch right before your developer finds he/she
needs a file. Now you're paying for someone to sit and wait for you to
come back from lunch. Any time you are not immediately available to
change the permissions, you are losing money.
"Not scalable" means that the management burden will grow tremendously
as the amount of code in your Web site grows. You may be willing to
adjust the permissions list regularly if there are only 100 files, but
what if there are 1,000? Or 10,000? What if there are 20 developers?
Or 50? What if some of them are in Europe, or India? For every
project, for every developer, you are going to have to build a list of
files to access, and that list is likely to need tuning as the project
proceeds.
Limits on source code access are very common; for example, a developer
working on analysis software doesn't need to see the internals of the
GUI (and vice versa). Usually the source code for different products is
in different directories, making access control manageable. It requires
some work to partition code, but the way of thinking it induces is good
for Software Engineering (as opposed to hacking something together).
I'm not a commercial Web site developer, but I would expect that any
feature which involves a fair amount of computation is going to require
quite a bit of code. You're going to want to isolate that code (with
APIs etc.) for testability anyway; why not move it into a separate
directory?
Look back at the statement you made above: you are willing to make
testing more difficult in order to protect your source code. If testing
is harder, less will be done - it's human nature. That could easily
degrade the quality of the product to be delivered. Most companies
accept the theft risk (using the legal system as a hammer) in order to
get a higher quality product. That's why you're finding so little
support for your methodology in the tools.
--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA
