We are running a development platform with about 30 developers and thus we are often bothered with a slow working SF, which primarily happens when someone is either generating definitions,validating definitions or executing a merge. But it also can happen sometimes just by trying to save a template or a new table column.
The root cause of this, in my opinion, is the fact that all of our transactions within the SF are executed on one single SF database. Especially during generation or merging a lot of data is being read, deleted or created in that single database, which often results in a slow performance or even processes being assigned as deadlock victim.
I believe the performance of the SF could largely be improved if we were able to run multiple instances of the SF database, maybe even across multiple database servers, and be able to merge branches from different databases. A couple of great benefits are:
- Whenever I work in a branch I am only bothering people that work in the same branch as I do or at least people that work in the same SF database that I do.
- It greatly improves scalability, especially when it supports multiple database servers
Especially the first benefit is great for a performance improvement.
With about 30 people developing there are several merges happening in a week. Consider the trunk to have it’s own SF-database and executing a merge to the trunk. This merge will then primarily lock access to the SF-database that belongs to the trunk and not slow down performance of the other 29 developers still developing in their own branches.
In the 2023.1 version of the Software Factory the way projects/project versions are managed will be changed.
Up to the 2022.2 release, version control in the Software Factory was handled by creating a copy of an entire model as a project version. However, changes only make up a minor percentage of the entire model, so all the other unnecessarily copied data made the Software Factory databases grow over time and become slower due to their size.
To solve this problem, we will handle version control from now on by using temporal tables. These tables, also known as system-versioned tables, are a database feature that brings built-in support for providing historical data. It means that only the latest version of every project will be stored, and all old data will be moved to history tables. This way, data modifications will be stored only once. The historical data can be accessed whenever required by requesting them for a specific time in the past.
So even though our approach was somewhat different then your suggested solution, it should definitely help when it comes to growing databases and performance issues.