How can we help you today? How can we help you today?
way0utwest
This might help. https://voiceofthedba.com/2018/11/02/adding-sql-search-to-azure-data-studio/ / comments
This might help.https://voiceofthedba.com/2018/11/02/adding-sql-search-to-azure-data-studio/
0 votes
Ah, so in the release steps, there is no analysis of the code, just a review of which migration scripts need to be deployed. The scripts are already set and the parsing of changes is done in development to build those scripts. A pre-deployment to intermediate environments is what should be used to catch this type of issue. I'm looking for something that would help here, but I think this is problematic from our view in that we do perform some drops for procedures in some scripting. Anything that's pre-SQL2016 can't handle CREATE OR ALTER, and the standard pattern we have is: if exists() drop, create. I think that the solution I'd lean towards here is to fail builds that contain drops, not wait until the release stage. My initial thought is to capture a list of tables and store this in my db. This would essentially be a way of auditing the state of the db. If you maintained this in your existing prod (and qa/staging/UAT, etc), then you'd know what objects exist. After a build, I'd run a left join from this table to sys.objects, and if things were missing, I'd then fail the build or return an error to the user. This would help me detect drops. You could easily expand this type of check into views, procs, functions, users, etc. / comments
Ah, so in the release steps, there is no analysis of the code, just a review of which migration scripts need to be deployed. The scripts are already set and the parsing of changes is done in develo...
0 votes
Incredibly different than .NET. Here are some thoughts, mostly distilled from experience (pre-SCA, DLM) and from working with some clients. First, branching is problematic in databases, mostly because chronology matters. The order of operations for single objects matters, but also potentially across objects (dependencies, name resolution, etc.). Therefore we need to manage the order of migration scripts. Second, switching branches for a state based entity, like a table, is an issue. This is because we may have holes (columns /tables removed in the new branch) or buckets (columns added in the new branch) and we have to decide what to do with data. How do we populate or save the data. Switching back is a bigger issue. Therefore, branches for databases need to be super short lived. We limit .NET branches to 1 week, but I'd really limit database branches to 1 day or less. Otherwise, the changes made by other developers can grow to be unmanageble in merges. My advice here would be this. FB1 -> commit triggers FB1 build. -> failure, let developer know                                                        0-> success, initiate PR for dev branch.                                                          on success, close branch, re-initiate, with new db build if new work needed. FB2 -> commit triggers FB2 build. -> failure, let developer know                                                        0-> success, initiate PR for dev branch. Dev PR approved, meaning code review -> triggers integration build                                                    -> failure, notify developers to resolve potential merge conflicts. This could be altering the FB1 or FB2 commit or renaming/renumbering migrations scripts. Must trigger new PR/DevBranch build.                                                  --> success, scripts now are fairly immutable. I say fairly, as there might be a need to cherry pick commits from DevBranch-> Master for release. Why? Perhaps I need an index rebuild moved before/after other changes. Or I want a risky change separated. When I move from DevBranch -> Master, I pull over (merge) certain changes as needed to move inflight work to a release. Personally, I think we should really develop on master, with branches pulled for features AND releases. At points in time we create a release branch, potentially chrry picking, but we know which branches give us a point in time review of either work being done (short lived) or release state (medium lived). This potentially lets me go back to a release branch for a hot fix, while there are still in-flight changes in master. Does this make sense? I think you need a second CI build to manage this. / comments
Incredibly different than .NET.Here are some thoughts, mostly distilled from experience (pre-SCA, DLM) and from working with some clients.First, branching is problematic in databases, mostly becaus...
0 votes