DevOps

TSQL Tuesday - Databases and DevOps

  • Posted on: 13 June 2017
  • By: Ed Elliott

DevOps isn't running SQL Server in a container and pushing code to it from Jenkins

When we talk about DevOps we envision that we have the ability to check-in code, spin up a new environment, deploy, test and push that code to production and be in the pub at 4.

We know that by having the right tooling in place we can make releases more reliable and more frequent enabling us to deploy the changes that the business want when they want them rather than every x days/weeks/months/years/decades. This outcome is best for everyone, no one loses and the path to fun and profit is that, fun and profitable.

So what do we need to do, run SQL Server in containers and write and deploy our code using SSDT? Yes do it, but you don't need to you can do DevOps and work on doing frequent releases with a standard sql server instance and manually written deploy scripts that are emailed around.

So what is DevOps if you can do it without source control?

DevOps is about enabling frequent releases - that is the core element of it and to enable frequent releases we need:

  • A way to deploy code (a DBA wearing out the F5 key in SSMS is a way to deploy code)
  • A way to be confident about the changes we are about to make (hint tests, lots of them)
  • A way to know when there is a problem with production (monitoring and alerting)
  • The ability to identify bottlenecks, work together and make improvements to the process

The last point is most important, for me it stems from kanban and the kaizen approach of identifying bottlenecks and working together to remove the bottlenecks.

If you look at your existing approach to making changes what are your bottlenecks? How can these be improved? When you deploy changes and they go wrong what stopped you finding out about those problems earlier? When you look at the different stages of a change from business analysis to troubleshooting issues reported by customers, how many of those and how much time and money could have been saved by not having that issue or by identifying it in developer tests or when it was rolled out rather than when the user complained about it.

If you truly start looking at bottlenecks in your entire release process it will more than likely lead you to an end position of a DevOps culture and practices including the tools required to do it but without the underlying kaizen approach, to continually remove bottlenecks in your processes, you will simply pay for tooling you don't need and covering your laptop with stickers but not deliver the value that the business needs.

Which one of these are you?

or

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

DevDev

  • 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!

 

Tags: