Devops without management buy in?

  • Posted on: 10 February 2017
  • By: Ed Elliott

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) :)


  • Posted on: 20 October 2014
  • By: Ed Elliott

There has been a gigantic shift in attitudes between development and operations, the devops movement, to create a streamlined, automated and high performing team of developers and infrastructure techs which has really helped transform many operations and projects.

It occurs to me that when building a development team or planning out a project we should include resources for developers to write tools and improve processes for the other developers in the team. I have seen this work very well in a small team which constantly had one developer on rotation spend a week just writing tools for developers.

The reason that I think that you should dedicate the resource to this is that, often on larger projects you find developers wasting time away on common things such as:

  • Setting their machines or build machines
  • Troubleshooting bugs which could be found quicker with custom tooling
  • Investigating possible frameworks / tools

All of the things are vital but take away from the real goal of delivering work.

Scheduling in a specific resource means that you can focus on making the development environment better, which consequently helps the deployment and support environment for free and keeps developers focused on what is important.

I have sometimes seen projects commit a sprint-zero to writing tools and such but it is hard to anticipate what tools would be needed before the project had begun which is why it is preferable for the work to be ongoing.

Overall, I would love to see development teams including a resource to make their lives better and more productive, if we saw even a fraction of the improvements that have been made with devops with devdev then I would be extremely happy!