Understanding Hippo's Design
NOTE: As of current writing, the actual Hippo data model and flow are not quite where this document says they are. That’s because Hippo is ~a journey~ a work in progress, and we’re figuring things out as we go. This document is how we currently think things ought to work, but the code may reflect older thinking.
Hippo is a tool for deploying applications. An application is defined in a rather circular way, as the unit of deployment for Hippo. That is, although its code and structure may change, and although different versions may be deployed at the same time, an application is deployed and versioned as a single thing.
An example of an application is a weather service or a to-do list.
The various versions of an application are stored as bindles. A bindle associated with an application is called a revision. Revisions don’t do anything in themselves - they just record that Hippo knows about the bindle and which application is belongs to. NOTE: We’re not sure if this is what revisions model in the existing code - may need to review this.
The weather application example might have bindles - and therefore revisions
Applications are deployed via channels. A channel represents a particular configuration or use case of the application. A typical use of channels is for the stages of maturity of an application, but you can use them for any situation where you want to have different versions or different configurations.
The weather application might have channels named
development(for work in progress),
staging(for pre-production testing), and
production(for the live site). If the weather application served different communities, it could also have channels such as
production/samoaconfigured for those specific communities.
NOTE: The existing code includes the concept of releases, which capture the pairing of a channel and a revision. We’re not sure if those are still meaningful.
What does a channel control?
The bulk of configuration is done at the channel level. A channel controls:
- Environment variables
The weather application might use a
DATA_SOURCEenvironment variable to determine where it gets its weather information from. In the
developmentchannel this could be set to a static, historical data set for predictable testing. In
productionit could point to a live weather feed.
- The domain to serve on
You might serve the
- Which revision of the application to run - see below
Channels and revisions
Revisions are defined at application scope - they are bindles that Hippo knows are associated with the application. However, it is up to each channel which revision it actually uses. A channel may choose in one of two ways:
- Rules based (auto deploy). The channel will serve the most recent revision
that meets its constraints. Here ‘recent’ is defined as the highest version
number. NOTE: We have not yet fully defined how prerelease segments
interact with this.
productionchannel might be configured to serve “the most recent revision whose minor version is 1.1”. If the application had revisions 1.1.0, 1.1.1 and 1.2.0,
productionwould serve 1.1.1. If you added revision 1.1.2, then
productionwould automatically switch to that.
- Specific revision. The channel will serve the specific revision given.
productionchannel might be configured to serve revision 1.1.1, and require a manual update to switch it over to a new revision.
NOTE: At the database level we can’t easily express this either-or choice. We
currently expect to have a
rules column and a
revision column, both
nullable, and a
revision_selection_mode column that says which to use. The
application has to enforce that the appropriate column is not NULL.
A channel always has a current revision - the revision being served, whether specific or derived from the rules.
A snapshot represents what a channel was serving at a particular time. Configuration such as domain and environment variables is copied when the snapshot is taken. The snapshot also copies the channel’s current revision.
If you roll a channel back to a snapshot, the snapshot’s configuration overwrites the channel’s configuration, and the channel is set to serve the specific revision in the snapshot. If the channel was rules-based, it stops being rules based; it is a manual action to set it back to being rules-based.