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.
The Voice of the DBA Podcast