How can we help you today? How can we help you today?
spakh
We currently put production definition of the synonyms in SVN source control and have a separate script that we run on dev and test machines after updating the dev and test databases from SVN. This way we do not accidentally promote dev or test synonym definitions into production. This process can cause issues if a developer by accident checks in the development version of the synonym by accident if the checkmark is not deselected during the checkin process to SVN. This will not get caught in test environment since the test environment uses the same definition as the dev environment. Only when the script is promoted to production will the problems appear. So we have to double check our synonyms on production servers and in SVN to make sure nobody checked in the wrong definition into SVN. This also forces us to continue to put together update script files to give to our DBA's to update the prod database. DBAs do not conern themselves with what is in the script. They just apply them. If the script breaks, then the test process is improved to make sure that does not happen again. In this case the test process must include the check of synonym definitions in source control. Which is not what the test team should be doing. So, I was hoping for the SQL Source Control to provide mechanism where different synonym definitions can be assigned to the same object and extract the appropriate one depending on the target environment. Maybe there is a better solution. Possibly through CI (continuous integration). We currently do not have CI setup for our database changes, but it is on the wish list [image] . / comments
We currently put production definition of the synonyms in SVN source control and have a separate script that we run on dev and test machines after updating the dev and test databases from SVN. This...
0 votes