With our 1.0 release, Spread now versions your software environment (i.e. a Kubernetes cluster) like Git versions source code. Because Spread is built on top of libgit2, it takes advantage of Git's interface and functionality. This means after you deploy your Kubernetes objects to a cluster, you can version those objects by staging, committing, and pushing them to a Spread repository.

The key difference between Spread and Git is what we are versioning: the structured data of the deployment. Unlike with normal text files, structured data includes the context of the information. This means we know which configuration fields mean what, or what "type" (string, boolean, integer, etc) those fields expect. This enables us to both programmatically "back up" Kubernetes clusters and to build new functionality on top of this contextual information, like linking between fields or objects.

Versioning the cluster itself also provides a standard format for merging the cluster - because Kubernetes deployments can be created in a variety of ways (ex: scripts or YAML/JSON files), right now there isn't a good way to compare two arbitrary clusters, or environments. One exciting use case is the ability to diff two clusters against each other, making it easy to track differences in software environments.

We'd love to hear your thoughts on deployment versioning - join the discussion on Twitter @redspread or shoot us a note at [email protected].