Voice of the DBA

Tag: continuous integration

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

  • Practical Problems with CI

    I agree. Continuous Integration has issues in the real world, at least it probably does in many companies. The more tests you have, the more likely you refactoring or changes will break something. The more things break, the more people will look to leave them alone, deferring the "fix" into the future.

    This defeats the purpose of CI. The whole idea is to keep your software in releasable condition. That way you can push it out if you need to.

    How do you deal with the constant build breaks? The first thing I’d do is see if I mad a mistake and can fix my code. That should be the first reaction.

    The next thing is stop for a moment and see what tests are failing. It’s entirely possible that the tests aren’t valid or aren’t needed. Maintenance of tests is an issue. If this is a test that regularly breaks, I might call a quick meeting and see if we should remove it.

    The last thing is that I’d rollback my code and then go back to work on it. Perhaps there’s another way to solve the issue and not break the build.

    This isn’t magic. It’s also not easy. However if you are keeping up with your CI process and it’s healthy, I believe it will pay off over time with better software.

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

  • DevConnections–Continuous Integration for Databases

    Thanks to everyone that attended my Continuous Integration for Databases talk today. I’ve included download links to the deck here if you’re interested.

    Slides: CI for Databases.pptx

    I’d also recommend that you check out a few other resources if you want to get CI working.

    And remember, this starts with Version Control, so be sure you implement a VCS at your company. If you don’t have one, I’d recommend you try Subversion or Git, both of which are free.

    Some great questions on testing and the entire CI process and I hope I answered them all. If not, please feel free to ask.

    Keep in mind that the process isn’t about specific tools. The Red Gate tools work great, and help you get this running quickly and smoothly, but CI is about automating a process that you likely do manually already. It does it consistently and automatically, with less room for error.

    If you are looking for more information, check out the CI resources at Red Gate.