Ask HN:Continuous Delivery for an On-Prem Installable Product

3 points by boredmgr 7 years ago | 4 comments

How can we have a continuous delivery for an On-Prem installable Product when we need to support multiple versions? More importantly, in such products, the codebase is not in a single repo. The repos can grow/shrink across versions.

To elaborate more on the Problem statement. [ ON-PREM Installable ] Let's say you roll out first version( v1) of your product and you deploy it to 2 customer environments. Once you deploy you need to support like providing hotfixes, minor version upgrades. In the meantime, you continue to innovate and add new features / remove a few features in the next major version(v2). But since you already have customers on version v1 and it will be the choice of the customer to accept/reject the newer versions. You would get new customers for version v2. So now you have 2 major versions out there with customers using 2 different versions of your product. So the problem now becomes 2-fold. You need to have your team continuously support both the versions. Now the easier thing would be to discontinue the older version as soon as you have new version rolled out. But the downside is you cannot term your customers on older versions as active customers, neither they will be able to back you on the new innovations that you added to the newer versions.

Hope I have been able to elaborate on the problem. Any suggestions?

grantlmiller 7 years ago |

The problem is 2-fold, 1) a business/contract problem 2) a technology problem.

The business problem is that your on-prem customers need to accept the idea of being being upgraded to the latest version automatically or on a specific cadence (ie every day, week, month, etc). If they're not willing to accept this, they need to pay you more for the extended support (LTS) of an older version. Many enterprises will be hesitant to accept auto-updates b/c they fear that your application will break during update, you can alleviate that concern with technology as well.

The technology problem can be overcome by using a cloud-native architecture for your on-prem product. This will ensure that your product has the level of reliability that is needed for true modern on-prem deployments you're describing. It will allow customers to do canary updates, rolling updates that will minimize downtime (just like you do for SaaS based CD). Multiple repos, different components, no problem, package them as Docker containers and then deliver the new manifest (k8s, swarm etc) that includes the new images. The key to success here is automation. You have to have a level of rigor for automating every production change with automation (often packaged as a new migration container for the new version). There are other systems you can build to solve for this as well, including release channels that will allow you to push different versions to different customers or staging environments based on specific licenses for each customer.

We've spent the last 4 years turning this problem into a product: www.replicated.com and it currently powers the on-prem versions for Travis CI, CodeClimate, CircleCI, Terraform Enterprise, Gradle and many others who know a lot about CI/CD.

sidcool 7 years ago |

I find GoCD a very good candidate. It's a Continuous Delivery first, free & open source software. Do have a look.

boredmgr 7 years ago | |

@sidcool, Thanks for the cool open-source project. One query is all the documentation are about how to make things work when you have a single repo to deal with. The problem complicates when we have to deal with multiple repos that can grow/shrink across versions.

sidcool 7 years ago | | |

GoCD scales very well for multiple repos. It has pipelines as first class citizens. And builds can be configured to have a workflow across repos.