[Vtigercrm-developers] Features DevOps friendly and other nice to have features
Martin Allen
martin.allen at clystnet.com
Thu Oct 22 15:10:02 GMT 2020
If you're adding fields or modules then the best way we've found to do so
is to use vtlib scripts to create, then when migrating from one environment
to another, just have to run the relevant scripts (we manage those scripts
internally and run them manually, but could easily write some PHP to
automatically run any scripts in a folder and then remove them once run?
Anything that requires direct database manipulation (e.g. changing values
on existing fields) should be done as a SQL query which can be run as its
own migration script.
Martin Allen
*01392 248692 - Main Office01392 690659 - Direct Line*
*[image: signature2]*
Have you visited our website recently? https://www.clystnet.com
<http://www.clystnet.com/>
The information in this email is confidential If you are not the intended
recipient, you must not read or use that information. This email and any
attachments are believed to be virus free however no responsibility is
accepted by Clystnet for any loss or damage arising in any way from receipt
or use thereof. Clystnet Ltd (company reg number 7164503) is based at
Silverdown Park, Fair Oak Close, Clyst Honiton, EX5 2UX
On Thu, 22 Oct 2020 at 15:37, Sukhdev Mohan <s.mohan at myti.it> wrote:
> Hello All,
>
> We have been using VTiger and we are now trying to use DevOps. With other
> projects we set 3 three environments
> 1. Dev - local/vm/docker/vagrant
> 2. Test - Our Server
> 3. Prod - Client’s server
>
> The *ideal *developing cycle is we have multiple branches on out private
> repo for local dev, these branches than merges into the develop which is on
> Test env, after it’s tested out we release it to the clients server.
> Sometimes client can access the test env so that we can fix issues before
> release.
>
> We would like to do the same with Vtiger but we have a *STRONG* limitation:
> vtiger_crmentity, vtiger_crmentityseq and the variations done to
> vtiger_field, vtiger_fieldmodulerel, vtiger_ws_entity, vtiger_entityname
> and so on and so forth. Basically the local db can’t be different because
> there is no migrations which trace the sql which changes the db structure.
>
> So is there any way to capture the queries you perform, for example table
> creation, table alter, field creations? This would make life easier for a
> lot of vtiger devs and also would make it easy to port the platform.
>
> Pleae let me know your thoughts, may be we can team up and come up with
> something useful to the community?
>
> Best Regards,
> *Sukhdev Mohan* | *Software Developer*
>
>
>
>
>
>
>
> _______________________________________________
> http://www.vtiger.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20201022/53421994/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 10550 bytes
Desc: not available
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20201022/53421994/attachment-0001.png>
More information about the vtigercrm-developers
mailing list