[Vtigercrm-developers] Vtiger: Git code base + Deployment

[Martin Allen]

We have a private Git repo for vTiger – this repo is actually of the codebase AFTER installation. This repo is then used to manage the different versions of vTiger as they are released. (hence pushing for proper semantic version numbering to make this far easier to spot hotfixes etc!)

Then for each deployment of vTiger we clone this repo to a new one specifically for each installation. By cloning it, this allows access to the original repo, as an upstream source for deploying updates later.
Each individual repo can then be customised and managed.
vTiger updates are then added to the main repo, and can be merged into each individual repo as required, to merge with any customisations.

Actual deployments do require us to do a standard installation process (to create database etc), but after wards is then managed via GIT, and as you said any new fields / modules/ database changes are recorded ins PHP vtlib/vtwsclib scripts so they can re-run on production and development servers. (This is slightly laborious but works – would be FANTASTIC to have a database migration that can be run independently 😉 )
Updates we do the same, we run the update to actually update database, and having already ‘fixed’ the codebase on our development server, then merge and deploy these fixes straight over the production branch/server.

From: vtigercrm-developers-bounces at lists.vtigercrm.com <vtigercrm-developers-bounces at lists.vtigercrm.com> On Behalf Of Sukhdev Mohan
Sent: 23 July 2021 17:36
To: vtigercrm-developers at lists.vtigercrm.com
Subject: [Vtigercrm-developers] Vtiger: Git code base + Deployment

Hi All,

I’m sure you all face this problem: each installation is custom,  you develop modules/estensions edit core files etc Since anything in vtiger is mapped into vtiger_crmentity table and mod_tracker (which is heavy as hell), each new field is saved on db (vtiger_field) and there is no trace of them on code if not the scripts that adds them. Same goes for the modules you create.

This requires to create different repos for all the clients, while instead we could think of vtiger code as base and do not touch it (even using code.vtiger.com and fetching the desired version) and host the variations for project somewhere else and manage the customisation through a migration system (php script? Zip package? Sql?).

For example:
I fetch the vtiger7.4 and install the version, then through a migration system add the customisations.

This would lead to automate deployment to prod instead of manually transfer db and development code to the clients machine, reducing human error.

What do you guys think? How can we achieve this mechanism?

Sukhdev Mohan
Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20210726/49afecb4/attachment.html>