
Ask HN:Continuous Delivery for an On-Prem Installable Product - boredmgr
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&#x2F;shrink across versions.<p>To elaborate more on the Problem statement. [ ON-PREM Installable ] Let&#x27;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 &#x2F; 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&#x2F;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?
======
grantlmiller
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
I find GoCD a very good candidate. It's a Continuous Delivery first, free &
open source software. Do have a look.

~~~
boredmgr
@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
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.

