Шаблон для работы правильного 1С разработчика

• содержит выработанную и обдуманную семантически структуру каталогов
• содержит необходимые подмодули для быстрого старта

Порядок установки

• прочитайте Wiki
• склонируйте репозиторий

git clone https://github.com/silverbulleters/vanessa-bootstrap.git <название-вашего-продукта-1С>

• подключите репозиторий к своему git серверу (GitHub, Bitbucket, GitLab, etc)

cd <название-вашего-продукта-1С>
git remote set-url origin git://new.url.here

• не забудьте подписаться на обновление шаблона

git remote set-url bootstrap https://github.com/silverbulleters/vanessa-bootstrap.git

теперь вы можете начинать разрабатывать по правильному и быть подписанными на любые изменения.

Порядок работы 1С специалиста

• как настоящий 1С специалист новую конфигурацию подключите к Хранилищу 1С (если вы разрабатываете внешнюю обработку, этот пункт можете пропустить)
• настройте на своем CI-сервере выгрузку исходников из Хранилища 1С в git репозиторий с помощью Yet Another Unpack - выгрузку лучше всего настроить в каталог .\src\configuration
• обратите внимание на проект по исправлению артефактов 1С при выгрузке в исходники - если вы видите странные изменения в xml файлах, значит необходимо описать пример в качестве запроса https://github.com/pumbaEO/undiff1c/issues, чтобы исключить проблемы выгрузки.
• обратите внимание на наличие у вас интерпретатора python для работы с precommit1C - конечная цель чтобы в каталоге src находились все epf файлы анаходящиеся в репозитории, только в виде исходников.
• следите за обновлением шаблона
• подпишитесь на изменения WiKi в виде RSS канала https://github.com/silverbulleters/vanessa-bootstrap/wiki.atom

Порядок обновления шаблона

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

git config --local merge.ours.driver true

Чтобы получить изменения каталога, получите изменения, без фиксации:

git pull --no-commit bootstrap master

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

Если вы уже ведете разработку на 1С при помощи Git репозиториев

создайте как это положено в git-flow отдельную тематическую ветку

git-flow new-feature new-catalog-structure

добавьте новый внешний репозиторий, как это указано выше

git remote set-url bootstrap https://github.com/silverbulleters/vanessa-bootstrap.git

здесь необходимо обратить внимание на функционал "Стратегий объединения" (merge strategies)
для этого используется файл .gitattributes в котором указано как файлы не объединять из основного репозитория с шаблоном

получите изменения из нового внешнего репозитория без применения изменений

git fetch bootstrap

включите стратегию слияния для текущего репозитория - чтобы изменения шаблона каталогов не изменяли ваш проект

git config --local merge.ours.driver true

и получаем изменения шаблона

git pull --no-commit bootstrap master

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

Возможности доработки шаблона

• откройте issue - если вам не хватает кого-то каталога под ваши задачи
• войдите в чат Gitter - чтобы задать дополнительные вопросы
• сделайте fork, внесите изменения и выполните pull request с предлагаемыми вами изменениями (fork и pull request - это кнопки на GitHub.)

Важно !!!

В структуре каталогов в ближайшее время НЕ будет каталога tests, это наша осознанная на данный момент позиция. По следующим причинам:

* тестирование это процесс, для него мы используем каталог функциональности(./features) и каталог сценариев тестирования поведения (./features/**/steps_definitions)
* каталог tests НЕ появится никогда, вместе него мы используем каталог spec - в нем хранятся фиксированные данные для проверки поведения, а также интеграционные сценарии проверки поведения
* тесты для 1С опасное семантически понятие. Хочется покрывать тестами модули и функции. Но для быстрого старта и для быстрой пользы заказчику лучше покрывать тестами поведение, что плавно приводит нас к сценариям тестирования, или шагам сценариев, поэтому мы отказываемся от понятия unit-теста. Из нашей практики переход на feature файлы и steps_definitions позволяет второму разработчику на второй feature сократить на 40% время необходимое для реализации сценария тестирования. И это только за счёт перехода на другую концепцию

Если вы не согласны с этим - то тогда вам подойдёт какой-нибудь другой альтернативный проект.

Заметки на полях

• структура содержит адаптацию семантики каталогов для проектов на проекте Graphite от компании 1С (пример текущего каталога из проекта Graphite можно посмотреть тут https://github.com/1C-Company/dt-demo-configuration/tree/master/DemoConfDT)

• для GitFlow в Windows мы советуем использовать программу SourceTree от компании Atlassian, для GitFlow в linux следует использовать расширение git-flow для git

• для управления релизами мы используем Семантическое версионирование