Most CMS technologies are what we would call a "coupled CMS." The content authoring and content delivery environments are usually part of the same stack. The act of "going live" with new content or a feature is essentially based on the act of marking a true/false in a database field. There are a lot of problems with coupled CMS platforms around security, performance, scalability, and flexibility (you can learn more here.)
For these reasons and many others, Crafter CMS is built as a decoupled CMS. With a decoupled CMS you author content in one system and publish to another separate system. For platforms like Crafter CMS that are decoupled, when correctly implemented, the architecture provides great solutions for the issues mentioned above. That said, nothing is without its challenges. Decoupled systems, by their nature, are typically very scalable and can have many instances all over the world. Security, scalability, and distribution are no longer issues that only concern the Internet's biggest players like Google and Amazon. Security and distribution impact customer experience, safety and help reduce operating costs. Every brand-conscious and customer-forward organization in the world is focused on these tactical issues.
Once you have a decoupled, distributable deployment model, the challenge becomes making certain that the content on the servers all over the world is the same - everywhere. Every decoupled solution has an approach for this. Some better than others. That said, few if any of the approaches offered out of the box by today's traditional CMS platforms "mathematically" ensure every remote instance is 100% up to date and in sync with every other instance. If there are bugs in the deployment code or there is trouble in the environment you may get out of sync.
In our previous posts, we looked at Crafter CMS and its Git-based versioning (part 1) and distributed repository (part 2). In this post, we'll take a deeper dive into how a Git-based CMS leverages git mechanics to provide a better, more consistent distributed publishing mechanism.
Git-based CMSs use git mechanics to publish content to their decoupled delivery space. When Git reports that its repository is set at a specific version that means that every file is guaranteed to be present and in the proper state for that version, it is. Fact. It's provable.
The reason it's provable is due to the fact that the Git mechanics that underlie a Git-based CMS's content repository are based on Git's purely functional data structures. "The main difference between an arbitrary data structure and a purely functional one is that the latter is (strongly) immutable" ( Wikipedia). What this means is that as commits happen within the repository an entirely new immutable data structure is created containing the changes for the commit. No action is taken on the previous data structure(s.) Nothing you ever change can be lost or corrupted by an operation once the change has been committed. Moreover, in Git, the ID for the commit is essentially a SHA1-hash of metadata and the content in the directory tree. By definition, if a single bit changes anywhere in the tree a new SHA1-hash must be generated.
While this explanation is an oversimplification of Git's algorithm, it is essentially the model of how it works. The point is that two repositories on two different machines with the same commit ID are mathematically guaranteed to be the same. That's an extremely useful mechanism for versioning but it also is a very large helping hand in publishing. A Git-based CMS publishes (replicates) content based on Git commits. If you want to know if an endpoint on the other side of the world is the same as what you expect, you only have to compare the commit ID(s).
In today's elastically scalable, globally distributed world you can have any number of servers. You need a means to make sure they are all in sync. As you can see above, Git's internal mechanics give us just that. A Git-based CMS has the capacity to scale geographically across an elastic cloud and at the same time make 100% certain that remote instances are consistently running the same version of content and code.
Decoupled CMS platforms provide push-based publishing, offer greater architectural flexibility and are much easier to scale elastically and distribute globally. Along with this increased power and flexibility comes a need to ensure that all remote endpoints are in sync with one another and are up to date. While this problem is solvable, few of today's decoupled CMS platforms provide a solution for this that is 100% guaranteed and mathematically verifiable. Crafter CMS is one such CMS and its Git-based repository leverage Git mechanics for publishing and replication to remote nodes.
Calculating changesets and verifying that an endpoint is in a particular state is based on the proven algorithms and data structures that back Git, the world's most powerful and popular distributed source repository.
Stay tuned for our next blog entry to learn another major reason why you should use a Git-based CMS!