1c/1C-Functin-to-yEd
1
0
Fork 0
mirror of https://github.com/SergeFocus/1C-Functin-to-yEd.git synced 2025-03-03 14:32:19 +02:00
Code Issues Releases Activity

обновлена документация вследствии работы с шаблоном в пяти конфигурациях, в 3-ех командах разработки

Browse Source
This commit is contained in:
Alexey Lustin 2015-10-09 03:06:38 +03:00
parent deedb47619
commit cddeddf80c
1 changed files with 16 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
README.md
View File

@ -25,18 +25,26 @@ git remote set-url origin git://new.url.here
```Shell
git remote set-url bootstrap https://github.com/silverbulleters/vanessa-bootstrap.git
```
теперь вы можете начинать разрабатывать по правильному и быть подписанными на любые изменениями.
### Порядок обновления
#### Порядок работы 1С специалиста
включите стратегию слияния для текущего репозитория - чтобы изменения шаблона каталогов не мешали в вашем проекте
* как настоящий 1С специалист новую конфигурацию подключите к Хранилищу 1С (если вы разрабатываете внешнюю обработку, этот пункту можете пропустить)
* настройте на своем CI сервере выгрузку исходников из [Хранилища 1С](http://v8.1c.ru/overview/DeveloperGroupp.htm) в git репозиторий с помощью [Yet Another Unpack](https://github.com/silverbulleters/vanessa-unpack) - выгрузку лучше всего настроить в каталог .\src\configuration
* обратите внимание на проект [по исправлению артефактов 1С при выгрузке в исходники](https://github.com/pumbaEO/undiff1c/blob/master/src/undiff1c/undiff1c.py) - если вы видите странные изменения в xml файлах, значит необходимо описать пример в качестве запроса https://github.com/pumbaEO/undiff1c/issues, чтобы исключить проблемы выгрузки.
* обратите внимание на наличие у вас интерпретатора python для работы с [precommit1C](https://github.com/pumbaEO/precommit1c) - конечная цель чтобы в каталоге src находились все epf файлы анаходящиеся в репозитории, только в виде исходников.
* следите за обновлением шаблона
* подпишитесь на изменения WiKi в виде RSS канала https://github.com/silverbulleters/vanessa-bootstrap/wiki.atom
### Порядок обновления шаблона
включите стратегию слияния для текущего репозитория - чтобы изменения шаблона каталогов не мешали в вашем проекте тем изменениям, которые вы сделали в процессе реальной работы
```Shell
git config --local merge.ours.driver true
```
Чтобы получить изменения каталога
Чтобы получить изменения каталога, получите изменения, без фиксации:
```Shell
git pull --no-commit bootstrap master
@ -90,11 +98,11 @@ git pull --no-commit bootstrap master
~~~
Важно !!!
В структуре каталогов в ближайшее время НЕ будет каталога tests, это наша осознанная на данный момент позициция. По следующим причинам:
В структуре каталогов в ближайшее время НЕ будет каталога tests, это наша осознанная на данный момент позиция. По следующим причинам:
* тестирование это процесс, для него мы используем каталог функциональности(./features) и каталог сценариев тестирования (./features/**/steps_definitions)
* каталог tests может появиться только в случаях когда будет иметься практика построения интеграционных тестов, например с помощью проектов JMeter
* тесты для 1С опасное семантически понятие. Хочется покрывать тестами модули и функции. Но для быстрого старта и для быстрой пользы заказчику лучше покрывать тестами поведение, что плавно приводит нас к сценариям тестирования, или шагам сценариев, поэтому мы отказываемся от понятия unit теста. Из нашей практики переход на feature файлы и steps_definitions позволяет второму разработчику на второй feature сократить на 40% время необходимое для реализации сценария тестирования. И это только за счёт перехода на другую концепцию
* тестирование это процесс, для него мы используем каталог функциональности(./features) и каталог сценариев тестирования поведения (./features/**/steps_definitions)
* каталог tests НЕ появится никогда, вместе него мы используем каталог spec - в нем хранятся фиксированные данные для проверки поведения, а также интеграционные сценарии проверки поведения
* тесты для 1С опасное семантически понятие. Хочется покрывать тестами модули и функции. Но для быстрого старта и для быстрой пользы заказчику лучше покрывать тестами поведение, что плавно приводит нас к сценариям тестирования, или шагам сценариев, поэтому мы отказываемся от понятия unit теста. Из нашей практики переход на feature файлы и steps_definitions позволяет второму разработчику на второй feature сократить на 40% время необходимое для реализации сценария тестирования. И это только за счёт перехода на другую концепцию
если вы не согласны с этим - то тогда вам подойдёт какой-нибудь другой альтернативный проект
~~~