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.<p>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.<p>Hope I have been able to elaborate on the problem. Any suggestions?
The problem is 2-fold, 1) a business/contract problem 2) a technology problem.<p>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.<p>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.<p>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.