Как стать автором
Обновить

Комментарии 34

ADunaev подскажите пожалуйста, плагин на поддержку языка BSL для Sonar писали сами, нашли, или купили у silverbulleters?
И почему в качестве CI сервиса выбрали jenkins а не имеющийся в GitLab`е функционал? GitLab же тоже позволяет формировать и запускать pipeline?
BSL плагин для SonarQube используем silverbulleters, но в планах разработать собственный.
А Jenkins CI выбрали так как функционал из коробки удовлетворял потребности по организации сборочной линии, были готовые плагины для SonarQube.
Скажите, а плагин для сонара это ваша собственная разработка?
Используем silverbulleters, но в планах разработка своего.
Имхо, неплохо было бы и в статье это отразить. получается вы используете наши же технологии и про нас ни слова.
Это потрясающе!
Если позволите, пара вопросов. Насколько комфортно разработчикам в этой системе? Как устроено взаимодействие консультантов и разработчиков? Или у Вас настолько грамотные консультанты, что способны спроектировать решение без участия программистов?
Как собираются баги?
Используете ли план/факт на задачи разработки, и если да то используете для расчета з/п участников процесса? И кто оценивает трудоемкость задачи?
Если позволите, пара вопросов. Насколько комфортно разработчикам в этой системе? Как устроено взаимодействие консультантов и разработчиков?


Кому-то комфортно кому то нет, кто привыкает на практике убеждается в эффективности инструментов, как говорится открываются глаза. Процент уходящих всегда есть в таких процессах, надо это понимать и быть готовым к этому.

Как устроено взаимодействие консультантов и разработчиков? Или у Вас настолько грамотные консультанты, что способны спроектировать решение без участия программистов?

Они грамотные, большую часть способны спроектировать, тем более на уровне метаданных они уже работают с проектированием СППР, и эта же система избавляет их от множества ошибок в описании ТП, а также сами ФДР/ТЗ генерирует СППР, а не пишет консультант в Word.

Как собираются баги?

Как задачи в jira и СППР

Используете ли план/факт на задачи разработки, и если да то используете для расчета з/п участников процесса? И кто оценивает трудоемкость задачи?

Да, план-факт проектирования-разработки используется в СППР. К ЗП участников это не имеет отношение ( а надо бы :)) ). Трудоемкость оценивается на этапе утверждений требований к доработкам архитекторами разработчиками и ответственными консультантами совместно — но это мало имеет отношение к стенду, разве что для отметки и контроля в jira и сппр — стенд позволяет раньше выявлять проблемы в отставании это да.
А 1С: ДО не способен заменить jira?
Любой хороший инструмент способен встроиться в ваш процесс, если его немного подпилить. Но именно для своих целей jira подходит как нельзя лучше (масса плагинов, тесная интеграция с репозиториями, смарт-коммиты, доски, диаграммы сгорания и тп), ну и эта система является основной принятой у нас во всей компании. Документооборот в дебрях СППР всё-таки используется :), но значительно допиленный — с генераторами полноценных документов на Python сервисах и т.п.
Получается, это еще одна реализация VanessaServices, которые уже несколько лет существуют.

Советую рассмотреть: silverbulleters.org/vanessaservices
Рассматривали, про несколько лет говорить не приходится, — как и наши сервисы они развиваются и имеют разные подходы ко всему, даже к вопросу переучивания разработчиков 1С сразу на массу незнакомых им технологий.
Спасибо за наводку. Не так много комментариев, и уже изучаю мат часть по этому вопросу. Действительно очень интересно.
К сожалению, 1С не балует нас инструментами для разработки, а, признаться честно, git всегда немного пугал. Но от него никак не уйти, если говорить о более менее высоком уровне разработки. Даже на 1С.
Вокруг 1С существует довольно большое движение в OpenSource (в масштабах мира 1С, разумеется). Вливайтесь туда.

Часть инструментов, представленных в статье, например, gitsync со скриншота — это наши (сообщества) разработки.

btw, ADunaev — у вас gitsync штатный или допиливать пришлось?
Часть инструментов, представленных в статье, например, gitsync со скриншота — это наши (сообщества) разработки.

btw, ADunaev — у вас gitsync штатный или допиливать пришлось?


Влиты. Но, к сожалению пока с малой долей отдачи, работаем над этим тоже. Ваш вклад в сообщество неоценим, он дал как раз возможность строить по кирпичикам в виде сервисов подобные стенды с качественными процессами разработки из коробки. Ну а по поводу в рамках 1С, то мы живем не в рамках 1С и нам надо думать ещё и туда.

Да, кроме вашего плагина к сонару большая часть инструментов стенда опенсурсная, все мы видим на картинках известные продукты (гитлаб сонар гит докер гитсинк и тп). Плагин ваш, кстати, к ним не относится :) В частности, из-за сложности его развития и поддержки у нас и появилась (в уточнение к предыдущим вопросам — чей юзаем) и стала активно развиваться и использоваться на некоторых проектах своя альтернативная версия (ждём следующей статьи...).

Гитсинк у нас допиленный под некоторые небольшие усовершенствования и подстраивания под процессы, докер, СППР, сонар, оптимизацию и производительность
Я просто хочу напомнить, что в опенсорс принято возвращать полученную пользу в виде ответных коммитов. Тем более, если речь про оптимизацию. Ждем ваши доработки в виде PR в github.com/oscript-library/gitsync
Да, это все понимают. Только не думаю, что в нем принято напоминать об этом, т.к. процесс этот так устроен что сам должен способствовать отдаче сообщества, на практике же вопрос немного сложнее как со стороны 1С разработчика, так и со стороны ваших условий приемки (знаю что для некоторых разработчиков это является стоппером). И не стоит воспринимать мой ответ как обратную позицию — мы хотим это делать, но пока мало получается, играет роль приоритет проектных задач, необходимость изучать то, что не всегда нужно для PR, разработки не нужные в вами установленных процессах, т.к. они специфичны и т.п.
Ну мои персональные условия приемки довольно либеральные. В приципе можно просто пообщаться в форумах или чатах сообщества и обсудить, что из доработок полезно было бы вернуть в опенсорс, а что нет.

После можно было бы создать в отдельной ветке PR с пометкой Do Not Merge и в ветке коллективно доработать до состояния общественно полезного кода.
Обязательно пообщаемся, я в курсе соц.ресурсов сообщества. Соберу в кучу мысли и поделки нашей команды, и что из этого можно обсудить и попробуем. Думаю, они и без этого участвуют.
НЛО прилетело и опубликовало эту надпись здесь
Конечно, системы контроля версий — это фундамент процессов коллективной разработки — без них сейчас никуда, и EDT от 1С активно тестируется сообществом. Стоит думать о гите (уже как пару лет) как о стандарте и одном из основных навыков в резюме, собственно, и в 1С разработке.
А в вашем стенде разработки используется EDT (1C:Enterprise Development Tools)? Да/нет, почему? Вроде как он должен закрыть многие вопросы ( в т.ч. по гиту) которые у вас реализованы сторонними утилитами.
В том, что описан в статье еще нет. В следующих релизах стоит в планах внедрить этот инструмент, мы считаем его перспективной заменой (начать хотим с использования в разработке самих инструментов стенда – в первой очереди разработку СППР на нее перевести). В остальном пока только нацелены на перевод на EDT разработки внешних к конфе механизмов (расширения, внешние обработки-отчеты), — по нашим текущим попыткам, использовать его для конфигураций больших пока вообще нереально, для средних очень туго и мощные машинки приходится использовать (производительность некоторых операций страдает пока, достаточно ошибок, с нетерпением ждем и щупаем выходящие релизы).
Мержинг веток 1С в гите, если он возникает, каким инструментом пользуетесь?
У нас пока активно используются хранилища, поэтому автоматический мерджинг в гите только в стадиях проработки. Пока обходимся средствами сторонних инструментов к конфигуратору (kdiff в основном и инструменты из состава SourceTree). Плюс у нас сейчас преобладают проекты, в которых процесс выстроен с учетом работы вообще в одной ветке (максимум две), т.е. само дробление на ТП происходит с учетом этого изначально. Лично я считаю это ограничением, которое мы стараемся преодолеть.
Плюс у нас сейчас преобладают проекты, в которых процесс выстроен с учетом работы вообще в одной ветке (максимум две), т.е. само дробление на ТП происходит с учетом этого изначально

Получается 1-2 разработчика работающих параллельно?
5 – 25, проекты разные, больше вроде еще не встречал.
Плюс на стенде всегда крутится около 5 таких проектов параллельно.
Если разработчиков 5 то и веток должно быть 5, или ветки создаются просто из хранилища?
Если разработчиков 5, то должно быть столько веток, сколько принято в вашем flow, и, как я написал выше, у нас на текущий момент процесс построен так, чтобы достаточно было 1-2 веток. И да, ветки создаются из хранилищ (исключением могут быть патчи и все что создается вне конфигурации – внешние обработки, скрипты, внешние алгоритмы, запросы, геркины и тп – это только в гите и тут близкий git-flow процесс используется).
НЛО прилетело и опубликовало эту надпись здесь
Скажу чисто как один хоть и не значительных, но все же конрибъютеров сообщества — отсутствие ссылок на OpenSource разработки — это прямое неуважение к сообществу разработчиков. Это не Ваш продукт, а статье Вы об этом не говорите. И ваша попытка обновить статью после критики общественности — ни коем образом не очищает поступок.
Удивительно, что господин Линус Торвальдс не обиделся на то, что в статье есть упоминание ОС Linux но нет упоминаний о том, что это его OpenSource разработка, при этом нет никаких слов благодарности в его адрес… Возможно он просто еще не прочитал статью и нам посчастливится прочитать здесь его гневный комментарий, или тут просто не на что обижаться?
Для того что бы не задавать глупые вопросы по господину Линусу Торвальдсу Вам следует почитать что именно он сделал для Linux, чем он сейчас занимается, а так же тексты лицензий GNU GPL. И если Вы начнете нарушать их условия лицензирования, то накажут они сильно и больно.
Если уж намекаете на некомпетентность, то хотя бы ссылки добавляйте, я с удовольствием почитаю :).
Зарегистрируйтесь на Хабре , чтобы оставить комментарий