Starting Team Development of Databases
Before you can manage changes to a database schema, you first create a database project, and then you import objects and settings from the database that you want to manage. A database project contains the object definitions and deployment scripts that you would need to create a separate instance of that database or to update an existing instance. Because a database project is an offline representation of the database, you can put it under version control and then deploy iterative changes to an isolated development environment. Team members can test their changes independently and then share those changes with the team after they are fully tested. By taking this approach, you help regulate the quality of the database code before you deploy it to a production environment.
Specifying a Type of Database Project
When you create a database project, you specify the type of project that corresponds to your version of SQL Server. For example, if the database that you want to manage is based on SQL Server 2005, you specify either SQL Server 2005 Database Project or SQL Server 2005 Wizard. If you use the wizard, you can not only create the project but also configure some build and deployment settings and import database objects and settings at the same time.
Importing Database Objects and Settings
After you create the project, you can import the objects and settings from a database instance or from a script. When you import a database, its object definitions are validated, and statements that cannot be parsed are put in the ScriptsIgnoredOnImport.sql file. If you import object definitions that reference objects that no longer exist, you must resolve those errors before you can build and deploy the project. For example, you might import a stored procedure that references a table that no longer exists. To resolve the error, you could remove that stored procedure.
You might need to spend a lot of time resolving such errors when you import a large schema. However, team members cannot unknowingly introduce additional errors of this type as they update the schema in Database Edition. When they modify and save any object definition, all changes are validated so that team members can fix them immediately and avoid deploying those errors to a live database. After you resolve warnings in object definitions, you should also consider analyzing your database code for design issues, naming issues, and performance issues. For more information, see Improving Database Code with Static Analysis.
Common Tasks
Depending on the development methodology of your team, you might perform the tasks in the following table when you start team development of your database project:
Common Tasks |
Supporting Content |
|---|---|
Learn more about database projects: You can read about the basic concepts of how to manage schema changes by using database projects. |
|
Get hands-on practice: You can follow an introductory walkthrough to become familiar with how to create an isolated development environment, so that your changes will not conflict with changes from other team members. |
|
Put an existing database schema under version control: You can create a project, configure project settings, and import a schema by using the database project wizard. You can also create an empty project if you want to import the schema later or if you do not have permission to access the database from which you want to import the schema. After you import the schema, you can add the project to version control. |
Related Scenarios
Starting Team Development of Databases That Reference Other Databases
Starting Team Development of Databases that Reference Shared Server Objects
Starting Team Development of Databases That Reference SQLCLR Objects
Starting Team Development of Large Databases
Starting Team Development of Databases that Use XML Schema Collections