Voice of the DBA

Tag: software development

  • CI and CD Aren’t Magic

    I’ve been studying and talking with lots of developers and DBAs about Continuous Integration and Continuous Delivery for a few years. Many technical people are excited about the possibilities and look forward to trying to automate their builds, their testing, and improving their software. However there are no shortage of concerns about the cultural problems of getting both technical staff and management to change the way they perform development.

    These are very valid, and very real concerns.

    CI and CD aren’t magic. Just like Agile, Pair Programming, or any other methodology, these development techniques don’t produce better software by themselves. There need to be cultural changes in how an organization views software and an investment in learning to adhere to the process and apply solid software engineering processes throughout a project. Merely adopting new process without changing your view on testing, and on accepting and using the feedback, will not create better software.

    It’s a bit of a leap of faith to agree to implement testing earlier in the development process. The results of that additional work don’t readily appear, and certainly code will be written slower. It’s a stretch for many people to think that fixing problems returned by a CI process and maintaining a clean build will pay off over time. I agree, and I’ve questioned the value myself. However I also see that companies implementing these changes produce better software over time, and more reliably. If they really change their culture to believe in CI and CD.

    However the better evidence, to me, is that companies that continue to produce software the way they have for years, continue to produce software with lots of bugs, that’s also over budget and late. Perhaps that’s good enough for many companies, and that’s sad. I hold out hope that anyone producing software, from managers to developers, and everyone in between, would want to do a better job with their next project.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Anatomy of a tSQLt test

    I’ve been doing some work on testing database code, and working with the tSQLt framework. I really like the framework more and more, and want to continue to use it. The whole idea of testing is a bit immature in database code, and perhaps software in general, but at least the software people are trying to move forward. At least in places.

    As I’ve been learning, and presenting on this, I’ve started to adopt and follow the simple pattern espoused by the tSQLt framework. It makes sense, and it provides what I think is a good format for unit test. The structure is:

    • Assemble
    • Act
    • Assert

    It’s simple, and it makes it easy to see how a test works.

    Assemble

    Declare variables and create tables you need. Insert data, initialize values and ensure that you have an expected environment on which to base your tests. I think this is especially important for database code tests.

    Act

    This is the place you call your code, or perform some action. Usually easy to do, but there are some thing that might be tough to set up.

    Assert

    This is where you assert, or declare something to be true. A value is equal to another. A result set looks like another. Something that you declare to be true, which could be some condition, like an error has occurred. If it’s true, the test passes. If not, it doesn’t.

    More to Learn

    There is lots more to learn, and I’m trying to do more. However I also need others to not only try to write tests, but evaluate how well they work and also publish some code. Explain to people what has worked, AND what hasn’t. Having that information out there, for a large variety of cases, will help others better test their code.

  • It’s about Perception

    This editorial was originally published on Dec 9, 2009. It is being re-run as Steve is on vacation.

    It’s not just the code. Sure the code’s important, but it’s not necessarily the most important thing. It’s more than just the way something works, even if the code is written correctly and performs all the right calculations. That matters, to various degrees in different applications, but it isn’t the most important thing. The important thing is the way the application gets used, and the way the users feel about it. In other words, the perception of the application.

    The perception of all of our systems and the services we deliver is what really counts. I heard someone recently paraphrase a well known saying. I don’t remember it exactly, but it was something like “People never remember the quality code we deliver, but they never forget the lack of quality in our code.”

    That’s true, no matter what we deliver. Our users don’t remember the 500 days our database server ran without an issue; they remember the day it was down. They remember when our application rollout broke something or made them work more. And they definitely remember when the application is slow or doesn’t help them in their jobs.

    As an IT group, even as technologists in general, we have to  take this into consideration when we design and build solutions. Building great software doesn’t just mean meeting the specifications we were given to  the letter, or duplicating the functionality that we think is being performed or we think is needed.

    We need to make sure that our systems work with the user, that help the user and make their jobs easier. It has to provide some tangible benefits to the end user or they just don’t perceive it as being useful to them.

    I’ve rolled out applications before that had cool, new features that hadn’t existed before, or we had incorporated new functionality they had requested. But for some reason it didn’t work well, or smoothly, or the user didn’t understand how to use the system. The perception was that the application was a failure.

    None of us wants to be in that situation. We don’t want our work to go unappreciated. To do that we need to take the users’ perception into account when we’re designing and building software. We need lots of feedback as we go along and make sure we’re building the application the users actually want.

    Steve Jones

     

  • Continuous Delivery for Windows?

    I read a bit about the next version of Windows, which is coming in 2015 as Windows 10. I’m not sure how much I care about some of the changes coming in the OS, though having CTRL+V working in a command prompt is very welcome. However I did read this piece about the people testing the Technical Previews and was a little intrigued by one quote: “… Threshold testers … will have those features and fixes pushed automatically to them…”

    Does that mean that Microsoft has re-engineered Windows to be integrated with a Continuous Delivery process? If so, then I think this is a good move. We’ve already seen SQL Server move to a pace that releases new versions every two years and bimonthly patches to fix issues. Imagine that we could get patches even more often, as bugs are fixed.

    Also imagine that we could get those bugs quickly rolled back and patches pulled if there are issues.

    I think that’s one of the interesting things for me. There have been patches in the past which caused, issues and were sometimes hard to remove. If new changes can be pushed out quickly, I’d hope they could be removed quickly. And with all the feedback that Microsoft gets from existing installations, I could even start to see custom patches built that are deployed to only certain configurations that are compatible with the patch.

    Of course, that’s an ideal view. I suspect that we’ll still see overworked developers releasing patches that not only fix issues, but cause other problems, and at times, can’t be removed. At least we’ll probably get the patch to fix the patch, a little faster than in the past.

    Steve Jones

    The Voice of the DBA Podcast

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