At Red Gate Software, we have a product called Deployment Manager. Its aim is to smooth and ease the process of deploying changes in your software from environment to environment, database and application code. What I like about the product isn't that it makes the overall software development process easier, though it does. It's that the team behind the product is using their own tool and technique to . They're practicing Continuous Delivery (CD), even as they work to help make it easier for you to practice CD.

That's pretty neat. Even if you don't want to release software that often, you have to admit that's cool. I once worked at a company that released changes every week for well over a year, and I have to say that the development team was very proud of what we accomplished every week when the deployment was complete.

However we didn't release every change every week, and as the Deployment Manager team as learned, some things take longer than a week. There are particular challenges to handling the partial release of software, and while you can overcome lots of them, at times you have to delay a release. However, I'd much rather delay my release a week or two than months. The latter has happened in many places I've worked when a large application is being built.

At Red Gate we do think that continuous delivery is an important skill and valuable technique in software development. This idea gathers a lot of focus at Red Gate as we build tooling to help with the challenges of implementing CD. However the idea of CD doesn't mean that you constantly update your own software for customers. It's entirely plausible to practice CD internally, releasing changes to test and staging environments many many times before you release a change to production. The idea in CD is that you know how to, and practice, deploying software regularly. That way you're assured you can actually perform a release when you need to.