Can I create the nuget package without create a database?

Hi Team,
I'm using the Azure DevOps plugin to create a build and release.

I feel like create the temp db during the build process is just for validating purpose?

Is there any way to by pass it? Many thanks
Tagged:

Answers

  • Hello,

    Yes, the build process creates a database for validation purposes. If you skip this step, you would lose assurances that the code you have committed is valid SQL that is suitable for a deployment.

    You have the option to have the build dynamically create the database for this purpose and drop it after, or if it is more convenient you can hardcode a name for the database and reuse an existing database for each build. (The database will be "cleaned" so validation can succeed.)

    Can you explain why you would like to skip this step? Is there some barrier preventing you from using a database for this purpose, or some problem that you are hitting?

    Cheers,
    Kendra
    -------------------------------
    @Kendra_Little
    Product Manager at Redgate
  • yeweinanyeweinan Posts: 3 New member
    edited December 15, 2020 11:57PM
    Hello,

    Yes, the build process creates a database for validation purposes. If you skip this step, you would lose assurances that the code you have committed is valid SQL that is suitable for a deployment.

    You have the option to have the build dynamically create the database for this purpose and drop it after, or if it is more convenient you can hardcode a name for the database and reuse an existing database for each build. (The database will be "cleaned" so validation can succeed.)

    Can you explain why you would like to skip this step? Is there some barrier preventing you from using a database for this purpose, or some problem that you are hitting?

    Cheers,
    Kendra

    Hi Kendra,

    Thanks for the explaining but we really hope if we can have an option bypassing it. When deploying, we are using transactions so that if there is an error, we will get it eventually. Make us feel that the extra safeguard is redundant in most of the case. 

    The most important reason for us is time. We have a large DB so every time the build cost 10+ mins, and developers really want them fast pace into our Dev env. 

    We hope that we can have an option so that we can only enable the DB validation when we try to deploy to our Prod, and enjoy your assurance feature when we need :)
  • Hello,

    Sorry for the slow response, and thanks for the information that build time sounds like it is a pain point.

    Can I ask if you are using SQL Change Automation to deploy a SQL Source Control project, or is it a SQL Change Automation project that you are deploying with SQL Change Automation?

    Thanks,
    Kendra
    -------------------------------
    @Kendra_Little
    Product Manager at Redgate
  • And I've just found that I can answer this more fully before knowing which "authoring" tool you are using.

    There is a way that you can skip the build process if desired, by using the New-DatabaseProjectObject powershell cmdlet. Some notes on this:

    • You would implement this using a PowerShell step in Azure DevOps, instead of the graphic plugin. The documentation page linked above has examples for doing this (one example is for a SQL Source Control project, one is for a SQL Change Automation project)
    • The build process adds some additional value in terms of validation. It also creates a snapshot of the desired target schema which is used for things in the "Create Release Artifact" process, such as the changes report and the drift report. That means that if you skip the build process, you'll still have the ability to deploy, but won't have these extra features.
    • As mentioned above, this also skips the validation process. 
    I think that what you are mentioning above is that you might have more than one kind of build pipeline, and only run the "full" build when you are generating a NUGET package that is planned to be deployed to production? 
    I'm not entirely sure what your branching strategy and development database workflow is, but combining the two approaches might work, and then you would still get the changes report, the drift report, etc for your production release artifacts.

    Cheers,
    Kendra
    -------------------------------
    @Kendra_Little
    Product Manager at Redgate
Sign In or Register to comment.