В том, что описан в статье еще нет. В следующих релизах стоит в планах внедрить этот инструмент, мы считаем его перспективной заменой (начать хотим с использования в разработке самих инструментов стенда – в первой очереди разработку СППР на нее перевести). В остальном пока только нацелены на перевод на EDT разработки внешних к конфе механизмов (расширения, внешние обработки-отчеты), — по нашим текущим попыткам, использовать его для конфигураций больших пока вообще нереально, для средних очень туго и мощные машинки приходится использовать (производительность некоторых операций страдает пока, достаточно ошибок, с нетерпением ждем и щупаем выходящие релизы).
Если разработчиков 5, то должно быть столько веток, сколько принято в вашем flow, и, как я написал выше, у нас на текущий момент процесс построен так, чтобы достаточно было 1-2 веток. И да, ветки создаются из хранилищ (исключением могут быть патчи и все что создается вне конфигурации – внешние обработки, скрипты, внешние алгоритмы, запросы, геркины и тп – это только в гите и тут близкий git-flow процесс используется).
Обязательно пообщаемся, я в курсе соц.ресурсов сообщества. Соберу в кучу мысли и поделки нашей команды, и что из этого можно обсудить и попробуем. Думаю, они и без этого участвуют.
У нас пока активно используются хранилища, поэтому автоматический мерджинг в гите только в стадиях проработки. Пока обходимся средствами сторонних инструментов к конфигуратору (kdiff в основном и инструменты из состава SourceTree). Плюс у нас сейчас преобладают проекты, в которых процесс выстроен с учетом работы вообще в одной ветке (максимум две), т.е. само дробление на ТП происходит с учетом этого изначально. Лично я считаю это ограничением, которое мы стараемся преодолеть.
Да, это все понимают. Только не думаю, что в нем принято напоминать об этом, т.к. процесс этот так устроен что сам должен способствовать отдаче сообщества, на практике же вопрос немного сложнее как со стороны 1С разработчика, так и со стороны ваших условий приемки (знаю что для некоторых разработчиков это является стоппером). И не стоит воспринимать мой ответ как обратную позицию — мы хотим это делать, но пока мало получается, играет роль приоритет проектных задач, необходимость изучать то, что не всегда нужно для PR, разработки не нужные в вами установленных процессах, т.к. они специфичны и т.п.
Часть инструментов, представленных в статье, например, gitsync со скриншота — это наши (сообщества) разработки.
btw, ADunaev — у вас gitsync штатный или допиливать пришлось?
Влиты. Но, к сожалению пока с малой долей отдачи, работаем над этим тоже. Ваш вклад в сообщество неоценим, он дал как раз возможность строить по кирпичикам в виде сервисов подобные стенды с качественными процессами разработки из коробки. Ну а по поводу в рамках 1С, то мы живем не в рамках 1С и нам надо думать ещё и туда.
Да, кроме вашего плагина к сонару большая часть инструментов стенда опенсурсная, все мы видим на картинках известные продукты (гитлаб сонар гит докер гитсинк и тп). Плагин ваш, кстати, к ним не относится :) В частности, из-за сложности его развития и поддержки у нас и появилась (в уточнение к предыдущим вопросам — чей юзаем) и стала активно развиваться и использоваться на некоторых проектах своя альтернативная версия (ждём следующей статьи...).
Гитсинк у нас допиленный под некоторые небольшие усовершенствования и подстраивания под процессы, докер, СППР, сонар, оптимизацию и производительность
Конечно, системы контроля версий — это фундамент процессов коллективной разработки — без них сейчас никуда, и EDT от 1С активно тестируется сообществом. Стоит думать о гите (уже как пару лет) как о стандарте и одном из основных навыков в резюме, собственно, и в 1С разработке.
Любой хороший инструмент способен встроиться в ваш процесс, если его немного подпилить. Но именно для своих целей jira подходит как нельзя лучше (масса плагинов, тесная интеграция с репозиториями, смарт-коммиты, доски, диаграммы сгорания и тп), ну и эта система является основной принятой у нас во всей компании. Документооборот в дебрях СППР всё-таки используется :), но значительно допиленный — с генераторами полноценных документов на Python сервисах и т.п.
Рассматривали, про несколько лет говорить не приходится, — как и наши сервисы они развиваются и имеют разные подходы ко всему, даже к вопросу переучивания разработчиков 1С сразу на массу незнакомых им технологий.
Если позволите, пара вопросов. Насколько комфортно разработчикам в этой системе? Как устроено взаимодействие консультантов и разработчиков?
Кому-то комфортно кому то нет, кто привыкает на практике убеждается в эффективности инструментов, как говорится открываются глаза. Процент уходящих всегда есть в таких процессах, надо это понимать и быть готовым к этому.
Как устроено взаимодействие консультантов и разработчиков? Или у Вас настолько грамотные консультанты, что способны спроектировать решение без участия программистов?
Они грамотные, большую часть способны спроектировать, тем более на уровне метаданных они уже работают с проектированием СППР, и эта же система избавляет их от множества ошибок в описании ТП, а также сами ФДР/ТЗ генерирует СППР, а не пишет консультант в Word.
Как собираются баги?
Как задачи в jira и СППР
Используете ли план/факт на задачи разработки, и если да то используете для расчета з/п участников процесса? И кто оценивает трудоемкость задачи?
Да, план-факт проектирования-разработки используется в СППР. К ЗП участников это не имеет отношение ( а надо бы :)) ). Трудоемкость оценивается на этапе утверждений требований к доработкам архитекторами разработчиками и ответственными консультантами совместно — но это мало имеет отношение к стенду, разве что для отметки и контроля в jira и сппр — стенд позволяет раньше выявлять проблемы в отставании это да.
BSL плагин для SonarQube используем silverbulleters, но в планах разработать собственный.
А Jenkins CI выбрали так как функционал из коробки удовлетворял потребности по организации сборочной линии, были готовые плагины для SonarQube.
Плюс на стенде всегда крутится около 5 таких проектов параллельно.
Влиты. Но, к сожалению пока с малой долей отдачи, работаем над этим тоже. Ваш вклад в сообщество неоценим, он дал как раз возможность строить по кирпичикам в виде сервисов подобные стенды с качественными процессами разработки из коробки. Ну а по поводу в рамках 1С, то мы живем не в рамках 1С и нам надо думать ещё и туда.
Да, кроме вашего плагина к сонару большая часть инструментов стенда опенсурсная, все мы видим на картинках известные продукты (гитлаб сонар гит докер гитсинк и тп). Плагин ваш, кстати, к ним не относится :) В частности, из-за сложности его развития и поддержки у нас и появилась (в уточнение к предыдущим вопросам — чей юзаем) и стала активно развиваться и использоваться на некоторых проектах своя альтернативная версия (ждём следующей статьи...).
Гитсинк у нас допиленный под некоторые небольшие усовершенствования и подстраивания под процессы, докер, СППР, сонар, оптимизацию и производительность
Кому-то комфортно кому то нет, кто привыкает на практике убеждается в эффективности инструментов, как говорится открываются глаза. Процент уходящих всегда есть в таких процессах, надо это понимать и быть готовым к этому.
Они грамотные, большую часть способны спроектировать, тем более на уровне метаданных они уже работают с проектированием СППР, и эта же система избавляет их от множества ошибок в описании ТП, а также сами ФДР/ТЗ генерирует СППР, а не пишет консультант в Word.
Как задачи в jira и СППР
Да, план-факт проектирования-разработки используется в СППР. К ЗП участников это не имеет отношение ( а надо бы :)) ). Трудоемкость оценивается на этапе утверждений требований к доработкам архитекторами разработчиками и ответственными консультантами совместно — но это мало имеет отношение к стенду, разве что для отметки и контроля в jira и сппр — стенд позволяет раньше выявлять проблемы в отставании это да.
А Jenkins CI выбрали так как функционал из коробки удовлетворял потребности по организации сборочной линии, были готовые плагины для SonarQube.