Comments
Sort by recent activity
Hello, Apologies that @codegumbo 's question back in September was missed. We have some automation in place to try to help us make sure we get to these questions but it looks like something went awry in this case -- we're checking into that separately. I suspect that in this case the projects are authored in a SQL Change Automation Project, so I'm going to answer that way, but please let me know if you're using SQL Source Control. The first thing that I would look at is the Drift report. Are there objects in the target database which have diverged from the code in the project? The Changes report is generated by comparing a snapshot of the expected schema at the end of deploying your project (which is captured during a build). If you've had drift occur then that comparison may show things which are unexpected -- the Drift report can help explain it. Kendra / comments
Hello,Apologies that @codegumbo 's question back in September was missed. We have some automation in place to try to help us make sure we get to these questions but it looks like something went awr...
Hi, A quick update from our side -- I've been chatting with @DanC and some others about options for this today. I've tried out the "PublishHTMLReports" plugin by Laksahay Kaushik, and I haven't been able to get it to work for the changes.html report. The plugin is designed for publishing jmeter reports specifically. It might be possible to get this to work with some code contributions to rewrite some of the key files, I am not sure. We are looking at a couple of other options:
If one is using YAML Pipelines, it is possible to add a short bit of YAML to publish the Change and Drift reports as artifacts to the pipeline. This doesn't render the report in the Azure DevOps frame itself, but it does make it very easy to click on the published artifacts associated with a pipeline run and easily download the files and open them in the browser.
If one is using Classic Release Pipelines, this requires a different approach. I believe that Classic Release Pipelines still lack the ability to publish artifacts. My colleague is looking at an option to use a fileshare in Azure to publish the latest reports from a pipeline in a way that can be included on an Azure DevOps Dashboard. This approach could fit well with Classic Release Pipelines.
Do you already have a preference about whether you plan to use "Classic" pipelines, or YAML pipelines? ( I think we will be exploring both of the options above as time allows -- there is no wrong answer here. Just curious which feels like it might be the best fit of the two, if either.) Cheers, Kendra / comments
Hi,A quick update from our side -- I've been chatting with @DanC and some others about options for this today.I've tried out the "PublishHTMLReports" plugin by Laksahay Kaushik, and I haven't been ...
Hi, quick update--- @danielpottenger was kind enough to do a video explaining this as well, it's here: [image] https://youtu.be/-rZxLCRrgmI Below the video are the same links embedded in the written answer above (just to clarify that they aren't different info / you only need to look at them from one place). Thanks Dan! Edit: corrected the link [image] / comments
Hi, quick update--- @danielpottenger was kind enough to do a video explaining this as well, it's here:https://youtu.be/-rZxLCRrgmIBelow the video are the same links embedded in the written answer ...
Thanks @cjoneslib, totally understand. Thank you for the feedback in any case, it's really useful for us to know these things. / comments
Thanks @cjoneslib, totally understand. Thank you for the feedback in any case, it's really useful for us to know these things.
Hi @cjoneslib and @Shaggy, Thank you for the feedback on this. The structure of the project file within the existing implementation of SQL Change Automation is pretty integral to the implementation, and this would be a tough thing for us to change for existing implementations/projects. We are currently working on previews of our next-generation tooling for Database DevOps, and the solution will provide the ability to deploy via migrations without needing to track a list of scripts inside a project configuration file. Would you be interested in joining our research program as we develop this tool? If so, please drop our team a note at databasedevops@red-gate.com. Cheers, Kendra / comments
Hi @cjoneslib and @Shaggy,Thank you for the feedback on this. The structure of the project file within the existing implementation of SQL Change Automation is pretty integral to the implementation,...
Hi @Shaggy , Sorry for the delay on this one. For your second question, if there is a way to remove DeployChangesExecutionOrder, I am not knowledgeable about this one and am going to defer this one to other team members. For your first question, the best way to deal with the merge conflict, here's what I recommend: A) In general it's good for DevA and DevB to regularly merge to their branches from trunk (or where-ever they are eventually going to merge TO), if their branches will be updated on a regular basis. This way they can be aware of other changes as they happen and not have to find out about them all at the end. [image] It's also best for both DevA and DevB to do that merge again right before they create the pull request. That way they can review the conflict locally and handle it. C) If there's a race condition and someone merges in right before you, the Pull Request will notify you of the conflict as you mention. In this case I'd go back to the local repo, handle the conflict, and re-push. For handling the conflict locally, if you're using the SSMS plug-in, we recommend the free VSCode as a merge tool if you don't already have a favorite. To handle the conflict:
In the trunk branch, pull changes
Change to the branch in question (in this case BR1)
Merge changes from trunk into BR1 -- in the example where trunk is named master: git merge master
Open the sqlproj file with the conflict and merge the changes, in this case we would accept both (image below)
Stage and commit
Push
[image] [image] Hope this helps, Kendra / comments
Hi @Shaggy ,Sorry for the delay on this one.For your second question, if there is a way to remove DeployChangesExecutionOrder, I am not knowledgeable about this one and am going to defer this one t...
Hi there, Not sure if this bit is clear or not -- Azure SQL Managed Instances simply don't allow you to put the database into restricted user or single user mode. This is one of the limitations of Managed Instances. We don't have a way to work around that because Microsoft doesn't allow it to happen. Generally I would recommend that people work to be able to run deployments online without killing off all other transactions when possible. Is this an option in your case? If not, I would be curious to know what the specific pattern you have which prevents it -- there might be a more graceful way to work around the problem. If you do wish to kill off all active transactions, one workaround you may find suggested on the internet is to find another statement which supports ROLLBACK IMMEDIATE (Microsoft refers to this as the termination clause), which is supported on Managed Instances and to use that other commands and to turn that option on and then off. A list of commands that support the termination clause is here. However, this is definitely a hack and I would be wary of this approach. I personally have sometimes experienced a deadlock on some "ALTER DATABASE" commands which weren't pleasant to handle, and you can't put multiple ALTER DATABASE commands inside a transaction. So if you did hit a weird deadlock on the second command, you could end up putting the database into an odd state. I know this isn't a complete answer, but hoping to get more info on why you aren't able to do online deployments. Kendra / comments
Hi there,Not sure if this bit is clear or not -- Azure SQL Managed Instances simply don't allow you to put the database into restricted user or single user mode. This is one of the limitations of M...
Thanks, Peter. Andrew on our dev team has recorded an item related to this on our status board which prevents us from forgetting about it, too [image] We are continuing to think about how which source control elements are key to put in our tooling's UI, while not trying to completely recreate a Git client -- because there is so much functionality you can put in a Git client that it fairly quickly becomes overwhelming. It's definitely a balancing act. I'm sharing this post to our design team internally as well, as I think they'll find the info on this valuable for future product planning. Thanks again for all your feedback, it is very valuable to us! Kendra / comments
Thanks, Peter. Andrew on our dev team has recorded an item related to this on our status board which prevents us from forgetting about it, too We are continuing to think about how which source con...
Hi Peter, I suspect that documentation page intended that "uncommitted changes" include changes in the database which hadn't been imported yet, but I can see how that wording is unclear. I'll follow up on that (I'm out all next week so it may be a little while before I complete it). I'll also chat with the team and propose that we move the "Create new branches" section at the bottom up to the top of the page and give a little more advice about how using feature branches makes it easier to work with Git. My preferred methodology with Git is to have each developer working in a feature branch:
Import changes from your database to your feature branch as you are ready. Push your feature branch up to the central repo as often as you like as a way to back up your changes from your local machine -- - optionally building these branches whenever they are pushed if you like
If your feature branch needs to live longer than a day, do at minimum a daily pull from master and merge into your branch
When your changes are ready to go into a main line, use a pull request to merge in
Effectively, most folks find it more straightforward to always merge changes into a branch when using Git, rather than to have shared branches where you have people pushing and pulling changes into the same active branch. I find that the Azure DevOps Release Flow model often work for people when they are getting started as it is not overly complex, but some people still prefer the older Git Flow model which maintains a separate develop branch. Hope this helps! Kendra / comments
Hi Peter,I suspect that documentation page intended that "uncommitted changes" include changes in the database which hadn't been imported yet, but I can see how that wording is unclear. I'll follow...