Hi, does anyone have information on how best to carry out branching development in Creatio using Git? We've found plenty of pitfalls and issues with doing so that we work around in various ways, but it doesn't feel particularly streamlined and has plenty of trial and error involved, which isn't ideal!
Some of the things we encounter are desynchronisation of the database with the config, various errors thrown by the compiler, quite a consumption in time of switching branches, it being a bit easy to lose config changes unless you are very precise about how you change branches etc.
Based on our experience, most problems occur when switching branches that have different objects (for example, an object exists in one branch but not in another). This issue is not exclusive to Creatio but is common to all projects that use an ORM (Object-Relational Mapping) system to manage the database, such as EntityFramework. Therefore, the advice here is to avoid switching between such branches. If you must do so, remember to remove reverse references between objects (which are created for OData). I do this by executing the following queries in the database:
```sql DELETE FROM SysSchemaSource WHERE SysSchemaId IN (SELECT Id FROM SysSchema WHERE SysPackageId NOT IN (SELECT Id FROM SysPackage)); DELETE FROM SysSchema WHERE SysPackageId NOT IN (SELECT Id FROM SysPackage); DELETE FROM SysPackageSchemaData WHERE SysPackageId NOT IN (SELECT Id FROM SysPackage); DELETE FROM SysSchemaSource WHERE Name LIKE '%backreference%'; ```
After that, I perform a compilation.
Additionally, frontend schemas also have connections through the configuration (for example, the `SysModuleEdit` table), and if the schemas are missing, you might end up with a non-working UI.
In different branches, schemas can also be moved between packages, and the relationships in the configuration can break because of this.
This is precisely why only SVN is officially supported, and using Git comes with limitations similar to those when using SVN.
You should also consider that Git only deletes files, but folders may remain empty. While this is not an issue for Git, it is very important for Creatio. All empty folders are perceived as packages, and if a folder is empty, it will be populated when exporting code to the file system.
Also, deleting a package through Git will not remove the package in the configuration because Creatio reacts only to code changes, and if there are none, no changes will occur.
Our team has a whole list of such nuances, but we have written PowerShell scripts to solve most of them (for example, deleting all empty folders or removing a SQL script that remains when renaming it through the configuration and a new one is created with a new name).
I can describe our other rules as well, but that would take more time.
P.S. The Creatio system is well-designed if you follow its development features and keep it clean (for example, developers often delete schemas without removing resources, or they move schemas between packages through the file system to save time instead of doing it through the configurator). If you establish rules, adhere to them, and use helper scripts, development won't cause unpleasant issues.
Unfortunately, there is no universal recommendation that could completely resolve your issue. However, here are a few key points to consider:
1) All packages in the configuration should be tied to a single Git repository, since they depend on each other and need to be saved as part of a single commit. (It's not recommended to store each package in a separate repository.)
2) Automatically generated folders in independent packages should be added to the .gitignore file.
3) The obj folders in independent packages should also be added to the .gitignore.
4) Only your custom packages should be added to the repository. For vendor packages (from Creatio) and Marketplace packages, use the standard methods (application installation, upgrading to a new version).
5) Never modify vendor packages (from Creatio). To extend functionality, use inheritance and entity substitution.
6) Schema metadata is difficult to merge and understand, so it is recommended that only one developer works on extending objects or modifying a specific schema.
7) If a developer makes changes in one environment and commits them to the repository, and others pull these changes, there should be no database and configuration desynchronization issues.
8) You can create scripts to quickly set up the environment and pull the necessary branch from the repository. This will help avoid issues with leftover data from a different branch.
