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.

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×