Voice of the DBA

Tag: software development

  • DevOps

    The DevOps movement is supposed to promote a closer collaboration between developers, testers, operational people, and really anyone else that must help software gets build and deployed. The developers need to coordinate their needs and requirements with operational staff. They should work early on with any staff performing testing to help them ensure that bugs are caught quickly and fewer slip through to production. At the same time, operational staff should be responsive  and helpful in all the environments software moves through. Operational staff should help build and automate the configuration of development and testing environments, ensuring that systems are built in a repeatable fashion as well as the same way in each stage of the software development pipline.

    However, is devops killing the developer? If developers are becoming responsible for testing, that’s bad. If developers must learn to function as a DBA as well, then I certainly expect they’ll write less code. If developers need to ensure the software can be installed on production systems and train operations staff, then I suspect they aren’t very happy with their jobs.

    But that’s not DevOps. If that’s how your organization runs its development, it doesn’t understand DevOps. Developers should be leaning on and learning from, as well as teaching other staff. When I read that post, I think the developer has missed the idea of DevOps. It isn’t that developers need to become completely versed and responsible for the full stack. It’s that they should be working with everyone involved in the process the entire time that software is being developed, using the specialized knowledge each person has.

    DevOps isn’t something new. I’ve worked in teams that worked like this in the past, but we never had a name for what we did. We just thought we were part of the same team. I’ve also worked in organizations with walls between all groups. That wasn’t a team, and we had lots of four letter words for that style of process.

    DevOps is a good term and a good idea for software development. If a company implements it well, then it works and people are happier with the way software is produced. If they aren’t, then the process hasn’t been configured correctly.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • No Works of Art

    I used to pride myself on being able to run through menu selections and configuration options from memory. There have been times when I could describe over the phone  the process for using a GUI. I’ve been able to direct people to log onto SQL Server, choose a database, right click it, and choose restore. Then select device, choose NORECOVERY, etc, etc. I could walk people through many Windows dialogs, IIS configurations, and more, with verbal commands, picturing what they would see on the screen as I was holding my phone to my ear.

    People would be impressed, and I’d rarely make mistakes. I knew what was coming next, and where to click. However I did make mistakes at times, and while that’s human, that’s not what we want during software configurations. These days we find plenty of administrators and developers running an install program, and either selecting options from memory or using some sort of document that was given to them. The thing that concerns me is that any of those processes could be full of mistakes. Documents never get rev’ed to keep up with changes. Human memory is faulty, and certainly we find ourselves clicking the wrong button at times.

    When we install, or deploy, software in this manner, we’re asking for problems. Not every time, but if we manually configure, click, or select anything, then we are building individual works of art. That’s not what we want from our software environments. We want to know that the production environment is configured the same way every time, and if we need to recreate it in a DR situation, we can. We want confidence that the software that was tested in the QA environment will work correctly in production, which means we know that the states of the system are the same. We might even want to be sure that we’ve configured our development environments the same as production.

    As our tools get better, especially around virtualized systems, there isn’t a good excuse for not automating our installation and configuration through some sort of scripting. These days there ought to be no reason for a Windows, SQL Server, IIS, and most other platforms to not be easily scripted and deployed in a hands-free fashion. That’s one of the keys to engineering software at scale instead of sculpting it one system at a time.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • The Development Backup

    Have you ever had a development server crash? Have you lost work because of this? Had delays or had to recreate code? You shouldn’t, or at least you shouldn’t lose much work or time..

    There was a time when I offered to manage backups on all development servers. This was in a large environment with hundreds of instances.  I wasn’t worried. I had scripts to do the work of setting up, running, and reporting on backups for instances. I knew how to deploy these scripts to hundreds of servers.

    My reasoning was the our development servers were really our manufacturing environment for software. Wouldn’t you ensure your machinery was well maintained and kept in top condition if you had a factory? I know I would.

    The developers passed and once in awhile they’d call and ask of we could recover a server. 

    “Do you have backups?,” I’d ask. “No” was the usual reply. I’d appligize and reiterate my offer to manage the system. They were always resistent and that was fine. They were responsible, and these were their systems. However they had a backup system already. They just didn’t use it.

    Almost all of these people were using a version control system (VCS) for their code, but not for database code. Do me a favor; put your database object code in source control. Add all your DDL for tables, views, functions, stored procedures, and anything else you use.

    As long as it’s on a different physical machine than the development server, you’ll thank me one day.

    Just as long as you also run backups of that VCS database.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

     

  • Why Don’t We Have Better Practices?

    This essay isn’t quite Safe For Work (SFW) and might offend a few people, so be warned, but I found it somewhat humorous. It’s a look at all the insanity and problems with programming and software in the world. It certainly makes me glad that those of us working on software don’t actually build tangible objects like bridges.

    However the piece did make me think a bit. Why do we have so many conflicts and strange practices in our software systems? Why haven’t we decided upon more good security practices that we widely disseminate and use? Why doesn’t much of our code follow established patterns, like those that we might use to build a bridge?

    I think ultimately it’s because of the ease with which we can “try” something out in code. Our industry allows us to easily build mock ups of ideas, which often get altered and enhanced as we test out ideas to the point where we don’t have time to start over from the beginning in a new way. We continue to build and grow our systems like some sort of bizarre Winchester House, often afraid or uninterested in questioning the conglomeration of architectures that might be contained inside a single application. Even databases are not immune, containing multiple data models and substructures that may or may not mesh smoothly with each other, and often don’t contain much DRI at at all. I also think it’s the NIY syndrome that so many technologists have.

    It seems as though the more we learn about computing, and more important and embedded software becomes in our world, the less we seek to constrain the innovation and impose any sort of engineering or strong discipline on our systems. It makes me think we’ll never get to the highly integrated, and well running computer systems of the future.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.