Comments
Sort by recent activity
These are some awesome new capabilities. Kudos to the team. :-) / comments
These are some awesome new capabilities. Kudos to the team. :-)
After running git clean, did your issues persist? (I'm assuming so). At this point I think I'm out of suggestions. I suspect it's one for Redgate tech support. Good luck! / comments
After running git clean, did your issues persist? (I'm assuming so).At this point I think I'm out of suggestions. I suspect it's one for Redgate tech support. Good luck!
It should do. Most of my clients use Git repos that contain multiple DBs. Have you tried opening a command prompt to the DB directory and running a git status and a git clean? Does that give you any more feedback or provide any unexpected surprises? / comments
It should do. Most of my clients use Git repos that contain multiple DBs.Have you tried opening a command prompt to the DB directory and running a git status and a git clean?Does that give you any ...
So the entire DB is showing as a change... What sort of change? New objects? Modified objects? Deleted objects? I'm assuming you were expecting them to be in sync? / comments
So the entire DB is showing as a change... What sort of change? New objects? Modified objects? Deleted objects?I'm assuming you were expecting them to be in sync?
Is there a redgate.ssc file at the exact path you committed to? Does the code in the repo match the code in the DB? / comments
Is there a redgate.ssc file at the exact path you committed to?Does the code in the repo match the code in the DB?
Have you tried deleting the local repo and pulling down a fresh clone? (Obviously commit and push or otherwise save any local updates/commits before deleting the local repo to avoid losing work.) / comments
Have you tried deleting the local repo and pulling down a fresh clone?(Obviously commit and push or otherwise save any local updates/commits before deleting the local repo to avoid losing work.)
Do you by any chance have any of the files open/selected/locked in any other programs? (E.g. file explorer/text editor). Do you have full access to the filesystem where your git repo is located? / comments
Do you by any chance have any of the files open/selected/locked in any other programs? (E.g. file explorer/text editor).Do you have full access to the filesystem where your git repo is located?
Are you using a SQL Source Control projects or a SQL Change Automation Project? In either case, I'd create a post-deploy script with logic along the lines of: IF (Env is Dev) { Set up these dev users } IF (Env is prod) { Set up these prod users } Alternatively, for simplicity you may prefer to extract your dev/prod user security scripts into separate scripts/sprocs that are siimply referenced from your post-deploy script. In this way your security is version controlled in an environment specific manner. If using SQL Change Automation you could deternmine the environment using a SQL environment variable. If SQL Source Control you will probably either need to hardcode server name (I know, yuk) or use a config table in the DB with data specifying whether the database should be set up in the dev and/or prod security configuration (make sure security on this table is locked down in prod to ensure appropriater access controls are maintained). / comments
Are you using a SQL Source Control projects or a SQL Change Automation Project?In either case, I'd create a post-deploy script with logic along the lines of:IF (Env is Dev) { Set up these dev us...
There are a couple of things you could do to get around this issue. Neither are perfect, but they should work. 1. Move to a migrations based approach. If your developers use a SQL Change Automation project, rather than a SQL Source Control project, the deployments will be based on scripts that were curated by the developers so you would avoid unexpected column drops. 2. Move to a master == production branching strategy, and set up a process to detect and automatically add changes made in production directly to master. If this ever fails, you will get a broken build to alert you to an issue. All development changes would need to be done on a branch and merged with master when they are ready to be deployed. Obviously these are both avoiding the issue rather than fixing it. In an ideal world the 3rd party product updates would be going through source control too. / comments
There are a couple of things you could do to get around this issue. Neither are perfect, but they should work.1. Move to a migrations based approach. If your developers use a SQL Change Automation ...
How about this? Master = Production. Dev work is done on feature branches on development databases. (Ideally separate databases per feature/developer. Have you looked at SQL Provision?) On demand, plus on a periodic basis (e.g. at the weekend/at end of sprint) the following is automated: From your post above: 1) restore latest prod on the dev server as <DB>_FROM_PROD_<yyyMMdd_hhmmss> 2) rename the dev <DB> to <DB>_OLD 3) rename the <DB>_FROM_PROD_<yyyMMdd_hhmmss> db as <DB> My additions: 4) <DB> is compared with master in source control, any updates are automatically committed as "DRIFT CORRECTION". This should get all 3rd party and other updates on prod into master. When this occurs you may want to trigger some sort of notification to your team so they can review the updates. 5) master is automatically merged with all branches. If this merges nicely, wonderful, your development changes do not conflict with production drift. If this causes a merge conflict/build error, your developers need to review the problem before they can push to production. To release code to production: 1) Automatic check that production and master are in sync. If not, abort with a drift warning. Resolve drift by updating master and try again. 2) Master is merged into feature branch to ensure there are no merge conflicts. 3) Any automated tests are run to verify the merged code. (If you don't have tests, write some.) 4) Feature branch is merged into master. 5) Master is deployed to production. 6) Master is merged into any other feature branches. / comments
How about this?Master = Production.Dev work is done on feature branches on development databases. (Ideally separate databases per feature/developer. Have you looked at SQL Provision?)On demand, plu...