Database development policies

Applies to
ApexSQL Source Control

Summary
This article explains how to work with the Database development policies feature in ApexSQL Source Control.

Description
ApexSQL Source Control provides a possibility to establish and enforce behaviors among developers regarding source control, for example mandatory locking of files on checkout. These rules are enforced in ApexSQL Source Control via Database development policies. ApexSQL Source Control has three policies implemented: Optional, Permissive and Restrictive. The feature is available in the shared database development model only.

Optional policy

This is the policy set by default. When the Optional policy is set, each developer can work on an object without the need to perform a check out or lock before editing:

If developer A makes changes to an object, they will be overwritten if developer B makes additional changes.

Having the optional policy enabled (which is in reality having no policy) requires the team to communicate outside ApexSQL Source Control in order to avoid overriding each other’s changes

Permissive policy

By setting the Permissive policy, a requirement is created that each object must be checked out before editing:

An object can be checked out from the Object Explorer pane, by choosing the Check out option from the context menu:

As soon as an object is checked out, it can be edited. To verify that an object is checked out, note the icon on an object. A green check mark indicates that it has been checked out by you:

If an object is not checked out, (while the Permissive policy is active) ApexSQL Source Control prevents any developer to make any changes against it, enforcing the requirement that it must be checked out first.

In such cases, the following warning dialog will appear:

It is possible, to check out an object that is already checked out by someone else

When checking out an object already checked out by someone else, a dialog appears with the information about the user who checked out an object. To override the check out, click the Yes button:

Restrictive policy

The Restrictive policy requires that the object must be locked before editing. Note: the Lock operation cannot be overridden:

While the Restrictive policy is enabled, each developer must check out an object with lock before editing.

If an object is checked out with lock, a developer who performed this operation against an object is the only one who can edit an object after that.

To perform a check out with lock on an object, right click it in the Object Explorer pane and select the Check out and lock option from the context menu:

When an object is checked out with lock, the object icon will be changed in the Object Explorer pane, to reflect the appropriate status:

If an object is not checked out with lock, (while the Restrictive policy is active) ApexSQL Source Control prevents making any changes against an object, enforcing the requirement that the object must be checked out with lock prior to editing. The following warning appears:

If another developer checked out an object with lock, it cannot be edited by any other developer after that.

Since the Lock command cannot be overridden, there is no possibility for the rest of the team to override a lock, until it is released by a developer who performed the Lock operation, or until changes made against an object are committed.

Q: What is the scope of a database policy?

A: Database development policies are applied against the entire database.

Q: Will database development policies be applied on objects that are not included in source control?

A: Yes, policies will be applied against all database objects, even if they are not included in the source control.

Q: Is there an option to change the scope of a database policy?

A: Yes, using the Global settings filtering from the add-in options, objects that do not need to be version controlled can be excluded, and such objects will not be affected by database policy settings:

Q: Do I need to use a database policy if I’m the only one who works on a database?

A: No, database development policies are designed for a team working on the same database.

Q: Is there a way I can set a group of users that must follow the rules set by the database policy?

A: By default, all users are included in the scope of the policy.

Q: Can I apply database development policies while using the dedicated development model?

A: No, database development policies can be applied only if the shared database development model is used.

Q: Will users who did not install ApexSQL Source Control be affected with database policy settings, in case they are working on a database where policies are applied?

A: Yes, all users will be affected by database policy settings no matter if ApexSQL Source Control is installed on a local machine, except for objects that are excluded in the Global settings tab.

Q: Is there a quick overview of the status of all objects, so that I can find if an object that I want to work on is checked out or locked, without searching it in the Object Explorer pane?

A: Yes, ApexSQL Source Control has the Object status feature implemented. To see the status of all objects, right click a database, and from the context menu, select the Object status option:

A list of all objects that are included in source control will be shown, along with the status of each object and the user who changed the status: