I was talking to someone at a meetup recently who was really keen on doing continuous deployment for their database but they had a number of issues, the main was that because management wasn’t sold on the idea and the DBA’s had complete control to push back on all and every idea he had - there was no way he could deploy continuously.

The accepted route for devops is management buy-in, if you do not have management buy-in then you can’t do devops. I agree totally with this, I have seen how an executive can set the direction and all of a sudden hurdles that were there are now removed or being removed but what do you do when you don’t have management buy-in?

In short you do as much as you can, for sql databases that means you:

- use source control
- use an IDE
- write unit tests
- run your tests on check-in / merge
- generate your deployment scripts

You do as much as you can, in an ideal world you would check into a shared source control, your build server will checkout the code build, deploy and test it before deploying to the prod server - but if you have zero resources you can still use git to create a local repo, you can install jenkins locally and point it at your local git repo and you can write tSQLt tests plus you can do it all from the free version of SSDT. When you have done that there is nothing stopping you having a continuous delivery pipeline locally.

Is it ideal? No - does it work in practice? Yes.

If you are just one developer then you can do it all locally, if you are part of a team then find a server to host git and jenkins - the phrase “do it first then ask for forgiveness later” springs to mind

(warning: you know your environment, don’t blame me for you actions) :)