<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">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!)
<br>
<br>
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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Each individual repo can then be customised and managed.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">vTiger updates are then added to the main repo, and can be merged into each individual repo as required, to merge with any customisations.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><br>
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
</span><span style="font-family:"Segoe UI Emoji",sans-serif;mso-fareast-language:EN-US">😉</span><span style="mso-fareast-language:EN-US"> )<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">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. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> vtigercrm-developers-bounces@lists.vtigercrm.com <vtigercrm-developers-bounces@lists.vtigercrm.com>
<b>On Behalf Of </b>Sukhdev Mohan<br>
<b>Sent:</b> 23 July 2021 17:36<br>
<b>To:</b> vtigercrm-developers@lists.vtigercrm.com<br>
<b>Subject:</b> [Vtigercrm-developers] Vtiger: Git code base + Deployment<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div name="messageBodySection">
<div>
<p class="MsoNormal">Hi All,<br>
<br>
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. <br>
<br>
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?). <br>
<br>
For example:<br>
I fetch the vtiger7.4 and install the version, then through a migration system add the customisations.<br>
<br>
This would lead to automate deployment to prod instead of manually transfer db and development code to the clients machine, reducing human error.<br>
<br>
What do you guys think? How can we achieve this mechanism?<o:p></o:p></p>
</div>
</div>
<div name="messageSignatureSection">
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><b><span style="color:#C6C6C6">Sukhdev Mohan</span></b><br>
<b><span style="color:#999999">Developer</span></b><o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>