Release Management
Making a SaaS application ready to run in a Modern On-prem environment usually requires developing some additional capabilities among delivery teams. These capabilities will enable teams to unify their SaaS and on-prem delivery efforts, and avoid bifurcating products or code bases in order to support on-prem.
Unifying SaaS and on-prem
One of the biggest risks to converting a legacy SaaS application to run in on-prem environments is that of forking the original app and ending up maintaining two apps. Because delivering a software application is a cross-functional activity, shipping two separate applications will involve hiring and training a full set of developers, operators, support, field-engineering, sales, and product owners for what will effectively become a separate product in an organization.
Many Modern On-prem vendors like GitHub and Jama started with a fork-the-SaaS-app approach, and eventually found themselves rearchitecting their on-prem application to run from the same codebase as their SaaS application. In the remainder of this post, we’ll explore the capabilities required to accomplish this, and some tools that can help do this.
Please. For the love of all that is good in programming, do not make a second repository and try to merge upstream stuff into it. If you have a product of any complexity, it's a nightmare.
Key capabilities
There are a few key capabilities to be developed when developing a Modern On-prem application.
Don’t fork your SaaS app
As
the GitHub enterprise team discovered, if statements like the following are preferable to maintaining a forked copy for on-prem.
if is_onprem:
# On-prem logic
else:
# SaaS logic
Ideally one can minimize the amount of these conditional branches by using swappable external components, but this is a pragmatic way to avoid wrangling git merges across two products as part of a regular development process. As teams develop organizational expertise shipping on-prem, it should be possible to eliminate most of logic branches.
Staging out releases with branches and channels
When adding on-prem distribution channels to an application, it’s important to be able to perform business validation and QA on proposed code changes before shipping. For this, there are generally three tiers of distribution channels: Branch builds, QA Builds, and Production Releases.
Shift Left: Branch Builds and Dev Builds
When developing new features and fixes, its valuable to be able to expose a fully-functional on-prem build that represents the code from a branch or from a local dev environment. Just as software teams of all sizes are shifting left on security, it’s vitally important for teams delivering on-premise software to shift left when it comes to on-prem delivery. The sooner teams can start reviewing and testing on-prem builds of an application, the sooner they can catch critical issues that might not have manifested in the SaaS service.
For example, the Terraform Enterprise team leverages Replicated and CircleCI Enterprise to build an on-prem installable version for every dev branch in GitHub. The amount of testing required for a production release should be minimized. With proper automation and a well-adapted set of smoke tests
QA and Beta Testing
When delivering an on-prem version, its important to have confidence that on-prem builds will work well. Due to the difficulty of rollbacks when compared to SaaS, manual testing of on-prem software will probably be a necessity.
As a customer base scales, it is valuable to engage a subset of customers as Beta testers. This requires exposing a separate pre-production release channel that will be accessible by certain customers, allowing customers to preview new features and fixes before they are distributed to all customers. Tooling can eventually be built to allow TAMs and CSEs to control which end users have access to beta builds.
Production releases
Finally, it’s necessary be able to flag a version of the app as being stable and ready for use by end customers. To start, this flagging is usually performed by developers, especially if branches or git tags are used to trigger the automation around a production release. Fully developing this capability means building tools for Product or Release teams to trigger these production releases.
Further, some on-prem customers will want releases on certain cadences. Some will only accept releases quarterly, others might be willing to install new stable releases every week if they are made available. At some point Modern On-prem might even enable something resembling continuous delivery for third-party applications. Vendors will want to create tooling for sales and support teams to control which of their customers should received releases from which channels. This is often closely tied to how they implement an on-prem licensing strategy.
Enable dev teams
Depending on scale and the number of products being delivered on-prem, it will eventually be valuable to build a system such that dev teams building products can add one line to their CI system and they get an on-prem installable version of that product. This will help to consolidate packaging tooling, and should prove fairly low effort if organizational competence is built around some of the tools and disciplines for delivering Modern On-prem.
