Activity overview
Latest activity by pmenard
Thanks @way0utwest >write a script in the pre area I think I'm still leaning towards keeping the drop controls outside of SQL scripts for now. >Loading a set of test data is something you need to consider Absolutely [image] We're in the midst of migrating an existing home-grown deployment system to SCA... Primary development occurs within a personal environment, and gets built from scratch with basic metadata. Test-specific data is loaded only as necessary. For non-prod shared environments, we have mixtures of fully redeployed and long-lived/migrated databases. We drive test-data loads from the tests scheduled against the particular database. ...as such, test-data will likely continue to be non-SCA, though now that you have me thinking about it... 💡 I do wonder if additional, data-only, SCA projects could be paired with our integration tests to package data & tests side by side. 🤔 ...that won't be until later this year though [image] / comments
Thanks @way0utwest >write a script in the pre areaI think I'm still leaning towards keeping the drop controls outside of SQL scripts for now.>Loading a set of test data is something you need to con...
@way0utwest >integration/qa/staging/etc environment? Or a dev environment? Automation => all common environments, dev -> prod. Only lower environments ever get an automated 'drop' database, however. UI => local/personal dev environments / comments
@way0utwest >integration/qa/staging/etc environment? Or a dev environment? Automation => all common environments, dev -> prod. Only lower environments ever get an automated 'drop' database, howeve...
Re-Baselining via command line
Has anyone attempted to automate re-baselining?It seems as though SqlCompare can perform the tough work for us,.\SqlCompare /server1:MyServer /database1:MyDatabase /empty2 /scriptFile:"{path}\basel...
Thanks Andrea [image] For the devs, A toggle in SCA's UI would be great. There are limited options for automating such for the devs (a new configuration copied from debug, with an added drop task?). As for automation, It has to run somewhere, and with a push to have consistent deployment tooling across environments, the drop code is somewhere inclusive to production deployments. It would be great if SCA had an argument which could be driven from configuration so roll-your-own wasn't necessary. But I agree, if my current choices are to put it in conditional SQL or our overall mgt scripts, the latter wins. Thank you! / comments
Thanks Andrea For the devs,A toggle in SCA's UI would be great. There are limited options for automating such for the devs (a new configuration copied from debug, with an added drop task?).As for ...
Best practices for automating deleting a local/development database
During full deployments to, logically transient, non-prod environments we want databases to be recreated from scratch every time. For that matter, not every dev will be concerned with deploying mi...