After a conversation with my boss I just downloaded Continuous Delivery to my Kindle reader (Windows 8 / Windows Phone app).
On first brush, I can see it’s akin to the next phase of a process I’m somewhat familiar with. I’ve referred to it as Software Factory in the past, and even have a label for it in this blog. I designed and delivered a “Software Factory” solution around some of these concepts at one of the few product based companies I worked at in my career…
“Software Factory” took Continuous Integration (CI) up a few notches by automating not just builds, but code generation, deployment packaging, and then an early stab at what might now be called a private cloud, where we automated spinning up an instance of target test systems, deployed the fresh baked product, ran smoke tests, and (if smoke tests looked good) notified the folks in QA for more complete testing of a solid candidate.
I’ve been a fan of Domain Specific Language (DSL) for the purpose of custom build & automation ever since.
For that company our solution was an on-premises deployment, so it was still a matter of convincing customers to deploy the updates… but our automation produced both full install kits as well as patches that would upgrade a running system from a known build to a target build.
That company was preparing to take the product into the SaaS model which was very new at the time, and this would have been a part of that, as well.
I’ve worked with TFS to integrate smoke testing and build automation, as well. That could easily extend to this sort of thing.
That company suffered from lack of customers, unfortunately, but it was a process I’ve been looking forward to getting back to, and expected we’d get back to in the consulting world some day. It’s interesting that Software Factory (as Continuous Delivery) is working it’s way back to top of mind relevance through the cloud… I’m looking forward to reading what the authors of this book have to say about it.