Avoid scripting DeploymentMetadata in Deployment script

devrokdevrok Posts: 4 New member
Hi all!
After searching for hours, I am not able to find any options to avoid the scripting of the DeploymentMetadata stuff in the deployment script. We only want to script the changes and the migration scripts without this additional logging. The created "diff script" should finally be used to be delivered to the customer. Did I miss something or is it impossible to disable it.
Many thanks in advance  :)
Tagged:

Best Answers

  • Alex BAlex B Posts: 991 Diamond 3
    Accepted Answer
    Hi @devrok,

    The DeploymentMetadata is necessary when using the migration scripts.  This is what lets the product know what migrations have been run so that if you deploy to this target again, it does not attempt to redeploy the migrations it already has deployed - see this page for more information.

    If you want these to be removed you will need to use the "Ignore migration scripts for databases" option so that the migrations are not deployed and therefore the DeploymentMetadata is not needed.

    Kind regards,
    Alex
    Product Support Engineer | Redgate Software

    Have you visited our Help Center?
  • devrokdevrok Posts: 4 New member
    Accepted Answer
    Alex B said:
    Hi @devrok,

    The DeploymentMetadata is necessary when using the migration scripts.  This is what lets the product know what migrations have been run so that if you deploy to this target again, it does not attempt to redeploy the migrations it already has deployed - see this page for more information.

    If you want these to be removed you will need to use the "Ignore migration scripts for databases" option so that the migrations are not deployed and therefore the DeploymentMetadata is not needed.

    Kind regards,
    Alex
    Hi Alex!
    Thank you for the quick response. It sounds pretty logic that this metadata is necessary for executing the scripts in correct order and only for one time.
    The plan was to use SQL Compare combined with SQL Source Control to create schema and migration scripts automatically and ready to deploy to the customer without any additional data. Although I'm not sure if we can use your tools as they are, I want to thank you again.
    Have a nice day!!  :)

    devrok

Answers

  • devrokdevrok Posts: 4 New member
    Alex B said:
    Hi @devrok,

    The DeploymentMetadata is necessary when using the migration scripts.  This is what lets the product know what migrations have been run so that if you deploy to this target again, it does not attempt to redeploy the migrations it already has deployed - see this page for more information.

    If you want these to be removed you will need to use the "Ignore migration scripts for databases" option so that the migrations are not deployed and therefore the DeploymentMetadata is not needed.

    Kind regards,
    Alex
    Hi Alex!
    Thank you for the quick response. It sounds pretty logic that this metadata is necessary for executing the scripts in correct order and only for one time.
    The plan was to use SQL Compare combined with SQL Source Control to create schema and migration scripts automatically and ready to deploy to the customer without any additional data. Although I'm not sure if we can use your tools as they are, I want to thank you again.
    Have a nice day!!  :)

    devrok
  • Hi @devrok,

    You are very welcome!

    I thought of one thing you could do - you could have a "pre-deploy" copy of each customer database where you deploy the metadata and create the deployment scripts with the migrations and metadata and then write a script to remove the metadata when you deliver it to the customer.

    This would let your pre-deploy database keep track of the metadata and allow accurate creation of deployment scripts and then also allow you to only provide the meta-data free deployment script.

    You would just need to ensure that your pre-deploy environment was in exactly the same state as the customer database (but would also maintain the metadata tables).

    I hope that helps!

    Kind regards,
    Alex
    Product Support Engineer | Redgate Software

    Have you visited our Help Center?
  • devrokdevrok Posts: 4 New member
    Alex B said:
    Hi @devrok,

    You are very welcome!

    I thought of one thing you could do - you could have a "pre-deploy" copy of each customer database where you deploy the metadata and create the deployment scripts with the migrations and metadata and then write a script to remove the metadata when you deliver it to the customer.

    This would let your pre-deploy database keep track of the metadata and allow accurate creation of deployment scripts and then also allow you to only provide the meta-data free deployment script.

    You would just need to ensure that your pre-deploy environment was in exactly the same state as the customer database (but would also maintain the metadata tables).

    I hope that helps!

    Kind regards,
    Alex
    Hi again!

    Thank you for your efforts, I did not expect that :-)

    It was planned to replace our existing self created scripting tool to reduce maintenance time and use these resources for other necessary things. Therefore it seems that we will stick to our existing solution but the decision will be made by my manager ;-)

    But great job, you are very friendly and competent.

    Kind regards, 
    devrok

  • Hi @devrok,

    Glad to help if I can!

    I understand if it won't work for you, but if you end up going with our tool and do need anything further just let us know!

    Kind regards,
    Alex
    Product Support Engineer | Redgate Software

    Have you visited our Help Center?
Sign In or Register to comment.