Skip to content

Latest commit

 

History

History
171 lines (119 loc) · 12.8 KB

CONTRIBUTING.md

File metadata and controls

171 lines (119 loc) · 12.8 KB

Коллективное участие в проекте

постоянно наполняемый FAQ для "контрибьюторов"

Прежде чем создавать задачи GitHub

  • старайтесь ознакомиться с документацией по проекту с помощью поиска
  • старайтесь ознакомиться с уже имеющимися задачами с помощью поиска, включая закрытые задачи
  • ознакомьтесь с каталогом features для понимания уже существующего и стабильного функционала
  • будьте в курсе изменений по проекту
    • нажмите watch и star чтобы получать оповещения об изменениях

Старайтесь создавать задачи в формате BDD

  • если вы нашли "недочёт" (bug)
Дано <имею версию проекта>
  И <версию операционной системы>
  И <версию 1С предприятия>
  И <параметры совместимости конфигурации>
  • если хочется добавить новый функционал (enhancement)
Функционал: <Краткое описание>
Как <роль кому нужен функционал>
Чтобы <цель того кому нужен данный функционал>

Как добавить функционал к проекту

мы используем Example mapping, поэтому:

  • всё, что не имеет feature файла - это просто вопрос или "вброс"
  • если существует feature файл только с заголовком - это предварительное требование
  • если в feature файле есть Сценарии - это требование с правилами реализации
  • есть в Сценарии есть шаги - это требование с правилами и примерами

В связи с чем помимо задач, можно использовать концепцию

  • git-flow - коллективная разработка с помощью github
  • pull-request - для черновиков функционала используется каталог .\features\Drafts

Процесс коллективной разработки

в соответствии с принципами Agile и Open Source мы используем

  • итеративный подход к разработке
  • первоначально мы решаем недочёты, а уже затем дорабатываем функционал
  • приоретизация и порядок доработки остаются на усмотрение команды SilverBulleters, LLC

однако это можно изменить 3-мя способами:

Pull-request

если вы разработчик

  • Установите oscript, git и проверьте что данные находятся в переменной PATH, т.е. git, oscript, opm вызываются без указания полного пути в коммандной строке.

  • Дополнительно должен быть установлен пакет vanessa-runner, делать это надо в коммандной строке от имени администратора opm install vanessa-runner.

  • сделайте fork репозитория

  • склонируйте репозитарий себе на машину git clone https://github.com/*ТУТИМЯВАШЕГОПОЛЬЗОВАТЕЛЯ*/add.git

  • переходим в склонированный каталог cd add и выполняем несколько магических комманд

git remote add upstream https://github.com/silverbulleters/add.git 
git fetch upstream
git checkout -b develop upstream/develop 
git pull upstream develop

  • Если до этого не установили необходимые зависимости, необходимо в консоли от имени администратора перейти в папку add и запустить opm install. Результатом будет установленные пакеты необходимые для работы скриптов. Этот шаг необходимо сделать всего 1 раз.

  • На основании ветки develop создаем новую ветку с номером задачи или кратким описанием

git checkout -b feature/issue-9999
  • Для привычной разработки, необходимо инициализировать базовую базу данных для разработки и из исходников собрать epf файлы:
cd add
opm run init

ВНИМАНИЕ: команды opm необходимо выполнять в обычном виндовом cmd\far , но не в bash консоли, т.к. не сможет найти команду opm

  • в случаи, если база уже была успешно проинициализирована, тогда можно просто запустить сборку обработок из новых данных: opm run cepf

  • в каталоге add\build добавьте новый feature-файл, если необходимо

  • отредактируйте при необходимости add\build\bddRunner.epf

  • разработайте step проверки в add\build\features\*

  • после всех доработок можете запустить в каталоге проекта opm run vanessa для проверки в управляемых формах, что ничего не сломали из стандартного функционала.

  • При готовности зафиксировать изменения необходимо теперь сделать обратную операцию в виде разборки *.epf на исходники.

    1. Массово, выполнить команду opm run depf, разбирать будет все обработки из plugins, features, vendor, lib

    ВНИМАНИЕ: возможно будет долгая операция, т.к. скрипт найдет все epf файлы и попробует их разобрать на исходники

    1. Что-бы ускорить обратную разборку, можно указать определенный каталог opm run depf ./features/libraries разберет только ./build/features/libraries в ./features/libraries
    2. Вручную обработку отдельно: в конфигураторе открываем внешнюю обработку и в меню "Действия" -> "Выгрузить файлы", выбираем "Внешняя обработка в иерархическом формате" и указываем путь где будет она находиться.

    Например: для ./build/bddRunner.epf это путь в ./epf/ , для всех остальных каталогов это зеркальное ./build/feature - ./feature

  • В гите проверить необходимые изменения и зафиксировать только их.

Внимание, платформа каждый раз меняет файлы Form.bin, даже если их не меняли. Не надо добавлять Form.bin в гит, если вы не изменяли толстые формы.

Привожу команды для программного добавления необходимых файлов * Смотрим какие файлы изменились git status

Изменения, которые не в индексе для коммита:
  (используйте «git add <файл>…», чтобы добавить файл в индекс)
  (используйте «git checkout -- <файл>…», чтобы отменить изменения
   в рабочем каталоге)

	изменено:      epf/vanessa-behavior/VanessaBehavior/Forms/УправляемаяФорма/Ext/Form/Module.bsl

нет изменений добавленных для коммита
(используйте «git add» и/или «git commit -a»)

  • Добавляем необходимые файлы в индекс git add epf/vanessa-behavior/VanessaBehavior/Forms/УправляемаяФорма/Ext/Form/Module.bsl

  • Фиксируем изменения с комментарием git commit -m "Наш комментарий!"

  • Все эти шаги можно выполнять с какого-либо GUI клиента для git.

  • Отправьте изменения на github git push origin feature/issue-9999

  • Сформируйте pull-request в интерфейсе github.

  • реализуйте функционал или возьмите в работу какую-то задачу

    • обратите внимание - некоторые задачи могут иметь награду DONATIONS.md

Участие в архитектурных обсуждениях

если вы методолог или архитектор

  • сделайте свой первый pull-request, в том числе в документацию
  • создайте обсуждение https://github.com/silverbulleters/add/issues с описанием противоречия
  • участвуйте, обосновывайте, приводите примеры
  • используйте ТРИЗ для построения непротиворечивых решений

Enterprise-поддержка

если вы бизнесмен или менеджер

  • обратитесь по адресу [email protected]
  • заключите контракт на Enterprise-поддержку с гарантией по SLA и c контролем NPS
  • публикуйте любые запросы на доработку и консультацию - они будут выполнены или по ним будет выдан ответ в первом приоритете
    • на данный момент за последние год мы поддерживаем следующие медианы: время реакции - 24 минуты, время решения - 23 часа

BSD v3 License

Наша лицензия поощряет коллективное участие в разработке всего стэка продуктов Vanessa Stack, однако не поощряет использование брендов (с) SilverBulleters, vanessa-stack, vanessa-behavior, vanessa-add и остальных для развития своих неофициальных имплементаций.

Поэтому:

  • используйте, дорабатывайте через концепцию fork и pull-request официальный продукт silverbulleters/add
  • если вы хотите создать свой продукт на основе vanessa-behavior, это разрешено и не противоречит лицензии BSD v3
  • однако, если вы хотите использовать для рекламирования и продвижения своего продукта бренды "SilverBulleters", "Vanessa Behavior" или "Vanessa ADD", вам необходимо получить у нас разрешение на это, написав на адрес [email protected] или создать Issue на GitHub

Поэтому интернет-маркетологов просим быть осторожней при использовании символики Vanessa и SilverBulleters

CLA - лицензия на коллективное участие

Мы придерживаемся https://cla.github.com/agreement что означает Ваш вклад не нарушает никаких наших прав и не накладывает на нас никаких ограничений и обязательств.

Если ничего не понятно

  • используйте чат Gitter для того чтобы задать вопрос https://gitter.im/silverbulleters
  • запишитесь на практические занятия по правильной разработке 1С

(c) SilverBulleter, LLC - последнее обновление: 06.11.2017