Define software lifecycle environments - see the Introduction for more information on lifecycle environments and defining appropriate environments. Once environments are defined, edit the stored procedure admin.dbo.adminAddAllEnvironments as necessary to create the environment hierarchy.
Define Projects - See the Visual SourceSafe documentation in the MSDN for a general discussion of Designing and Organizing Projects. All scripts for a database must live in the same project. Furthermore, a database can only be in one project.
Allocate resources - SQL scripts tend to be quite small. On the other hand data saved in SourceSafe can consume a great deal of space. Space requirements based upon typical stored procedure size and count combined with other expected space usage provide a good starting point. Remember to plan for space within the SourceSafe repository, space for the local working folders, and SQL Server devices. As with any application, include plans to benchmark, monitor, and upgrade storage, memory and processing power when indicated.
Establish a Security Plan - Documented a plan concerning who will fill each actor's role in the dbChangeControl initiative. Who will enroll in each project, what level of access each user will have within SourceSafe, on the network, and on the SQL Servers. Permissions and access must be consistent with existing network security, SQL Server security, and assigned dbChangeControl roles.
Publish a Coding Standard - Compatibility issues between the work of different developers must be addressed at some level. A coding standard will describe and define the base level for this compatibility.
Identify process integration requirements - Do not abandon existing methodologies, process, and procedures. Develop and document a clear plan to implement version and project controls of database development efforts as tools to strengthen your kick ass development team.
Return to the dbChangeControl index page.