Voice of the DBA

Tag: DevOps

  • Held Hostage by the Database

    Your database platform will constrain and limit the flexibility you have in evolving your software. It doesn’t matter which platform you choose, which type of database, or even the format for your data. At some point, you will be dealing with legacy data in some legacy schema or structure, and your development, and certainly deployment, will be slowed or impacted. Face it, the need to maintain state for your data is an impediment in a relational system. In a NoSQL or other store, the need to maintain code in your application that can interpret your data might be the issue over time.

    That’s not to imply this need to maintain state has to slow your development. On the contrary, there are many companies that find themselves moving quickly, able to make database changes on a weekly, or even daily, basis. There are multiple tricks and techniques for managing change, but ultimately the real secret is having a process that computers can follow and your developers adhere to.

    In other words, having some automation.

    Certainly you need to program the automation, or use tools like those from my employer, Redgate Software, but it doesn’t matter which what process you use. The process does need to be flexible because it will change over time. I can almost guarantee that the way in which you need to deploy code to the database in your environment will change over time. It has to as the needs and requirements of your business change.

    This means the way in which your developers need to build, test, and package changes will need to grow and evolve as well. While every developer and sysadmin needs to work within the process, the process does also need to be flexible as needs change. That isn’t to imply that your process should change every week, or for every deployment, but it will need to do so periodically, and hopefully, rarely.

    There are techniques to make deploying database changes easier on the developer and system administrator, but there are no magic techniques. All the tools I’ve encountered, including those from Redgate, do the same types of things you’d do manually. They just save you time and stress by helping you get set up and easily maintain your deployment tasks over time.

    Whether you use tools or not, please don’t allow the database to hold back your software development. Learn new ways to alter your database. Learn the ways to make changes to large tables. Learn how to avoid downtime. Just learn to design database changes in a better way and then automate the deployment of those changes.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.6MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • DevOps at Microsoft

    I’ve been watching Microsoft for quite a few years, with my career being tightly intertwined with the company for 25 years.  I’m amazed by the way the company has changed in the last five years. It’s probably been longer than that, but from the outside, the last 5 years have been surprising. Certainly the way Microsoft produces software is a process worth studying by almost any organization with developers. There are some scale advantages Microsoft has, and their mission is to reach and touch people at a level far beyond what many of us deal with, but there are lessons to be learned.

    There’s a great piece that shows some of the ways in which Microsoft is practicing DevOps in their own software development. I like that the focus isn’t just that developers do more, but that operations staff are involved in working closely with the development teams. In fact, there’s a quote I like that notes in addition to technology changes and habits, ” we found that the organizational changes and cultural shifts required to embrace these practices have been just as significant.”

    As I talk about smoothing the database development pipeline and creating efficiency in the process, I want people to be aware that cultural change is required. My employer, Redgate Software, can sell you tools that solve the technology challenges, but if you don’t change the way you build software in your culture, with your staff, the tools don’t help. At best they make a few tasks easier for developers, but you will still have issues releasing your software consistently on your schedule, whatever that may be.

    There is also the emphasis on developers deciding when to release. In Microsoft’s domain, this probably works, but not likely for many line of business applications in organizations. However, the focus should be getting changes to customers quickly after development. The sooner they see features, the sooner they can provide feedback on whether the software works as expected or changes are needed. This quick feedback also means that developers have the architecture and flow of the code in their recent memory. Always a recipe for smoother continued development and quicker bug fixes.

    Testing isn’t emphasized much, though I think as developers become more accountable, and they can get changes to customers quicker, they’ll start to want automated testing that allows them to check for regressions, as well as ensure requirements are being met. Microsoft has the advantage that many of their internal teams can actually use the end product, something that isn’t always easy for those of us in other industries.

    DevOps works. The principles are sound, and it doesn’t matter if you’ve followed the principles for decades (maybe under another name) or just started a new process by asking for more coordination and collaboration from your teams. Learn to build a coherent system with your developers and operations staff, throughout your software development process, and your whole organization will benefit.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.6MB) podcast or subscribe to the feed at iTunes and Libsyn .

  • Bringing Database Devops to DevConnections

    Another alliteration post. Maybe I’ll make all my titles tongue twisters to test your talents?

    This is my new favorite session. I’m slated to deliver this at a few different conferences this fall, and hopefully you’ll come see it in Las Vegas at DevConnections on Oct 10-13.

    The talk is called Bringing DevOps to the Database, and this presentation is designed to show how many of the software development processes that we take for granted with .NET, Java, and other front end applications can be applied to the database. I’ll cover how version control, Continuous Integration (CI), and Release Management (RM) can be applied to database changes.

    This has been a focus of mine as an evangelist for Redgate Software, and I’ve found a number of ways that you can adopt common, best practice software engineering in the database development process. I’ll show how Redgate makes this easy, but I cover the process in a tool independent way. You’ll learn what needs to happen. How you get that working is up to you, but if help is needed, Redgate can cover that part.

    If you’re looking for some training, some inspiration, and are a full-stack developer, or multi-technology IT worker, think about coming out to DevConnections. There are a slew of technologies being covered (VS, ASP.NET, C#7, Azure, PowerShell, AWS, SQL Server, Sharepoint, Exchange, Hyper-V and more).

    Register today, use 500SPKR to save $500, and I’ll see you in Las Vegas this October.

  • Bringing DevOps to the Database

    Abstract:

    DevOps is a hot topic in today’s software development world. However most of the knowledge and experience with DevOps is based around application software and ignores the database. We will examine how the concepts and principles of DevOps can be applied to database development by looking at both automated comparison analysis as well as migration script management. Automated building, testing, and deployment of database changes will be shown.

    Level: 200 – Not to technical, but you should have some idea of how software development works to get something out of this talk.

    Goals:

    1. Conceptually understand how DevOps principles can easily be applied to the database in either state based or migrations based changes.
    2. Learn how databases can be automatically built and tested in a CI/CD environment
    3. Understand how database releases can be automated, but are different than those deployment/releases made for other software.

    Demos:

    This presentation has a few demos where I show how I stored database code in a VCS, perform an automated build, and use a scripted release process to move code from one database to the next. The demos are pre-built, so I just show how they work. I can do this with:

    • git, VSTS Build and VSTS Release
    • git or SVN, Team City, and Octopus Deploy

    Downloads:

    There are a few versions, as this talk has evolved.

    GroupBy – Bringing DevOps to the Database Groupby.pptx

    Live!360/VSLive – VSLive-Orlando 2016.pptx

    SQL Saturday Cambridge – Bringing DevOps to the Database.pptx