Comments 34
ADunaev подскажите пожалуйста, плагин на поддержку языка BSL для Sonar писали сами, нашли, или купили у silverbulleters?
И почему в качестве CI сервиса выбрали jenkins а не имеющийся в GitLab`е функционал? GitLab же тоже позволяет формировать и запускать pipeline?
И почему в качестве CI сервиса выбрали jenkins а не имеющийся в GitLab`е функционал? GitLab же тоже позволяет формировать и запускать pipeline?
Скажите, а плагин для сонара это ваша собственная разработка?
Это потрясающе!
Если позволите, пара вопросов. Насколько комфортно разработчикам в этой системе? Как устроено взаимодействие консультантов и разработчиков? Или у Вас настолько грамотные консультанты, что способны спроектировать решение без участия программистов?
Как собираются баги?
Используете ли план/факт на задачи разработки, и если да то используете для расчета з/п участников процесса? И кто оценивает трудоемкость задачи?
Если позволите, пара вопросов. Насколько комфортно разработчикам в этой системе? Как устроено взаимодействие консультантов и разработчиков? Или у Вас настолько грамотные консультанты, что способны спроектировать решение без участия программистов?
Как собираются баги?
Используете ли план/факт на задачи разработки, и если да то используете для расчета з/п участников процесса? И кто оценивает трудоемкость задачи?
Если позволите, пара вопросов. Насколько комфортно разработчикам в этой системе? Как устроено взаимодействие консультантов и разработчиков?
Кому-то комфортно кому то нет, кто привыкает на практике убеждается в эффективности инструментов, как говорится открываются глаза. Процент уходящих всегда есть в таких процессах, надо это понимать и быть готовым к этому.
Как устроено взаимодействие консультантов и разработчиков? Или у Вас настолько грамотные консультанты, что способны спроектировать решение без участия программистов?
Они грамотные, большую часть способны спроектировать, тем более на уровне метаданных они уже работают с проектированием СППР, и эта же система избавляет их от множества ошибок в описании ТП, а также сами ФДР/ТЗ генерирует СППР, а не пишет консультант в Word.
Как собираются баги?
Как задачи в jira и СППР
Используете ли план/факт на задачи разработки, и если да то используете для расчета з/п участников процесса? И кто оценивает трудоемкость задачи?
Да, план-факт проектирования-разработки используется в СППР. К ЗП участников это не имеет отношение ( а надо бы :)) ). Трудоемкость оценивается на этапе утверждений требований к доработкам архитекторами разработчиками и ответственными консультантами совместно — но это мало имеет отношение к стенду, разве что для отметки и контроля в jira и сппр — стенд позволяет раньше выявлять проблемы в отставании это да.
А 1С: ДО не способен заменить jira?
Любой хороший инструмент способен встроиться в ваш процесс, если его немного подпилить. Но именно для своих целей jira подходит как нельзя лучше (масса плагинов, тесная интеграция с репозиториями, смарт-коммиты, доски, диаграммы сгорания и тп), ну и эта система является основной принятой у нас во всей компании. Документооборот в дебрях СППР всё-таки используется :), но значительно допиленный — с генераторами полноценных документов на Python сервисах и т.п.
Получается, это еще одна реализация VanessaServices, которые уже несколько лет существуют.
Советую рассмотреть: silverbulleters.org/vanessaservices
Советую рассмотреть: silverbulleters.org/vanessaservices
Рассматривали, про несколько лет говорить не приходится, — как и наши сервисы они развиваются и имеют разные подходы ко всему, даже к вопросу переучивания разработчиков 1С сразу на массу незнакомых им технологий.
Спасибо за наводку. Не так много комментариев, и уже изучаю мат часть по этому вопросу. Действительно очень интересно.
К сожалению, 1С не балует нас инструментами для разработки, а, признаться честно, git всегда немного пугал. Но от него никак не уйти, если говорить о более менее высоком уровне разработки. Даже на 1С.
К сожалению, 1С не балует нас инструментами для разработки, а, признаться честно, git всегда немного пугал. Но от него никак не уйти, если говорить о более менее высоком уровне разработки. Даже на 1С.
Вокруг 1С существует довольно большое движение в OpenSource (в масштабах мира 1С, разумеется). Вливайтесь туда.
Часть инструментов, представленных в статье, например, gitsync со скриншота — это наши (сообщества) разработки.
btw, ADunaev — у вас gitsync штатный или допиливать пришлось?
Часть инструментов, представленных в статье, например, gitsync со скриншота — это наши (сообщества) разработки.
btw, ADunaev — у вас gitsync штатный или допиливать пришлось?
Часть инструментов, представленных в статье, например, gitsync со скриншота — это наши (сообщества) разработки.
Влиты. Но, к сожалению пока с малой долей отдачи, работаем над этим тоже. Ваш вклад в сообщество неоценим, он дал как раз возможность строить по кирпичикам в виде сервисов подобные стенды с качественными процессами разработки из коробки. Ну а по поводу в рамках 1С, то мы живем не в рамках 1С и нам надо думать ещё и туда.
Да, кроме вашего плагина к сонару большая часть инструментов стенда опенсурсная, все мы видим на картинках известные продукты (гитлаб сонар гит докер гитсинк и тп). Плагин ваш, кстати, к ним не относится :) В частности, из-за сложности его развития и поддержки у нас и появилась (в уточнение к предыдущим вопросам — чей юзаем) и стала активно развиваться и использоваться на некоторых проектах своя альтернативная версия (ждём следующей статьи...).
Гитсинк у нас допиленный под некоторые небольшие усовершенствования и подстраивания под процессы, докер, СППР, сонар, оптимизацию и производительность
btw, ADunaev — у вас gitsync штатный или допиливать пришлось?
Влиты. Но, к сожалению пока с малой долей отдачи, работаем над этим тоже. Ваш вклад в сообщество неоценим, он дал как раз возможность строить по кирпичикам в виде сервисов подобные стенды с качественными процессами разработки из коробки. Ну а по поводу в рамках 1С, то мы живем не в рамках 1С и нам надо думать ещё и туда.
Да, кроме вашего плагина к сонару большая часть инструментов стенда опенсурсная, все мы видим на картинках известные продукты (гитлаб сонар гит докер гитсинк и тп). Плагин ваш, кстати, к ним не относится :) В частности, из-за сложности его развития и поддержки у нас и появилась (в уточнение к предыдущим вопросам — чей юзаем) и стала активно развиваться и использоваться на некоторых проектах своя альтернативная версия (ждём следующей статьи...).
Гитсинк у нас допиленный под некоторые небольшие усовершенствования и подстраивания под процессы, докер, СППР, сонар, оптимизацию и производительность
Я просто хочу напомнить, что в опенсорс принято возвращать полученную пользу в виде ответных коммитов. Тем более, если речь про оптимизацию. Ждем ваши доработки в виде PR в github.com/oscript-library/gitsync
Да, это все понимают. Только не думаю, что в нем принято напоминать об этом, т.к. процесс этот так устроен что сам должен способствовать отдаче сообщества, на практике же вопрос немного сложнее как со стороны 1С разработчика, так и со стороны ваших условий приемки (знаю что для некоторых разработчиков это является стоппером). И не стоит воспринимать мой ответ как обратную позицию — мы хотим это делать, но пока мало получается, играет роль приоритет проектных задач, необходимость изучать то, что не всегда нужно для PR, разработки не нужные в вами установленных процессах, т.к. они специфичны и т.п.
Ну мои персональные условия приемки довольно либеральные. В приципе можно просто пообщаться в форумах или чатах сообщества и обсудить, что из доработок полезно было бы вернуть в опенсорс, а что нет.
После можно было бы создать в отдельной ветке PR с пометкой Do Not Merge и в ветке коллективно доработать до состояния общественно полезного кода.
После можно было бы создать в отдельной ветке PR с пометкой Do Not Merge и в ветке коллективно доработать до состояния общественно полезного кода.
Конечно, системы контроля версий — это фундамент процессов коллективной разработки — без них сейчас никуда, и EDT от 1С активно тестируется сообществом. Стоит думать о гите (уже как пару лет) как о стандарте и одном из основных навыков в резюме, собственно, и в 1С разработке.
А в вашем стенде разработки используется EDT (1C:Enterprise Development Tools)? Да/нет, почему? Вроде как он должен закрыть многие вопросы ( в т.ч. по гиту) которые у вас реализованы сторонними утилитами.
В том, что описан в статье еще нет. В следующих релизах стоит в планах внедрить этот инструмент, мы считаем его перспективной заменой (начать хотим с использования в разработке самих инструментов стенда – в первой очереди разработку СППР на нее перевести). В остальном пока только нацелены на перевод на EDT разработки внешних к конфе механизмов (расширения, внешние обработки-отчеты), — по нашим текущим попыткам, использовать его для конфигураций больших пока вообще нереально, для средних очень туго и мощные машинки приходится использовать (производительность некоторых операций страдает пока, достаточно ошибок, с нетерпением ждем и щупаем выходящие релизы).
Мержинг веток 1С в гите, если он возникает, каким инструментом пользуетесь?
У нас пока активно используются хранилища, поэтому автоматический мерджинг в гите только в стадиях проработки. Пока обходимся средствами сторонних инструментов к конфигуратору (kdiff в основном и инструменты из состава SourceTree). Плюс у нас сейчас преобладают проекты, в которых процесс выстроен с учетом работы вообще в одной ветке (максимум две), т.е. само дробление на ТП происходит с учетом этого изначально. Лично я считаю это ограничением, которое мы стараемся преодолеть.
Плюс у нас сейчас преобладают проекты, в которых процесс выстроен с учетом работы вообще в одной ветке (максимум две), т.е. само дробление на ТП происходит с учетом этого изначально
Получается 1-2 разработчика работающих параллельно?
5 – 25, проекты разные, больше вроде еще не встречал.
Плюс на стенде всегда крутится около 5 таких проектов параллельно.
Плюс на стенде всегда крутится около 5 таких проектов параллельно.
Если разработчиков 5 то и веток должно быть 5, или ветки создаются просто из хранилища?
Если разработчиков 5, то должно быть столько веток, сколько принято в вашем flow, и, как я написал выше, у нас на текущий момент процесс построен так, чтобы достаточно было 1-2 веток. И да, ветки создаются из хранилищ (исключением могут быть патчи и все что создается вне конфигурации – внешние обработки, скрипты, внешние алгоритмы, запросы, геркины и тп – это только в гите и тут близкий git-flow процесс используется).
UFO just landed and posted this here
Скажу чисто как один хоть и не значительных, но все же конрибъютеров сообщества — отсутствие ссылок на OpenSource разработки — это прямое неуважение к сообществу разработчиков. Это не Ваш продукт, а статье Вы об этом не говорите. И ваша попытка обновить статью после критики общественности — ни коем образом не очищает поступок.
Удивительно, что господин Линус Торвальдс не обиделся на то, что в статье есть упоминание ОС Linux но нет упоминаний о том, что это его OpenSource разработка, при этом нет никаких слов благодарности в его адрес… Возможно он просто еще не прочитал статью и нам посчастливится прочитать здесь его гневный комментарий, или тут просто не на что обижаться?
Sign up to leave a comment.
Интегрированный стенд разработки КРОК для 1С и не только