CD and Embedded - Another Note on this Topic

Our PM David Rosen, recently wrote an excellent blog on Continuous Delivery (CD) and its applicability to embedded technologies. And it goes to the heart of what we hear often from our embedded prospects and customers – Can we really do CD? I understand the confusion and angst and would like to point the readers to two recent blogs on this topic:

• Perforce blog: Continuous Delivery is not always Continuous Deployment

Fundamentally, there is a difference between Continuous Delivery and actually delivering to the customer. CD implies that we treat every checkin or commit as a release candidate and automate whatever you can - the builds, tests and deployments. It however does not stipulate that you actually ship code with every commit. You may be in a business where you can ship code as quickly as it comes from development (Web, SaaS) or you may be in a business where you cannot (embedded, ISV etc.). But that does not take away from the value of CD. CD is a cultural change as much as an upgrade to the systems. It requires development to work in a different way – to ensure that the code branches are always integrated, to detect problems (compilation, test etc.) quickly rather than at a later time and to automate and get efficiencies in every task. By taking this proactive approach, development teams ensure a "always shippable" version of the software. And this brings immense value to the development process (and improves product time to market and quality). But this software need not be shipped. It can go as far a pre-production/staging environment and no more. And there is a huge value in just achieving that. So embedded teams – go implement CD! It does not have to be the Facebook or Netflix style CD. It can be your own form of CD. And you would be happy you did so.