SQL Source Control 6

Teams using the shared model

The shared development model is where developers work on a single copy of the database.


Setting up

To start with, everyone installs SQL Source Control on their machine. This means they can all commit their changes.

Then, one person (it doesn't matter who) needs to link the database to version control and make the initial commit.

Workflow

Once the database's schema has been committed to version control, your team can start developing changes.

The workflow should look like this:

  1. Develop your changes.
  2. Commit your changes using the Commit tab.

There's no need to use the Get Latest tab, because all the changes are already in the database: that's where they're developed.

History

The repository will contain everyone's changes. If you want to see how the database has changed, or see the history of changes to an object, you can view the source control history.

Conflicts

Sometimes, when two team members are working on the same object, there can be conflicts.

The best way to deal with this is to use object locking. You can lock an object when you start working on it to temporarily prevent other team members from changing the same object.

For information on how this works, see Lock an object.

Benefits

  • You only need one development database, so fewer instances of SQL Server.

Drawbacks

Switching to dedicated development

To switch from shared to dedicated development, each developer on your team needs to:

  1. Unlink the database from source control.
  2. Create an empty database. This will be the developer's dedicated copy.

    For easy identification, you should name the database something similar to database you're about to copy.

  3. Link the new database to the source control repository that the shared database was linked to.
  4. Go to the Get latest tab and get the changes.
    The new database is updated with the changes from the original database, creating a dedicated copy.

Didn't find what you were looking for?