Voice of the DBA

Tag: DevOps

  • Lessons from the Phoenix Project–Leave Slack

    Not @Slack, but slack time, time when you aren’t buried on a particular project.

    In the book, The Phoenix Project, the Brent character is the jack of all trades, the one that everyone goes to to fix and solve problems. He gets tasked with important projects and work, which means he’s always busy. I’ve been in this position, and a few of you are likely depended upon like this at your job.

    Slowly, the other characters start to realize that if Brent is fire fighting, or he’s on a long project, then he can’t get other things done. He likes and wants to complete work, something most of us do, which means that unless he has windows to tackle new work, he never gets to new work.

    It’s important to break work down and work in small windows. It’s also important to ahve some free time available for anything that comes up. That way if there is something important, you can tackle it without subjecting that item to a long delay. If you also find that some work can be handled by others or isn’t important, you have a break to switch to something else and leave the less important project behind.

    This comes from flow of work and theory of constraints, outlined in The Goal, from manufacturing. Ensuring that some resource is always busy doesn’t make sense from an flow standpoint. This is discussed in the book, Slack, as well.

    If you haven’t read The Phoenix Project, it’s a quick and easy read. A little silly, somewhat exaggerated, but it makes a point that’s worth making in how we work in technology.

  • Take the State of DevOps Survey

    Kendra wrote a nice piece on this the other day, and I agree.

    Take the Survey

    The data that comes out of this helps to influence executives and managers. You can show them results, which might get them to help you change your job.

    This is also a way that we can share information with each other. Are others doing their jobs better than you? Can they actually get code tested and reliably deployed? Are most people using VCS?

    Or maybe not.

    Take the Survey

    Share some information and learn something back. The results will be available online, and you can use them however you like to convince your organization to make changes.

    We don’t manipulate the data, and we’ve hired a company that specializes in doing this, so we can try and get accurate accounting of the data.

    Take the Survey

  • Wasted Work

    I’ve been re-reading some of the manufacturing and DevOps books that I’ve collected over the years. In these texts, there are a number of concepts that stand out, but one that resonates with me is the concept of waste. There’s actually a good article on LinkedIn about waste that’s worth reading as well. While it’s easy to start spinning in circles and thinking everything is waste around you, step back and keep some perspective that some waste is inevitable because the world is messy. Don’t get too caught up in waste, but try to reduce waste where you can.

    One of the areas that I think contains a lot of waste in software development is the effort to build features that won’t be used. Like many of you, I have been asked for no shortage of changes to software in the past. Often those changes require both application and database changes, usually to support a new way of conducting business.

    The interesting thing to me is that often I’ll work my through a queue and get changes completed, a percentage of which rarely, or even never, get used. What seemed like a good idea when it was requested, specified, and scheduled may not be a good idea weeks or months later.

    In other cases the latest request is labeled as important and needing to be completed ASAP. This might displace older work, perhaps even pushing it to the lowest priority level where it may never get completed. That’s fine, as if the work isn’t important enough to be pushed by someone, perhaps it isn’t needed.

    To me, this is one of the advantages of working in a DevOps style flow, with small changes being developed and released. If clients start to use the feature and need additional development, we can continue to enhance the feature. If the users don’t use it, which we know from either future requests or instrumentation (the latter is preferred), then we can put more effort into the areas that are more important to our organization.

    With less waste.

    We don’t work on large projects to completion, wasting work on the parts of projects that will not be used. Instead, we complete small parts and keep shifting our focus to the areas that are most important to clients.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Rolling Back Migrations

    I happen to be a fan of database migrations as a way of making and deploying database changes. This is an approach that tracks each of the scripts run by developers in their working environments and the replays these scripts in production to deploy the changes. It works really well, and is the most bulletproof method I know of for ensuring the changes will work in production. That’s not to say there aren’t issues, but it’s the approach I favor. It’s a part of what SQL Change Automation from Redgate Software does, and it’s also what Microsoft and other companies see as the future of database deployments.

    This is in contrast to making changes in development and then using some technology such as SQL Compare or Schema Compare in SSDT to create a script and use that to deploy changes. That works very well for many people, but I do find that most customers outgrow the technology with certain changes that don’t lend themselves to this state or model based method of script generation.

    In either case, rollbacks are a concern for many DBAs and developers. After all, the database is a stateful service, as our data must be maintained over time and there are certain changes that are difficult to rollback. While many developers that might have renamed an entity or added a column might be tempted to just reverse the change, this isn’t always easy to automate, especially in most of the tools we use. Often we depend on the skill of a particular individual to manually execute the reversing DDL, and possibly determine what to do with any data that was changed.

    I ran across another developer that things migrations are a better way, and that in a year of development, they never had to roll back any changes. While I agree that migrations is a more reliable process, I do think that assuming you’ll never roll back a deployment is highly optimistic. I’ve had tales of application developers being out of sync, of other applications not working with a new version of the database, and more. Some of these might be fixed with a quick roll forward, but ultimately I think that there needs to be an easy way to make rollbacks normal.

    The one downside of migrations is that the reversing transactions can be complex, since each migration script might make complex changes moving forward. There isn’t much help from most migrations tools, whether that’s SQL Change Automation, FlywayDB, Entity Framework migrations, and more. These tools can certainly generate reversing code for simple changes, but any sort of complex alteration requires custom code.

    My view is that a few simple rules govern how I view rollbacks. For views, procs, functions, I’d grab the previous version from our VCS and re-deploy that. I might try to run through a DevOps pipeline, but if I were in a hurry, I’d grab the code and run it. I’d also then recommit the old version as the latest one. For tables, we should write reversing migration scripts for any entities that are risky. Risky meaning this might affect my employment status. I’d be sure I had a second deployment pipeline that I could use to run these scripts in QA, staging/pre-prod, etc. after we’d verified the code we were deploying. I’d then have checks to ensure we really were reversing the changes.

    The last rule I have is that I use time to make deployments easier. I would never add new columns and drop old ones in the same deployment. If I move or change data, I’d always ensure the old versions of data remained. That way I could reverse changes without problems. I can always do cleanup in a later deployment that just removes objects or data, but I want to be sure that old data is really no longer needed. That means I need to be organized and have a good calendar system to scheduling future cleanup work as well.

    Migrations are really a better way to do database deployment, whether you’re working in a relational system, or you might be altering documents in a NoSQL system. Replay the changes you’ve made in development, that you are sure worked on “your” machine. You’ll be more confident they’ll work on another machine.

    Steve Jones

    The Voice of the DBA Podcast

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