Apex SQL Tools Blog: Source Control Mapping in Edit

One of the most used features in ApexSQL Edit has always been the ability to integrate with Source Control systems and map database objects to Source Controlled items. However, this has never been easy and has always had some issues in terms of trying to explain exactly how the process works. It was also difficult for teams to share and use the same mappings or provide re-use across machines.

Well, now those days are behind us...

With the changes to ApexSQL Edit in the next release related to the Source Control integration, we have totally rewritten the entire Source Control inegration to make it easier to setup, to use, and more powerful.

Source Control integration will now be at a higher level and will allow easier sharing of mappings across different machines so that developers can share mappings and also so that mappings can be shared across different environments such as a DEV or PROD machine.

The mapping process is now wizard based, starting with the following page:

The process will then ask the user if they want to create a new project or add an environment to an existing project. The Project concept for Source Control integration now allows you to basically setup the mappings at a project level and then have different environments (eg. Dev1Machine, Dev2Machine, DevUnitTest, QATest, Production, etc) within the project that will all share the same mappings so that the objects will automatically inherit the mappings that are defined on different environments. This will allow the user to easily see which items may be on the DEV environment but don't yet exist on the Production environment.

When creating a new Project, the wizard will ask the user for information such as the project name, the environment name for the current connection, and the Source Control system that will be used.

Once the project, environment, and Source Control information have been set, the user can then specify the default Source Control projects/folders to use for each specific database type (currently table, view, procedure, function, and trigger are supported although we will be adding other types as well). This location will be where items of that type will be added when the user adds new items from the schema explorer.

The final step in the project setup process is setting up the mappings for the database objects. This can be done in 3 different ways. You can choose to script items from the database to the Source Control system, have Edit attempt to map objects automatically to existing items, or manually map items.

Once this step is done, the database is now mapped and a project will be created along with the initial environment. This information can either be stored in the default local data store that Edit uses or stored in a centralized SQL Server that the user defines. If using a centralized SQL Server, then other users using the same centralized server can choose to work under the same project and thereby get the same mappings for objects simply by selecting the project and then entering in the name of their particular environment (ie. AshtonDevSQL). They will then automatically have items mapped for the database and will share any further mappings that they or other developers define.

This new feature will also make it easy to get reports on what is mapped, what actions have been performed such as what items were mapped as well as what items have been applied to which environments when the application methods are used to apply items. It will also allow developers to easily apply new items that other developers have mapped to their own environments or to upstream environments like BLD or PROD.

This feature will be available in the next version of ApexSQL Edit which should be available soon. Existing mappings will also be converted so that users will be able to take advantage of the feature even if they have existing mappings for databases.

Labels: ApexSQL Edit

posted by Ashton Hobbs on Wednesday, November 22, 2006

0 Comments: