Introducing Versioning in a Content Management System
With tons of minor to major edits daily, keeping track of all content changes becomes challenging for content and website administrators, and that’s where content versioning comes into the picture. It is the concept of tracking different versions of content updates to answer simple day-to-day operations, such as:
- What edits were made?
- When was content changed?
- Who made the changes?
- What is the difference between previous and updated content?
Content versioning answers all these questions to make everyday operations efficient and seamless. The best example to understand content versioning is Google Docs. You can view version history, real-time changes and roll back to any version of the document without any hassle.
Since we are a swiftly scaling online higher education providing platform, our website upGrad.com requires constant changes. Almost until a couple of years ago, the content edits on the website were still being done by the technology team. This included information about our programs, and how they add value to an individual’s career. Even though most of this data was in the form of JSON, it required constant code changes to update the website. To solve this, we built Apollo, our in-house content management system (CMS). Apollo allowed us to add, alter, and delete content on the fly. Over these two years, content editing has streamlined and individual program owners now own their respective content. But as it is true in software engineering — you never solve a problem completely, you only get mature enough to solve greater ones. Along with immense flexibility, Apollo also brought in some complications, which eventually raised the need for introducing versioning.
The Why
As mentioned, Apollo CMS allowed our internal programmers and administrators to edit website content hassle-free. But over time, managing a track of every edit became hectic. When we realized that editing content with Apollo was creating problems, we started looking for a solution, and we found that versioning can be a potential fit. But what were the issues that kept us looking for a solution like versioning?
What we used to do is have separate collections for components, layouts, and pages on Apollo. The CMS is backed by a Nodejs server using a MongoDB database. The initial design was more like a relational DB. To represent a page’s data, we included references for components into layouts and then layouts’ references into the page. This led to a mesh topology where every document was connected to several components, layouts, and pages from.
As the size of the data and frequency of edits increased, keeping track of every edit with such infrastructure was challenging. Also, it was troubling to delete or rollback to any previous point in the website. For instance, if we wanted to delete any particular document, we had to go through the entire mesh topology and look for references of all the components, layouts, and pages associated with that collection. Hence, it was hectic for everyone, right from content managers to us, developers, to delete or revert to any previously updated webpage.
Each query’s response time was also increasing as the program had to go through the entire database. Slow response time affected the performance of the whole website, which was not acceptable by us. All these problems led to an urgency for introducing versioning in Apollo.
The How
We introduced versioning in Apollo by eliminating the step of instance references; instead, we started storing the actual instances in each collection. This reduced mesh topology’s complexity, and now everything, with actual instances, was held in a single collection. Hence, everything: tracking, altering, reverting, and deleting content became more straightforward.
Our CMS was now storing data about who was changing what content at what particular time. Even a minor edit was creating a new version of the entire collection. The administrator and internal programmers now had the option to compare the changes side by side to see how they will affect the website’s whole layout.
We created two stacks of pages, one for storing only the latest page version and the other for keeping the latest and older versions. Whenever a query was called to retrieve the latest version or when someone visited the website, the program would take the code from the stack with the newest version and give the output to reduce response time and enhance performance. On the other hand, if the administrator wanted to compare two versions, he can merely head to the versioning interface and select any two versions to see the differences between them.
The Seamless Transition to Content Versioning
Let’s look at an elementary example to understand what’s the difference between the older Apollo and the newer one with versioning. The below table showcases how the versions are made, and the collection is changed with each edit.
+----------------+------------------+----------+-------------+
| Global Version | Internal Version |
+----------------+------------------+----------+-------------+
| 1 | Page | Layout | Component |
+----------------+------------------+----------+-------------+
| 2 | Page | Layout | Component 1 |
+----------------+------------------+----------+-------------+
| 3 | Page | Layout | Component 2 |
+----------------+------------------+----------+-------------+
| 4 | Page | Layout 1 | Component 2 |
+----------------+------------------+----------+-------------+
| 5 | Page | Layout 1 | Component 3 |
+----------------+------------------+----------+-------------+
| 6 | Page | Layout 2 | Component 3 |
+----------------+------------------+----------+-------------+
| 7 | Page | Layout 2 | Component 4 |
+----------------+------------------+----------+-------------+
| 8 | Page | Layout 2 | Component 5 |
+----------------+------------------+----------+-------------+Without versioning, the administrator had to pass queries to search through the entire website code to add, alter, rollback, or delete any content. With versioning in place, the administrator only has to select a particular global version number to find out all the details about that version. It became possible to track changes, rollback, or delete content with just a few clicks without worrying about the associated instance references.
How Versioning of CMS Helped Us?
This initiative of introducing content versioning in CMS provided us with numerous benefits, the most significant ones are:
Easy traceability: With versioning, we could track even minute changes and details such as who made the changes, what changes were made, and when they were made. It also allows us to compare the data on two versions by highlighting the changes made.
Enhanced performance: The speed and overall performance of the website were improved. For instance, to navigate a page with 3 layouts and 15 components, the program had to run 1 x 3 x 15 = 45 queries to provide the results as each collection of stored instance references. But now, with versioning, since everything is in a single collection, the program only has to run a single query for getting the output. This led to enhanced performance.
Efficient content management: Versioning allowed our internal programmers, content managers, and administrators to manage the entire website efficiently. Everything right from adding, updating, altering, reverting, and deleting content on the website became hassle-free and easy.
Introducing versioning in Apollo has helped us overcome the hurdles in efficiently managing our website. This has not only increased traceability but also has made reverting to older versions easy and has improved content stability. As engineers, this was an interesting problem to solve, deriving inspiration from versioning systems like git . If you are interested in solving similar and other interesting problems, do check out our careers page. We are always on the lookout for ambitious, talented folks!
Do visit upGrad.com to check out our programs that are completely online!
Contributors: Jawad Sonalkar
