Minimal Set of Rules for Team Development with Visual Studio.NET and VSS
I'm trying to pare this down to just the absolute streamlined minimum, here's what I have so far. If you have comments, feel free to contribute:
Minimal rules for Team Development:
1) Learn how to add a solution / project to VSS and make sure you don't screw up. Everybody needs to be able to be working from the same solution tree, and a new developer should be able to get latest on a solution and successfully build it within 10 to 20 minutes. Shared library references should be in the solution as Solution Items, and they should be able to be checked out with the Solution. If a shared library needs to be changed, it should be checked out and the new library saved over it, then checked back in so everybody can have the same versions.
2) All references should be PROJECT references if the project is available, and the project should be retrieved from VSS and included in your solution.
3) All build output from EVERY project should go ONLY into it's respective /bin folder. That can be /bin/release or /bin/debug depending on configuration. DO NOT ALTER THE DEFAULT BUILD OUTPUT FOLDER!
4) If you are going to change something ALWAYS ask "What will this affect?" It is your responsibility to keep in contact with the other developers on the team and keep them informed of any changes you propose, and to ensure that any related code that needs to be modified gets changed. And, the best time to do this is BEFORE you make any changes.
5) Always check in your code as soon as it is ready to build. Don't keep code checked out any longer than necessary. If you need to keep code checked out for a long while, you can comment out your changes and check it in, and use the "Keep checked out" option from Visual Studio to keep working on it. Learn how to use Merge.
6) if you add a new class or web page to a project, you need to CHECK OUT the project before adding it, then check in the project so that the project will now include your new file(s). Same with adding a project to a Solution.
7) All actions involving VSS-based code should be done ONLY from within the Visual Studio IDE.
8) All developers are encouraged to take the time to read the Team Development Guide.
Minimal rules for Team Development:
1) Learn how to add a solution / project to VSS and make sure you don't screw up. Everybody needs to be able to be working from the same solution tree, and a new developer should be able to get latest on a solution and successfully build it within 10 to 20 minutes. Shared library references should be in the solution as Solution Items, and they should be able to be checked out with the Solution. If a shared library needs to be changed, it should be checked out and the new library saved over it, then checked back in so everybody can have the same versions.
2) All references should be PROJECT references if the project is available, and the project should be retrieved from VSS and included in your solution.
3) All build output from EVERY project should go ONLY into it's respective /bin folder. That can be /bin/release or /bin/debug depending on configuration. DO NOT ALTER THE DEFAULT BUILD OUTPUT FOLDER!
4) If you are going to change something ALWAYS ask "What will this affect?" It is your responsibility to keep in contact with the other developers on the team and keep them informed of any changes you propose, and to ensure that any related code that needs to be modified gets changed. And, the best time to do this is BEFORE you make any changes.
5) Always check in your code as soon as it is ready to build. Don't keep code checked out any longer than necessary. If you need to keep code checked out for a long while, you can comment out your changes and check it in, and use the "Keep checked out" option from Visual Studio to keep working on it. Learn how to use Merge.
6) if you add a new class or web page to a project, you need to CHECK OUT the project before adding it, then check in the project so that the project will now include your new file(s). Same with adding a project to a Solution.
7) All actions involving VSS-based code should be done ONLY from within the Visual Studio IDE.
8) All developers are encouraged to take the time to read the Team Development Guide.
OK Mike thanks. Comments are enabled on the UnBlog so that you can comment! (DOH).
ReplyDeleteI have one issue with the rules. Presently Visual Studio's interface to VSS doesn't include everything you might want to do with a project, such as defining labels, reverting to a specific instance, etc.
ReplyDeleteAre you suggesting that these operations be avoided entirely?