Как переносить доработки SuiteCRM

[Barmix]

Добрый день.

Есть 3 сервера SuiteCRM: DEV, DEMO, PROD.

Хотелось бы упростить (читай ускорить, в идеале автоматизировать) перенос доработок DEV => DEMO и DEMO => PROD.

Есть идея использовать репозиторий для хранения файлов и забирать изменения из него.

Но тут возникает сразу несколько вопросов:

1. Какие файлы надо исключить из контроля версий?

2. Как правильно отслеживать и применять изменения в базе? Есть опыт, что достаточно скопировать файлы .php и изменения в базе обработает "быстрое восстановление". Можно  ли всегда так делать?

3. Насколько приемлем вариант разработки сразу на площадке DEV, без создания у себя локальной копии CRM? Как в этом случае вести одновременно несколько доработок?

Просьба поделиться опытом в вопросе организации репозитория и контроля версий. А также других возможных способах упрощения переноса доработок между площадками.

 

SuiteCRM 7.10.10, MySQL

 

 

[SpravkaCRM.ru]

Добрый день!

В 28.11.2018 at 14:05, Barmix сказал:

1. Какие файлы надо исключить из контроля версий?

Общий принцип: исключаем файлы, которые являются автогенерируемыми (папка cache, папки Ext в /custom/modules) и так далее. Так же исключаем загружаемые файлы, историю изменений metadata-файлов, индексы поиска, служебные файлы разных GUI и прочее. Я сталкивался с тем, что некоторые системные администраторы пытаются засунуть в .gitignore core-файлы типа того, что находится в папках Zend, XTemplate и так далее обосновывая тем, что не надо эти файлы править, значит и в гите им делать нечего. Я против такого подхода. Считаю, что в git должны быть файлы, достаточные для корректного запуска SuiteCRM в том месте, где его развернули из git-репозитория.

Вот файл .gitignore одного из проектов:

*.log
.DS_Store
Thumbs.db
/cache/*
/.idea/*
/config.php
/config_override.php
/tmp/
/upload/
/custom/screenshots/
/test_*.php
/custom/blowfish/*
/custom/history/*
/custom/modulebuilder/*
/custom/working/*
/custom/application/Ext/
/custom/modules/*/Ext/
/custom/modules/unified_search_modules_display.php
/modules/AOD_Index/Index/*
/.htaccess
/custom/client_secret.json
/custom/appsactivity-php-quickstart.json

 

В 28.11.2018 at 14:05, Barmix сказал:

2. Как правильно отслеживать и применять изменения в базе? Есть опыт, что достаточно скопировать файлы .php и изменения в базе обработает "быстрое восстановление". Можно  ли всегда так делать?

Такой подход комфортно работает если изменения структуры модулей делать не в студии, а вручную. Поля, добавляемые в студии, вносят meta-данные (vardef) в таблицу в БД, а она через git не обновляется. А если будете расширять список полей вручную, то вполне сможете работать через git запуская быстрое восстановление.

 

В 28.11.2018 at 14:05, Barmix сказал:

3. Насколько приемлем вариант разработки сразу на площадке DEV, без создания у себя локальной копии CRM? Как в этом случае вести одновременно несколько доработок?

 

Не претендую на супер-универсальность и что это решение самое лучшее, но вот одна из реализаций, которой пользуемся наиболее часто:

Ветки + сервера:

1. В git-репозитории создаем ветку master. Эта ветка содержит состояние файлов на PROD-сервере
2. В git-репозитории создаем ветку test. Эта ветка содержит состояние файлов на TEST-сервере
3. В git-репозитории создаем произвольное кол-во веток с конкретными задачами, находящимися в работе (по 1-ой ветке на каждую задачу)

Процесс работы:

1. Берем очередную задачу в работу: из master делаем ветку с задачей. работаем в ней. Как правило это удаленная ветка, так как в процессе работы над задачей часто работают несколько человек.
2. После выполнения задачи она окончательно пушится на сервер.
3. Делается мерж ветки test и ветки с задачей. На тестовом сервере делаем pull ветки test и проверяем работу.
4. Если все норм, то ветка с задачей мержится с веткой master
5. Если что то не норм, то ветка с задачей просто уходит в доработку.
6. Ветки test и master никогда не мержатся. Все происходит именно путем мержа ветки с задачей.

 

P.S.

надо видимо уведомления где то тут найти чтобы на почту приходили... а то задача то наверное уже не актуальна ... больше для тех, кто по поиску потом придет...

[IBlasterus]

Как вы потом заливаете изменения из гита в конкретную папку веб-сервера?

[IBlasterus]

В 28.05.2019 at 14:00, IBlasterus сказал:

Как вы потом заливаете изменения из гита в конкретную папку веб-сервера?

Есть идея. На веб-сервере поставить гит, и выполнять раз в минуту с помощью скрипта в кроне git pull ветки production.
В том же GitLab сделать эту ветку защищенной и сливать в неё обновы.

[Guest Palach]

В 27.06.2019 at 18:20, IBlasterus сказал:

Есть идея. На веб-сервере поставить гит, и выполнять раз в минуту с помощью скрипта в кроне git pull ветки production.
В том же GitLab сделать эту ветку защищенной и сливать в неё обновы.

в гитлабе есть возможность деплоя на сервер через gitlab CI