Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Software Configuration and Management Using Visual SourceSafe and VS .NET : Page 2

Good software development is a combination of many things that are outside of just writing great code. Turning the art of software development into the science that makes for controllable, predictable, managed software projects makes your business more productive.


advertisement
SCM Best Practices with Visual Studio .NET and VSS
Before we begin to offer a prescriptive approach to SCM implementation, we'll first define some common terms. Table 2 discusses many of the common terms and products that you will learn about in this article.

Table 2. Terms that you need to learn to be effective in your communication about SCM.

Term

Definition



Visual Studio .NET

Interactive Development Environment (IDE) for .NET application development.

.NET Framework

Base framework a.k.a. Common Language Runtime (CLR).

Visual SourceSafe (VSS)

Microsoft's SCM software.

VSS 6.0c

The client (desktop) version of Visual SourceSafe software that integrates with Visual Studio .NET.

VSS server

The server (library) Visual SourceSafe software that contains your source code, project files, etc.

System

Refers to the overall application that you are developing. Your system ultimately consists of the combined set of assemblies that you release into a production environment.

Visual Studio .NET Solution

A solution essentially represents everything you are currently working on. Visual Studio .NET uses solutions as containers for individual projects—these generate your system components (.NET assemblies). Solution files maintain project dependency information and are primarily used to control the build process.

Visual Studio .NET Project

Project files are used by Visual Studio .NET as containers for configuration settings that relate to the generation of individual assemblies.

.Net Assembly

A compiled Visual Studio .NET project taking the form of a DLL or EXE file.


You can include a project in one or more solutions, but you cannot include solutions within other solutions.
Visual SourceSafe Projects
A VSS project is a collection of logically related files typically stored in a central folder on a network share. A VSS project is similar to an operating system folder. Do not confuse the VSS term "project" with a Visual Studio .NET project. When compiled, a Visual Studio .NET project results in an assembly (DLL or EXE). A VSS "project" is simply a folder that contains files. VSS project files may include a Visual Studio .NET project of source files and a collection of Word documents and other "stuff". As a best practice, a Visual Studio .NET project should map into a VSS project folder. You will have additional VSS project folders containing other system files such as documents or binary files.

Develop and Build
Successful team-based software development projects combine many elements, processes, and roles. The two core processes are the development process and the build process. It's essential to develop working practices and project structures that work well for both processes to work in tandem.

Development Architecture
For your development process to be successful, everyone on the team will need basic tools. You should configure all developer workstations in a common, standard way in your development group (and if you can, in your whole company). Standardized workstations improve productivity by reducing installation and setup time, and if issues arise they are much easier to resolve since everyone has the same configurations. Your developers will require at a minimum:

  • Windows 2000, Windows XP Professional, or Windows Server 2003. It is a good idea (if practical) to develop your applications on the same OS as the target production operating system.
  • Visual Studio .NET IDE (including, of course, the Visual Studio .NET Framework).
  • Visual SourceSafe 6.0c (client) or another SCM product.
  • Access to a database server, either locally on each development machine or on a shared remote server.
  • Test database servers. This is the Windows server that will run Microsoft SQL Server or another database management system. In general, you'll have developers and a quality assurance team to test your software, but you may encounter times when testing could harm the database or inhibit others from testing. Developers can import the database from the test database server and continue testing (or experimenting) locally.
  • Access to a Visual SourceSafe (VSS) server. The VSS server houses your source library. You can have as many VSS libraries as you want, but you may want to keep the number to just two or three. It can become confusing to have too many.
  • Test application servers. For an n-tier application you may also need an additional server running the middle tier (business objects).
  • Test Web servers. For Web applications you will need a test Web server (IIS server). Typically, your Web server also hosts the middle tier.
  • Backup server. Do not forget this important element. Always test your restore process. Just because you can back something up does not mean you can restore it.
Hardware Requirements for Developers
Hardware prices keep dropping, so get as much as you can afford for each developer. Our minimum requirements include: 1 GB memory, 1 GHz CPU, and 40 GB hard drive.

Drive Layouts
Within an organization you want your developers to have a common drive. Project leaders often overlook this important topic. A consistent machine environment reduces new developer training, reduces overall development issues with file and assembly references, and allows programmers to move from one machine to another with no effort. Our best practice suggestions for drive layout include:

  • The C drive contains just system software. This means just the operating system, Visual Studio .NET, and all the other application software you require.
  • The D drive contains all of your project data and application data. When you retrieve data from your SCM tool, it should always go onto this drive and not the C drive. Keeping data on only this drive allows you to back up just your data without having to back up all of your application software.
  • The E drive should be a backup image of your C drive. Use Drive Image from PowerQuest or Norton Ghost to create an image of your application software and operating system.
  • Map your DVD or CD ROM drive to X: or Z: right after you install your operating system.
You may have additional drives or different letters, but you get the idea.

Layout of the "Data" Drive
Since your developers will retrieve all data from VSS, everyone's D drive will look similar. A developer's D drive will, in fact, "mirror" the VSS project layout (or a subset of a VSS project). Of course, you may have other things on the D drive, but you should map any folder in VSS that the developer needs to a folder on their D drive.

This approach has some good benefits. A common Drive D layout enables developer's to move between machines that will be very familiar. Try this approach in your shop and you will find that your developer productivity will increase. This approach lets you more easily train new hires since everyone does things the same way.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date