Voice of the DBA

Tag: DevOps

  • The Redgate Way

    Recently Matt Hilbert, from Redgate Software, wrote a piece on our blog about our journey to DevOps. It’s a great read, summing up some of the things that we’ve learned in our journey across the last decade. Matt is a great writer, and it’s worth a few minutes of your time to check it out and think about all the things that we’ve been through.

    I’ve known some people at Redgate for 18+ years, and I’ve worked there for 12, so I’ve had the chance to see quite a few changes. When I started, teams worked for long periods of times, in what is really a waterfall methodology. They went through substantial phases of development, testing, and beta releases, with Brad McGehee and myself having plenty of time to learn a product and then know it would be stable for a year or so.

    That slowly started to change, as Matt describes, with teams moving to new methods of building software, experimenting and learning. The Prompt team was one of the most ambitious, working in pair programming and finding ways to release almost on demand. Over time, other teams caught up and built some amazing processes. We even had two teams working on some products, with alternating two week sprint cycles to allow them to release every week. That was an impressive coordination of software development teams.

    Even today, I’m constantly impressed by teams. They aren’t all always rock stars, but they often exceed my expectations. I will see some slowdowns when teams change their people, process, or tooling, but then they will leap forward. The Data Masker team has been impressive lately, with some fantastic productivity improvements being added to the software. I apologized recently for not taking the Data Catalog team seriously for almost a year, but they have done more than I ever imagined with that tool in the last six months.

    We do continue to improve our software development skills at Redgate. We do release often, but really, we try to also improve the quality of our software, improve the skills of our developers, while working to retain talented individuals and help them enjoy their chosen career. We still produce bugs, we never get everything done as fast as sales, marketing, or even me, would like, but I do think that the last ten years has been an incredible growth as set of software development teams. Now our challenge is more closely aligning all teams to work in a loosely coupled, but tightly integrated fashion.

    DevOps is really a better way to build software for most organizations and teams. It often doesn’t change a lot about the actual code we write, but it does get developers, infrastructure staff, and management to rethink how we work, especially how we work together. That’s the hardest part to get through to many customers. This isn’t an install-a-tool-and-things-are-great system. Tools do help, but your attitude, your focus, and your willingness to work as a team are more important.

    Read about our journey. We’ve taken 1,000 steps, but there is more for us to learn, change, and implement as we move forward. Think about how you would want to change things at your company, and maybe pass this along to your manager. It’s not easy, and it might not be quick, but it’s an incredible journey. It’s also very much worth the time and effort you put into it.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • A Mindset Shift

    I’ve been working with people at Microsoft for nearly two decades in different circumstances. It’s been interesting to me to work with developers, Microsoft consultants, and community people across the lifetime of SQLServerCentral, especially the last 5 years. For a long time, I never wanted to work there, but I’ve started to think I might find it to be an interesting company in the last couple years.

    There are two good articles that talk about the ways that Microsoft has changed. The first is from the high level culture perspective and tries to explain how the mindset has changed. If I hadn’t been witness to it, I wouldn’t believe it. These changes really happened, and they were amazing to me. I’ve been going to Redmond for 15 years, often working with a couple groups and since Satya Nadella took over, I’ve seen these changes get implemented. I’ve watched teams grow and change, and learn to re-frame the way they look at their work. I think it’s been a change for the better.

    The second one is a little more technically detailed, and perhaps more interesting to anyone that would like to get their organization to adopt DevOps. There are some specifics with tools, but really read about the mindset changes and the feedback they use to improve software. I think too many managers think automation and features are all you need to implement and forget that quality, experimentation and learning are keys to this working well. Make sure you point those out to managers if you pass this along.

    Not everyone at Microsoft made the transition. Some left, some were probably asked to leave. New people came, but plenty adapted, altered their mindset, and have bought into the way that the company has evolved. They’ve certainly gone from a company I wouldn’t want to work for because of the stacked ranking and competition to an organization I’d now consider employment within. That’s if they want someone remote in Denver.

    I’m proud that Redgate is also moving in this type of direction. We’ve learned a lot from DevOp and we’re learning that culture is important. We hire those that work well with us and help us build better tools for software developers in a team culture. Those that don’t want to work with a team, work in a DevOps flow, and be accountable for their autonomy will probably move on. That’s fine. We’re learning who we are and implementing that into our staff. I’ve tried to do the same in my life, know who I am and be that. I hope you can do the same.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Do What Hurts

    A long time ago I heard a manager at a company say that if something is hard, we ought to practice it more and find ways to make it easy. Barring that, we ought to at least be comfortable with the task. I’m not sure if this manager made this up or read it somewhere, but it’s the same thought expressed by Martin Fowler in this post: “if it hurts, do it more often.”

    I’m not sure that’s the advice I want to use with everything. When my shins hurt from running, or my shoulder aches after hitting a number of volleyballs, often I want to take a break. At the same time, I know that stopping isn’t always the productive thing. I can slow down and build up some strength and things will get better. My long running streak started with slow jogs for short distances, slowly building up the strength in my muscles and joints. Regularly hitting volleyballs and slowly increasing the number I hit allows me to get more done without hurting myself.

    At the same time, putting a hand on a hot stove doesn’t get better, no matter how slowly I increase the heat over time. There are some things that aren’t worth doing more often to get better, but building software is one where we can get better. Our practice does improve skill, quality, and ability if you practice well. We can decompose our problems easily, we can work in steps, and we can (relatively) easily alter our course of work if we need to do so. In fact, quite a few of the software methodologies adopted in the last 20 years are designed to improve the entire process be ensuring we adapt our work to the customer with regular pauses to evaluate our progress.

    When the pain of delays (procrastination) grows, we should find ways to reduce the hassles. Often the pain comes from difficulties, and when that is the case, we might do what Martin Fowler suggests: do it more frequently.

    It works well for databases, as he points out in his post, though I’d caution the data professionals to consider the details in his post. Decompose the problems and make the changes across multiple steps, not all at once. When you do that, make sure you plan for pauses in the various stages, not just stringing together multiple scripts into one transaction. That will help you evolve the database along with the application while ensuring your customers can continue working as you make changes.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Losing The Security Game

    It’s sad some weeks to see reports of security issues at large companies. It’s also discouraging some times when clients or friends will talk about security issues they’ve had in their organization. What’s mostly disappointing is how easy many of these issues would have been to prevent with a little effort.

    Joey D’Antoni made some fun of this with his Data Breach Game. It’s a bingo card you can print out and use the next time you hear about an issue. My guess is most of us could win this in about a week with the general state of security in most places. Some of you might win this in a day with inside knowledge.

    This is poking a little fun at the poor security practices of many places. There’s a wider article about 9 poor security practices you can read, with some notes about what you should be doing instead. When you read it, you’ll wonder why hasn’t someone just made these simple changes and dramatically improved security? I have asked myself that many times when I’ve seen some environments.

    Ultimately, no one wants bad security, but we (as a group) often make poor choices because we’re in a hurry. We can, and should to better. All of the items on this list can be avoided, and should be. Even the complexities of SQL Injection can be fixed with a little code refactoring. No time or that’s too hard? You should be building software in a Compliant Database DevOps manner.

    I like the list, though I wish ElasticSearch where on there in number 6 with MongoDB. Too many breaches this year from people dropping that server on their network without a password because they need full text searching of data. Don’t make that mistake. Always, always, always set a password on data resources. Developer or partner complaints aren’t worth the risk of losing data from an unsecured server.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.