Nah, this is from my day job so it's a proprietary closed source thing. Supposedly the CI speed issues are because the CI has to start with cold caches every run (we use Gitlab pipelines that run in docker containers) whereas the IDE has the caches on hand. Something about the way our devops has set up the Gitlab runners makes enabling shared cache much hard than it should be so I haven't had the chance to test that. I don't think I ever tried limiting it to only changed files, that's worth a shot.
I wish their was a standard c# formatter too. dotnet-format doesn't support wrapping long lines which is one of the more important features in my opinion.
I've always been afraid of updating Jenkins or the plugins because things always broke. Always.
That being said, I updated a few instances to 2.0, immediately applied all plugin updates and things kept working as before. That was a surprise. I was already prepared to spend hours trying to find why our jobs were failing. That was nice.
We have had problems but mainly with plugins. There's basically no mandatory QA process for plugins, nor is there any facility to make it obvious to an updater that an upstream change affects a downstream plugin and might break it.
In my opinion, Jenkins is a product that you really need to have a test instance for, where you either have copies of your builds or you've set up some 'unit test'-type builds to exercise functionality you depend on.
I prefer to think of db version control and db migrations as two separate things.
Version control achieved by keeping the SQL scripts to create the database in your VCS along with the code that depends on it.
Migration scripts are created later as a pre-deployment step. I prefer not to store these scripts in VCS because in my experience they are typically run once and never used again. There are several tools that can generate the migration scripts by comparing two schemas e.g. dev-->prod.
