You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I quote: "Carefully consider before using this approach in production. Experience has shown that the simplicity of this deployment strategy is outweighed by the issues it creates. Consider using SQL scripts instead."
So what is the raison d'etre of this product? What is the point in spending any time at all developing migration scripts if ultimately we also have to spend time developing SQL scripts to migrate production servers?
I understand the caution and the recommendation not to include the scripts in the primary application but surely the migration mechanism can form part of a separate application/process to upgrade production servers under controlled conditions?
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
ID: 06b35eff-79e4-2068-6d1c-f9079d43f903
Version Independent ID: 6c575b10-048c-349c-397e-0d9c11d47235
I quote: "Carefully consider before using this approach in production. Experience has shown that the simplicity of this deployment strategy is outweighed by the issues it creates. Consider using SQL scripts instead."
So what is the raison d'etre of this product? What is the point in spending any time at all developing migration scripts if ultimately we also have to spend time developing SQL scripts to migrate production servers?
I understand the caution and the recommendation not to include the scripts in the primary application but surely the migration mechanism can form part of a separate application/process to upgrade production servers under controlled conditions?
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
The text was updated successfully, but these errors were encountered: