Интегрированный стенд разработки КРОК для 1С и не только

    Опыт разработки, накапливаемый на крупных и сложных проектах, воплощается в полезные инструменты и инженерные практики, которыми необходимо обогащать процессы разработки, переосмысливая его целиком раз за разом. Именно осознание ценности приобретенного опыта как артефакта, желание развиваться, привело нас к пониманию необходимости внедрения инструментов и практик в текущие процессы. И мы запустили кардинальный пересмотр подходов к проектированию решений и к процессу разработки в целом. Нет смысла описывать типичные ограничения и недостатки «классического» подхода к командной разработке в мире 1С. На эту тему уже много сказано. Опишу лишь паттерны, которые позволили нам сделать эти недостатки маленькими и почти не страшными.

    Итак знакомьтесь, интегрированный стенд разработки!



    Общие принципы архитектуры



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


    Процесс



    Жизненный цикл любого решения практически не меняется в зависимости от масштаба и сложности проекта. Он включает в себя: анализ, проектирование, разработку, тестирование, внедрение, сопровождение, вывод из эксплуатации. Чтобы получить максимальную эффективность, каждый из этих процессов должен быть выверен и согласован с предшествующими и последующими процессами, объединен в подобие автоматизированного конвейера, который может тиражироваться под неограниченное количество проектов. Решить поставленную задачу, позволила реализация системы в виде связанных через экспортируемые API микросервисов в изолированных контейнерах, которую возможно развернуть как в облачном сервисе, так и в локальной сети предприятия.

    Вот так выглядит наш стек, реализующий процесс:


    Мы постарались свести к минимуму использование платных сервисов с закрытым исходным кодом, что положительно отразилось на стоимости владения. Практически все сервисы с открытым исходным кодом и работают на ОС Linux.

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


    Проектирование (Сервис Проектирования Прикладных Решений)



    Один из наиболее значимых этапов при старте проекта — проектирование будущего решения на основе анализа требований. Основная задача — максимально понятно, однозначно и быстро описать архитектуру будущего решения, в терминах понятных как разработчику/инженеру, так и консультанту. Описать метаданные, алгоритмы реализуемых бизнес-процессов. При этом, хотелось максимально задействовать готовые, быстро настраиваемые под конкретные условия шаблоны, которые можно адаптировать к данным на входе и получить проектную документацию на выходе.

    Мы внедрили конфигурацию «1С: СППР» в качестве единого интерфейса для проектирования прикладных решений, значительно переработали концепцию описания бизнес-процессов и функций, а также проектирования ТП (ФДР). Еще автоматизировали процессы генерации документации через интеграцию с функционалом «1С: ДО» и микросервисами по генерации документов формата docx.

    «1С: СППР». Редактирование информации о проекте:


    «1С: СППР». Отчёт по процессам:


    «1С: СППР». Редактирование метаданных объектов:


    «1С: СППР». Редактирование схемы бизнес-процесса:


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

    Конечно, нельзя сказать, что процесс проектирования изменился кардинально, однако унификация организационных подходов и автоматизация многих функций уже вносит вклад в качество проектов.


    Разработка (Сервисы непрерывной интеграции, инспекции и тестирования)



    Мы постарались сфокусироваться на возможности всестороннего, непрерывного, автоматизированного контроля качества разрабатываемого кода, чтобы гарантировать соответствие установленному в КРОК стандарту. Причем, даже если привлекаем сторонние команды разработчиков, методики, инструменты и стандарты разработки которых могут существенно отличаться от принятых у нас.

    На стенде каждый коммит разработчика автоматически запускает процедуру разбора конфигурации в структуру каталогов и файлов через сервис Gitsync. Полученные изменения индексируются и помещаются в репозиторий Git. В нашем случае это сервис Gitlab. Сообщение коммита автоматически формируется из текста комментария, введенного при помещении изменений в хранилище конфигурации, а автор коммита в системе контроля версий сопоставляется с пользователем хранилища конфигурации. Во время разбора из текста комментария мы можем получить информацию о задаче разработки и трудозатратах, передать ее системе отслеживания задач, например, Jira. Это дает исчерпывающую картину истории разработки. Например, мы можем найти автора по строке кода, а smart-комментарии к коммитам позволяют управлять автоматически статусами задач и оценивать код в привязке к задачам непосредственно в самих задачах.

    Gitlab. Теперь возможно прокомментировать любую строку помещаемого коммитом кода:


    Gitlab. Провести «Code Review» c подсветкой синтаксиса:


    Gitlab. Получить наглядную картину изменений кода в новом коммите:


    После каждого коммита в репозитории автоматически запускается процедура статической инспекции кода сервисом SonarQube. BSL код коммита проверяется на соответствие набору правил (профиль качества), описывающих стандарт разработки кода. Процедура выполняется как для кода разрабатываемой конфигурации, так и для внешних механизмов: расширений, внешних отчетов и обработок и, в принципе, любого другого кода проекта, даже на других языках.

    SonarQube:


    Каждая проверка обновляет информацию отслеживаемых метрик качества кодовой базы, таких как:

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


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

    Профиль качества может расширяться собственными наборами правил через XPath, а также за счет выпуска новых правил в составе собственной реализации плагина для языка 1С. Это позволяет гибко управлять требованиями качества, исходя из реалий конкретного решения.

    Автоматизированный запуск процессов разбора конфигурации, инспекции кода, автоматизированного тестирования и т.д. запускает сервис непрерывной интеграции (сервис Jenkins). Количество и характер таких сборочных линий может быть изменено в соответствии со спецификой того или иного проекта.

    Несмотря на относительную сложность описанного процесса, все механизмы конвейера, которые выполняют рутину, скрыты в облачном сервисе. А разработчик имеет дело с привычным для него интерфейсом конфигуратора, а также может развивать свои навыки, используя более продвинутые инструменты. Например, git, репозиторий для внешних механизмов в связке со сторонними редакторами кода и SonarLint, SourceTree, и т.п.


    В общем случае разработчик подключает информационную базу к сервису хранилища конфигурации 1С, пишет код и помещает его в этот сервис, тем самым запуская скрытый от него процесс на стенде. Если в результате проверки коммита в коде выявлены недостатки, разработчик получает почтовое уведомление (или сообщение чат-бота) со ссылкой на описание ошибки и с рекомендациями по исправлению и временной оценкой трудозатрат в интерфейсе сервиса SonarQube. После исправления ошибки, происходит новый коммит и процесс повторяется, отредактированные задачи автоматически закрываются… технический долг уменьшается. По той же логике построен процесс автоматизированного тестирования, где каждый коммит инициирует запуск развёртывания тестового окружения, подключает необходимые тесты из библиотеки тестов. А после прогона агрегируется информация об ошибках при тестировании, а также о покрытии кода тестами.

    Трудно переоценить эффект от непрерывной, всесторонней проверки кода, за которой следует автоматизированное тестирование разрабатываемого функционала. Это позволяет избавиться от далеко идущих последствий, сделать этапы разработки прозрачными, а вкупе с правильно выстроенными процессами, объективно оценить квалификацию разработчиков, что исключает риски зависимости от подрядчиков. Оценивая параметры текущей кодовой базы, мы можем оперативно выявлять и нивелировать возникающие риски, исправлять недочеты проектирования, своевременно реагировать на меняющиеся требования.

    Модульная организация архитектуры стенда позволяет встраивать в процесс новые модули, тиражировать решение для необходимого количества проектов. Схематически она выглядит так:



    Тестирование (сервис непрерывного тестирования)



    Выше я уже говорил про сервис непрерывного тестирования, который интегрирован в конвейер процесса разработки. На данный момент на стенде реализован прогон дымовых тестов и unit-тестов. Функционал автотестов реализуется с использованием фреймворка xUnitFor1C.

    Запуск процессов тестирования, так же как инспекция кода, привязан к событию коммита в репозиторий проекта. Для unit-тестов подразумевается разработка теста параллельно с разработкой функционала. Непосредственно перед их выполнением производится автоматизированное развертывание последней версии конфигурации в подготовленную тестовую информационную базу. Затем запускается клиент, который выполняет сценарии тестирования для уже реализованного функционала. Тесная интеграция сервисов автоматизированного тестирования с BSL плагином SonarQube позволяет вычислить такой параметр как покрытие кода тестами. Результат прогона тестов — отчет, который загружается в систему анализа и визуализации результатов тестирования ReportPortal. Этот сервис представляет собой портал отчетов, в котором агрегируются данные о прогонах тестов (статистика и результаты), производится базовое обучение системы по категоризации падений и дальнейшее автоматическое определение причин. Все параметры прогонов тестов доступны в удобном веб-интерфейсе с различными досками для графиков, диаграмм (виджетов). Для расширения функций портала возможно использовать собственные расширения.

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

    ReportPortal. Дашборд:




    ReportPortal. Неудачные запуски тестов:


    ReportPortal. Типы дефектов:


    ReportPortal. Редактирование типов дефектов:



    Развитие



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

    Из планов на ближайшую перспективу развития стенда — создание портала управления сервисами стенда. Веб-интерфейс портала позволит работать с заявками на подключение проектов к стенду, с калькулятором стоимости сервисов, с их автоматизированным развертыванием по запросу под проект. В результате менеджер сразу же может получить калькуляцию стоимости выбранных услуг и оценить затраты, определить разработчиков на проект.

    Мы планируем провести интеграцию портала с облачным решением эксплуатации систем 1С. Это поможет быстро разворачивать тиражируемые типовые решения в связке с сервисами разработки, реализованными на стенде для более эффективной миграции систем заказчика в облако КРОК.

    Портал управления планируем также интегрировать с сервисом автоматизированного управления конфигурацией (развертывание, настройка, удаление). Это позволит сократить время развертывания, упростить настройку и обслуживание системы. А для повышения уровня безопасности внедрим сервис сквозной аутентификации по всем сервисам стенда, чтобы использовать одну и ту же учетную запись во всех из них.

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

    UPD. По просьбам в комментариях добавляем список опенсурсных продуктов, которые используем, с ссылками.

    Продукт Вендор/Автор Ссылки №1 Ссылки №2
    http://v8.1c.ru
    1С: СППР http://v8.1c.ru/model/
    1С: ДО http://v8.1c.ru/doc8/
    Git SFC https://ru.wikipedia.org/wiki/Git
    Gitlab Gitlab https://ru.wikipedia.org/wiki/GitLab https://about.gitlab.com/
    Jira Atlassian https://ru.wikipedia.org/wiki/Jira https://ru.atlassian.com/software/jira
    ReportPortal EPAM Systems, Inc. https://github.com/reportportal https://rp.epam.com/ui/
    SonarQube SonarSource https://ru.wikipedia.org/wiki/SonarQube https://github.com/SonarSource/sonarqube
    Jenkins Косукэ Кавагути https://ru.wikipedia.org/wiki/Jenkins https://github.com/jenkinsci
    SourceTree Atlassian https://www.sourcetreeapp.com/
    xUnitFor1C artbear https://github.com/xDrivenDevelopment/xUnitFor1C https://github.com/artbear
    Gitsync EvilBeaver https://github.com/oscript-library/gitsync https://github.com/EvilBeaver
    SonarQube 1C (BSL) Plugin Silver Bulleters https://silverbulleters.org/sonarqube https://github.com/silverbulleters/sonar-1c-bsl-public
    КРОК
    115,00
    №1 по ИТ-услугам в России
    Поделиться публикацией

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

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


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

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

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

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

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

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

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

            Советую рассмотреть: silverbulleters.org/vanessaservices
              0
              Рассматривали, про несколько лет говорить не приходится, — как и наши сервисы они развиваются и имеют разные подходы ко всему, даже к вопросу переучивания разработчиков 1С сразу на массу незнакомых им технологий.
                0
                Я, к сожалению, ошибся веткой. Мой камент был адресован Taliesien

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

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

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

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


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

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

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

                            После можно было бы создать в отдельной ветке PR с пометкой Do Not Merge и в ветке коллективно доработать до состояния общественно полезного кода.
                              0
                              Обязательно пообщаемся, я в курсе соц.ресурсов сообщества. Соберу в кучу мысли и поделки нашей команды, и что из этого можно обсудить и попробуем. Думаю, они и без этого участвуют.
                                +3
                                Я все-таки вынужден отрефлексировать на указанные тезисы.

                                Получается — претензии к приему изменений в открытые продукты, но вы не приводите конкретных пул-реквестов. Всем известно что костыли не пропускаются — это да. Артур не пропускает — это тоже да. Но есть люди которые почему-то успешно пул-реквестят. Что конкретно вас не устраивает.

                                Получается — у вас претензии к развитию плагина платного, я даже знаю про что вы, но там вопрос менеджерский а не технический и бюджетный в том числе. Но я вам напомню про альтернативную версию — вы наверное в курсе что наш плагин в Роспатенте зарегистрирован. Как вы собираетесь писать и тем более распространять свою альтернативную версию — это большой опять же менеджерский вопрос.

                                Артур — я так и не понял что вы такое сделали. И самое главное зачем опубликовали в таком стиле. Бизнес конечно понятен — типа ничего личного. Но чувствую в ваших формулировках именно личное сквозит.

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

                  Получается 1-2 разработчика работающих параллельно?
                    0
                    5 – 25, проекты разные, больше вроде еще не встречал.
                    Плюс на стенде всегда крутится около 5 таких проектов параллельно.
                      0
                      Если разработчиков 5 то и веток должно быть 5, или ветки создаются просто из хранилища?
                        0
                        Если разработчиков 5, то должно быть столько веток, сколько принято в вашем flow, и, как я написал выше, у нас на текущий момент процесс построен так, чтобы достаточно было 1-2 веток. И да, ветки создаются из хранилищ (исключением могут быть патчи и все что создается вне конфигурации – внешние обработки, скрипты, внешние алгоритмы, запросы, геркины и тп – это только в гите и тут близкий git-flow процесс используется).
                    +2
                    Я не буду сильно много комментировать, хотя публикация выглядит очень сильно странной.

                    Как сотрудник компании silverbulleters.org видеть такую публикацию от компании КРОК мне как минимум странно, мы вам там на корпадрес письмо написали.

                    А вот как представитель сообщества скажу несколько слов:

                    Во первых указание OpenSource инструментов без ссылок противоречит духу OpenSource и некоторым лицензионным соглашениям (в частности Mozzila и Apache).

                    Во вторых на схеме опечатка — xUnitFor1C а не xUnite

                    Во третьих у нас в лицензии написано — не использовать Trademark
                    github.com/xDrivenDevelopment/xUnitFor1C/blob/develop/LICENSE

                    в четвертых в лицензии GitSync написано не использовать Trademark
                    github.com/oscript-library/gitsync/blob/master/LICENSE

                    в пятых xUnitFor1C сейчас объединен в общий продукт Vanessa Automation Driven Development github.com/silverbulleters/add
                    искренне советую обновиться github.com/silverbulleters/add/releases

                    ADunaev у меня вопрос — у вас точно все там в порядке? вы получается сами не контрибьютите, ссылок не указываете, торговые марки указываете на схемах и я так понимаю еще этим и торгуете. Я конечно понимаю что ничего личного, только бизнес, но вроде как это выглядит странно…

                    P.S. Что то я не помню pull-request'ов от компании КРОК нив GitLab, Jenkins, Oscript Libs и xUnit (vanessa ADD) — возьмите хотя бы пример с Петра Грибанова: он в своих статьях явно указывает ссылки на открытые продукты используемые в 1С платформе.

                    P.S.S. Я очень удивлен именно отсутствию ссылок на открытые продукты и самое главное ни слова благодарности например artbear который уже 10 лет как пилит xUnit и дальше продолжает пилить ADD совместно с сообществом разработчиков.
                      0
                      Скажу чисто как один хоть и не значительных, но все же конрибъютеров сообщества — отсутствие ссылок на OpenSource разработки — это прямое неуважение к сообществу разработчиков. Это не Ваш продукт, а статье Вы об этом не говорите. И ваша попытка обновить статью после критики общественности — ни коем образом не очищает поступок.
                        0
                        Удивительно, что господин Линус Торвальдс не обиделся на то, что в статье есть упоминание ОС Linux но нет упоминаний о том, что это его OpenSource разработка, при этом нет никаких слов благодарности в его адрес… Возможно он просто еще не прочитал статью и нам посчастливится прочитать здесь его гневный комментарий, или тут просто не на что обижаться?
                          +1
                          Для того что бы не задавать глупые вопросы по господину Линусу Торвальдсу Вам следует почитать что именно он сделал для Linux, чем он сейчас занимается, а так же тексты лицензий GNU GPL. И если Вы начнете нарушать их условия лицензирования, то накажут они сильно и больно.
                            0
                            Если уж намекаете на некомпетентность, то хотя бы ссылки добавляйте, я с удовольствием почитаю :).

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое