SQL Server : Replicate Schema changes to another database

To me, this does not seem like a good idea.

If you make a change in the development environment that breaks the system, you would immediately break the testing environment too. This would be bad.

If you make a code change in the development environment, and make the database changes to support it, if the database change is immediately replicated, you would have code and database that were out of sync, and again, could conceivably break the test environment.

A better approach would be to use a version control system, to batch your changes to data and code together, and use a manual system, or continuous integration, to deploy them together to the test environment.

You can use Visual Studio schema compare to store database structure changes as part of your project

Instead of automatically syncing changes done on one database to another, use some kind of source control for your database and deploy the changes to both environments manually (or automatically).

Source control have all kinds of positive impacts and should become a habit anyway. Even for your databases.

I suggest using Liquibase due to it being free open source and quite flexible.

Since I do not really like triggers on the essence that they make changes without my knowledge, I would suggest to make a procedure initialize each database. So when you include some new code to your schema make sure to include it also into the initializing process.The replication should start always with this process.

Do you make changes on code, on both DB? If you have a master-slave relation you only need to initialize the slave DB. Otherwise, in case of master-master you should keep with some sort of versioning.