Voice of the DBA

Tag: continuous delivery

  • DLM Workshops

    We’ve got a bunch of DLM workshops coming up in the next few months from Red Gate Software. We’ve been working on trying to bring some depth to our education, helping DBAs and developers learn how to built smoother software development pipelines for their databases.

    The list of workshops is at http://www.red-gate.com/training/workshops/ and we’ll be updating it throughout the year. In this series, I’ll be at these events

    • Mar 10 – Dublin
    • Apr 10 – LA

    Certainly more are coming later in the year that I’ll deliver or help out at.

    We’ve built a series of three days of in depth instruction, each one building on the next. Our hope is to help you move through the subjects. Right now the days are covering these topics.

    • Version Control for Databases
    • Continuous Integration
    • Automating Deployments

    We are looking to try and schedule these over time in a city, so that you’ll be able to learn about VCS for databases, then come back in 3-4 months and take the next step to CI. We might do all three days consecutively, but it’s a lot to learn and cover, and I’d really hope that companies would learn one area, implement it, and then come back to learn the next step.

    If you have requests for dates or cities, or even private instruction, let us know. We’re growing a list of partners as well because Grant and I can’t be everywhere, so we hope to be able to help more people learn ways to build software smoother and quicker.

  • 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. 

  • 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.

  • Database Checkups

    I am most definitely a fan of continuous delivery (CD) and the idea that we have the ability to both release our software at any time, for any change, but also have the process and mindset in place to rapidly push enhancements and patches through our development process. However I’m also no naive enough to think that the processes of Agile, Lean, Scrum, Continuous Integration, or any other methodology make this happen. It requires belief and effort by your entire team, including management, to evolve your software quicker.

    There is a downside. The faster, and more often, you release changes to your production system, the more likely you are to cause an issue. This isn’t really any different from traditional waterfall processes, which also cause issues in production, but it does mean that the perception of issues is a bit changed. People expect higher quality when they implement a CD process, and while quality might be higher (there is debate on this), it certainly isn’t perfect.

    Walgreens has implemented a CD process, and they rapidly deploy changes, but they’ve also had issues. In fact, there’s a piece that talks about an issue during a database deployment, and offers some guidance on preparation to deal with problems in your deployment process. The ideas of monitoring (which is critical), planning for recovery, coordinating development, etc are all things that we need to do in any production environment, but they are especially important in a CD process where people expect changes quickly. Whether those changes are enhancing the application, or rolling back a problematic deployment, they need to happen quickly.

    Over time, which may be decades, I expect that more and more organizations and end users will expect patches and changes to their software to happen in the background, while the system is being used. This might mean we need to plan for application architectures with sections that can be upgraded separately, or maybe we will develop ways to modify executable code without ending the process. In either case, the ideas behind CD will become more and more useful, and the more you understand them, the better off you’ll be.

    Steve Jones

    The Voice of the DBA Podcast

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