Jump to content
SpravkaCRM.ru - Ваш справочник по CRM
Barmix

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

Recommended Posts

Добрый день.

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

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

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

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

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

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

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

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

 

SuiteCRM 7.10.10, MySQL

 

 

Share this post


Link to post
Share on other sites

Добрый день!

В 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.

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

  • Like 1

Share this post


Link to post
Share on other sites
В 28.05.2019 at 14:00, IBlasterus сказал:

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

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

Share this post


Link to post
Share on other sites
В 27.06.2019 at 18:20, IBlasterus сказал:

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...