Conditionally built objects and static data from a master

cmaslen

Hi,

We have a couple of related scenarios where we'd like to maintain different versions of source controlled objects.

The first scenario is static data. For development we have a set of static data that is only appropriate for a local environment but not for test or production. An example here is environment specific configuration data that resides in the database. Another example is some test data that could be under source control for automated integration tests.

The other scenario is database objects. In our case we develop a platform product that uses some core tables. We also develop applications for the platform that have their own tables. We would like to build a database from source control for a given application or combination of applications depending on factors such as what the client has installed or what the developer is supporting.

Thanks in advance,
Christian

Sian.Williams

Many thanks for your suggestions, I think they are reasonable however I don't believe they've been requested yet.

It would be great if you could add them to our uservoice site, where other users can vote for them to be added in the future.

http://redgate.uservoice.com/forums/390 ... ce-control

Thanks

David Atkinson

cmaslen wrote:

Hi,
The other scenario is database objects. In our case we develop a platform product that uses some core tables. We also develop applications for the platform that have their own tables. We would like to build a database from source control for a given application or combination of applications depending on factors such as what the client has installed or what the developer is supporting.

Thanks in advance,
Christian

Christian,

SQL Compare has a filter feature that lets you specify at a very granular level which objects to consider. Would it work for you to save a SQL Compare project for each client to use as the deployment mechanism?

David Atkinson
Product Manager

David Atkinson

cmaslen wrote:

For development we have a set of static data that is only appropriate for a local environment but not for test or production. An example here is environment specific configuration data that resides in the database. Another example is some test data that could be under source control for automated integration tests.

Regarding this issue, it's actually one that our internal web team also have. They solve this using this automated process.

- 'gett' the scripts folder to a temporary folder using their source control command line
- sync the static data folder to their integration database using sqldatacompare.exe
- copy a 'test data' scripts folder on top of the temporary scripts folder
- sync the test data folder to their integration database using sqldatacompare.exe

That's pretty much it.

Using this technique you can have as many test data folders as you like, representing different clients or test scenarios.

David