Альтернативные системы контроля версий и их применение для хранения версий продуктов, разработанных на платформе 1С

Публикация № 343317

Разработка - Практика программирования

git контроль версий

Речь пойдет о том, каким образом мы с вами можем использовать для разработки в 1С альтернативное программное обеспечение контроля версий, которое существует сейчас в мире. Если выбирать емкое слово, которое должно отразить доклад, то это, наверное, слово «ветки» - ветвления. Статья написана по итогам доклада, прочитанного автором на Конференции IE 2013 Еvolution 23-24 мая 2013 года. Также она напечатана в Журнале Инфостарта №2.

С развитием 8.3 по части полной выгрузки конфигурации в файлы у нас с вами появилась возможность использовать мировой опыт программного обеспечения по контролю версий (ревизий). Соответственно, можно использовать эту возможность как альтернативу хранилищу.

Итак,статья посвящена системам версионного контроля и их практическому применению для работы с 1С.

История развития систем контроля версий

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

Историю развития систем контроля версий можно разбить на несколько этапов:

1.     Файловые (локальные) копии

 

 

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

2.     Локальные системы контроля версий

Соответственно, во всем мире еще где-то в 1985 году тоже подумали, что это неправильно, и сделали локальные базы для хранения версий файлов.

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

 

 

И, в принципе, эти локальные задачи контроля версий на тот момент решало такое программное обеспечение, как RCS (Revision Control System). Я его упоминаю ради исторической справедливости. Потому что использовать подобную систему контроля версий имеет смысл только тогда, когда для разработки используется локальная база. Когда у вас и во всем мире начинается командная разработка, эта система контроля версий уже не подходит.

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

В некоторой степени системы на основе 1С:Документооборот или БСП с подсистемой версионирования файлов также являются локальными системами контроля версий.

3.     Централизованные системы контроля версий

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

 

 

Открытыми системами этого типа являются CVS и SVN.

  • До вчерашнего дня я думал, что CVS (Concurrent Versions System) уже можно выкинуть на свалку истории, но, оказывается, есть в нем некоторые моменты, которые все-таки до сих пор применимы и в наших сегодняшних жизненных реалиях.
  • Subversion (или SVN, сокращение от названия клиента для командной строки, входящей в состав пакета) – это эволюционное развитие CVS. По сравнению со своим прототипом что-то нашло, а что-то потеряло.
  • Хранилище 1С тоже является централизованной системой хранения версий. В принципе, в хранилище у нас есть и сервер, и права доступа, и две чашки кофе вы можете успеть выпить, пока захватите рекурсивно весь корень конфигурации, да? А если по http-доступу еще или по tcp – ваше счастье… Придется долго ждать.

 

 

Работа централизованных систем версий проста. Для каждого программиста-новичка понятна:

  1. Получил из хранилища
  2. Захватил
  3. Отредактировал
  4. Поместил обратно.

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

Но у централизованных систем есть и некоторые недостатки:

  1. Первый недостаток – это конечно то, что сервер фактически является «единой точкой отказа». В связи с этим совет: делайте backup хранилища. На самом деле, хотя бы базы данных.Но хранилища тоже, пожалуйста, делайте. Потому что если с сервером что-то случится – восстановиться можно будет только из backup-а.
  2. Следующая особенность – пессимистическая блокировка. Некоторые считают, что, когда в централизованной системе разработчик захватывает объект, он, таким образом, всем объявляет свое намерение, что собирается в этом объекте что-то изменить. К тому же, многие руководители думают, что они, таким образом, контролируют этого разработчика. Раз разработчик захватил какой-то там документ – значит, мы знаем, что он над ним работает, и он его к какому-то периоду времени сделает. По факту, если это уже опытный специалист, и вы ему доверяете, то он, конечно, всегда обоснует, почему он месяц назад объект захватил и до сих пор не поместил его в хранилище. Но все равно – эта пессимистическая блокировка накладывает на нас ограничение, которого можно было бы избежать. В дальнейшем в распределенных системах обошли этот путь.
    Также, если у вас идет глобальный рефакторинг, или идет какое-то исправление модуля и срочно необходимо исправить ошибку – тоже может возникнуть проблема. В худшем случае – база стоит, ничего не работает. В лучшем – возникает дилемма, 50% кода уже исправлена, то ли помещать в хранилище неоттестированный код, то ли сохранять его куда-то в файл. И у нас опять появляется в файловой системе «Копия конфигурации такой-то» и мы забыли/не забыли ее вернуть обратно в конфигурацию.
  3. И есть еще в централизованных системах такое соглашение – это за или против, я даже сомневаюсь – что последняя версия у нас самая оттестированная и самая рабочая. По факту, наверное, так и есть. Но только если мы тестируем на пользователях – нам сказали, что есть ошибки, мы их исправили и только тогда положили объект в хранилище. Только в этом случае мы можем быть уверены, что в хранилище у нас более-менее рабочая копия.
    В любых других случаях – для простого программиста у нас тестов нет. Разработчики типовых конфигураций не покрывают код тестами. Нет такого, что – дописал свое, запустил полное тестирование, проверил, как работает. Будет ли? Время покажет.

 

 

 

4.     Распределенные системы контроля версий

Следующим этапом развития систем контроля версий стали, конечно же, распределенные системы. Основная идея этих распределенных систем контроля ревизийэто ветвление.

 

 

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

Условный такой пример ветвления, который все знают – это конфигурация на поставке. Файл обновлений является «патчем» для конфигурации поставщика. При обновлении конфигурации поставщика на ее основе воссоздается новая конфигурация поставщика, которую вы не видите, но она есть. И, запустив действие «Показать дважды измененные», вы можете увидеть упрощенный вариант «трехстороннего сравнения». Можно сказать так: в конфигураторе «трехстороннее сравнение» есть, но оно скрыто от разработчика. Те, у кого есть «Снегопат», могут что-то в этой ситуации подкорректировать и все-таки посмотреть трехстороннее сравнение. Но от остальной массы разработчиков трехстороннее сравнение в конфигураторе скрыто.

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

 

Ключевые особенности

 

 

Итак – что отличает распределенные системы контроля версий от всех остальных?

  • Во-первых, как только перед вами встанет задача с кем-то обменяться информацией – для вас станет необходимостью организовать какой-то сервер. Пускай он будет развернут даже на вашей локальной машине, но для обмена сервер необходим.
  • Во-вторых, по сравнению с централизованными системами, где обычно можно было бы на определенные объекты поставить ограничение доступа, в распределенных системах нет смысла говорить о какой-то блокировке на определенный файл. В централизованной системе, например, в хранилище, у нас есть возможность на определенные объекты поставить доступ на чтение/запись, а в распределенной системе, поскольку вся копия проекта копируется разработчику на машину, разработчик все равно может этот файл изменить, прочитать и т.д. Это, наверное, одна из проблем… Но при желании, если вам необходимо какому-то удаленному разработчику выгрузить определенную подсистему, чтобы он ваше основное дерево конфигурации не смотрел, вы можете выделить эту подсистему в отдельную конфигурацию. Способы решения есть. Например, можно какую-то часть дерева истории выгрузить, а потом обратно загрузить уже изменения, которые разработчик внес.
  • Еще один важный момент, о котором я говорил: в централизованных системах на сервере должен всегда быть оттестированный код. В децентрализованных системах, когда вечером вы уходите домой, вы можете спокойно поместить в свою локальную копию неработающий код. Поверьте, это очень удобно, когда поместили свои изменения и записали для них какой-то естественный комментарий. От комментария многое зависит. Если вы с пустым комментарием что-то помещаете в то же хранилище, то я бы это не приветствовал. Понятно, что вы тут что-то изменили… А что по факту? С учетом скорости хранилища это практически невозможно узнать.
  • Ветвление, естественно, является палкой о двух концах. Оно, как линия жизни вашего проекта, может уйти куда-то в сторону, а может держаться генеральной линии. Это надо прочувствовать на себе. И основной принцип – ветвиться часто, но в меру.

Отдельно хотелось упомянуть о важности комментариев к коммиту. Если вы не можете кратко сформулировать результат работы и написать комментарий к версии хранилища, то вы наверное делали черти-что. Понятно, что вы тут что-то изменили… А что по факту? С учетом скорости хранилища это практически невозможно узнать, т.е. комментарий является кратким якорем для памяти и понимания что может быть в этой версии изменено.

 

Режимы работы распределенных систем

 

 

Распределенные системы поддерживают различные режимы работы.

  • Если вы разворачиваете проект для одного себя, вы можете использовать базу хранения версий локально.
  • Можно по старинке – с центральным сервером. Причем, вы можете копировать не полностью весь репозиторий на него, а только нужные вам для хранения истории файлы. Допустим, выгрузка хранилища 8.3 занимает 1.5 Гб. Разработчику первый раз выгрузить содержимое репозитория по каналу интернета очень тяжело. В то же время, можно выкачать только последние изменения, с которыми он работает.Так, поддерживается тот же принцип централизованной системы, как и в хранилище.
  • Без центрального сервера тоже можно работать. Но, в любом случае, какой-то сервер, хотя бы на локальной машине, организовывать все равно нужно.
  • И наконец, самый предпочтительный и самый удобный способ – с центральным сервером, с локальными фиксациями и ветками. Однако настройка будет наиболее трудоемкой.

 

Какие есть системы?

 

 

Альтернативы достаточно разнообразны: git, svn, bzr, fossil, hg.

Я специально выделил Mercurial – потому что, к сожалению, если брать практику разработки хранения версий именно для 1С – эта распределенная система не подходит.У нее есть проблемы с кодировками в наименованиях файлов и, когда перед вами встанет вопрос об осуществлении обмена с другим сервером (например, один сервер будет базироваться на ОС Windows 7, а другой – на WindowsXP), вы не сможете синхронизировать данные из-за различного представления кодировок имен файлов для различных ОС. К сожалению, его нельзя пока использовать. Хотя это моя любимая система, т.к. она более логичная и с ветками работает наиболее понятно. Особенно для новичка, делающего попытки разобраться в принципах работы.

 

 

SCM fossil

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

 

 

Ее особенности:

  • Проста
  • Удобна
  • Весь пакет инсталляции содержит один файл exe, который содержит в себе
    • Систему версионного контроля
    • Систему документирования на основе wiki
    • Простейший баг-трекинг
    • Встроенный web-сервер
    • Управляется с web-браузера
    • Единственный недостаток – нет GUI-интерфейса, к которому все привыкли. Покликать мышкой, чтобы сделать коммит/добавить файл, не получится. Посмотреть изменения через web-интерфейс можно. Но все остальное стандартно, только через консоль
    • Советую применять для внешних обработок, отчетов, схем СКД, различных внешних файлов. Почему-то у нас не любят хранить версии схем СКД, но ведь в процессе разработки схемы для какого-то отчета можно уйтив сторону и потом не вспомнить, какую схему мы использовали изначально…
    • Также SCMfossil можно применять как замену хранилищу для удаленной разработки или для малой разработки. Например, если у вас небольшая конфигурация или раз в два месяца какая-то удаленная разработка – чтобы вспомнить, что же там было в изменениях, fossil подходит просто идеально. Компактный и поддерживает все необходимое для удобной работы.

Здесь приведен простой скриншот web-интерфейса fossilс реальной работы. Внизу видно, как какая-то ветка разработчика слилась в основной ствол дерева.

 

 

 

Практика применения

Теперь продолжим про практику применения в 8.3 различных распределенных систем.

 

 

В ходе экспериментов с различным программным обеспечением я для себя составил такой набор необходимых инструментов:

  • Система управления задачами – Redmine. Я использую ее совместно с удобным плагином для обзора кода CodeReview
  • Сервером для Gitу меня служит такая программка, написанная на Java, как Scm-Manager– контроль репозиториев. Удобно ставится, настраивается через простейший web-интерфейс – запустили и все работает.
  • TortoiseGit – клиент для Git под Windows на основе «черепахи». Кто работал с Subversion – тот знает, что есть такой TortoiseSVN, TortoiseGIT и пр.
  • И, главный виновник торжества – 1С:Предприятие 8.3. Это то, что нам позволяет полностью выгрузить конфигурацию в файловую систему.

 

 

Связь коммита с задачей

Рассмотрим простейшие понятия. Может, это даже больше относится к системам управления требований (задач).

 

 

У меня есть настроенная синхронизация хранилища 1С:Предприятия с GIT, и, в дальнейшем, это передается уже в систему управления задач Redmine.

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

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

Есть плагин для Снегопата, который позволяет при помещении объекта в хранилище подключиться к Редмайну, выбрать определенную задачу, связанную с этим объектом, и автоматически сформировать краткое содержание того коммита, который должен быть (чтобы вы руками эти данные не писали). Соответственно, если нет Снегопата, то эти действия нужно делать руками. Хотя бы просто указать, какая задача закрылась.

 

В результате для задачи в системе Редмайн в поле «Связанные редакции» вы получите такую картинку – можно перейти, посмотреть, какой код изменялся. Это очень удобно.

 

 

Ветвление

Эта тема очень большая и актуальная.

 

 

Самих способов ветвления три. Остальное – их комбинации.

  • Ветвление по функционалу.

Например, вы разрабатываете какую-то подсистему – она разрабатывается неделю-две. И, в то же время, она еще окончательно не готова (не работает пока). Сейчас у вас какая задача:

  • захватить корень,
  • добавить новый объект
  • отпустить корень
  • Работать над объектом
  • Если он кому-то понадобится – отпустить
  • Потом опять захватить и т. д.

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

Соответственно, что такое ветвление по функционалу различных доработок, подсистем? Вы выделяете ветку под какую-то подсистему, туда производятся коммиты, изменения… И когда она у вас уже готоваделаете так называемый «мерж» (объединение историй). Опять-таки, за счет общего родителя (на картинке представлен пример – я думаю, понятно, что разработка началась с определенной версии), после какого-то промежутка в несколько коммитов изменения были влиты в основной ствол разработки. И это одно из преимуществ ветвлений, которое просто завоевывает мир, позволяя вот так непринужденно ветвить вашу историю, давая разработчику возможность разобраться, как же оно получилось.

  • Следующий способ ветвления – ветвление по пользователям. Тоже применяется. Например, у вас есть удаленный разработчик, или какой-то новый молодой специалист. И у вас стоит компромисс – или дать доступ на запись в хранилище, или… По мне, так это – «пусти козла в огород»… Если не проконтролировать, что он там изменял, завтра с базой будет совсем плохо. Одно дело, если этот «специалист» рядом сидит, и его проконтролировать и сделать ему какие-то замечания не составляет труда. А если это удаленный разработчик и он уехал куда-то в Таиланд – то… хранилище не поможет вам этого разработчика проконтролировать. Только если дать ему конфигурацию хранилища на чтение, а потом вам или ему мучиться с объединением. Никто не захочет дальше работать с вами. А возможность использовать трехстороннее сравнение позволяет определить именно те объекты, которые были дважды изменены, и быстро, с помощью различных инструментов типа kdiff3, их объединить. Это дорогого стоит.
  • Ну и самый последний, не любимый мною способ ветвления – это ветвление по задачам. На каждую задачу открывается отдельная ветка. Потом - вы задачу решаете, ветку закрываете. Поверьте, если задача у вас не долгоиграющая, и она закрывается за один-два коммита – лучше отдельную ветку под нее не выделять, потому что в определенном смысле вы можете уйти совершенно в другую степь. В этом смысле ветвление – это «зло». Может вдруг оказаться, что в ветке, предназначенной для решения одной задачи – вы «на автомате» начнете реализовывать и другие задачи, для других подсистем и в один момент времени может оказаться, что ваша основная ветка стала называться не trunk, а «суперРазработка252». Разобраться, где что, будет уже сложнее.

 

 

Обзор кода

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

 

 

Конечно, это решается административным путем – пришел утром на работу, сделай обновление конфигурации из хранилища. Посмотрел, что у тебя в хранилище 10 объектов измененных, смотришь «А кто их изменял?». Если там два программиста – еще можешь спросить/узнать, что же там изменяли. А если больше двух? Здесь начинается проблема коммуникаций, и понять, кто же что изменял в хранилище, довольно-таки трудно.

Соответственно – обзор кода нам позволяет заставить себя исправить наш «бистро-код», который мы быстро сделали, а потом забыли. Вы можете встать в Редмайне на ту строчку кода, которая вам не нравится, нажать «Создать задачу» и назначить ответственным за эту задачу того, кто поместил этот код в хранилище. Эта задача висит над ним, как «дамоклов меч». Она, конечно, может висеть долго-долго, а может сразу исправляться.

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

 

Авторство кода

Самая интересная картинка – «Авторство кода».

 

 

В стандартном хранилище от 1С я не знаю способа, как получить «Кто же писал эти строки?»

И, если разбираться, где там закралась наша ошибка, то, используя метод бинарного поиска, пять минут на получение из хранилища cf-ника – узнаем, что все-таки оно не здесь изменилось, и так дальше-дальше-дальше – пытаемся найти, кто же когда это изменил.

А тут, с помощью любого редактора, поддерживающего вывод авторства строк (того же GIT), вы можете встать на определенную строчку кода, и он вам покажет ту версию, с которой это было изменено. А потом еще дополнительно покажет все версии этого файла, которые были в системе контроля версий.

Думаю, многие с этим встречались, и кто-то может сказать, что все равно неизвестно, кто виноват (один программист одно условие добавил, а кто-то выше добавил еще какое-то условие – это он виноват).

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

 

Практика применения при выгрузке конфигурации в 8.3
Ложка дегтя

Сразу скажу, просто так взять и использовать выгрузку у вас не получится.

 

 

  • Во-первых, ваша древовидная конфигурация превращается в файловой системе в линейный список.
    То есть, например, наиболее распространенная конфигурация УТ 10.3 – в разобранном виде превращается в 9451 файл в одной папочке. Причем ориентироваться по таким файлам просто невозможно (Документ.Реализация.МодульОбъекта.txt). С учетом того, что по алфавиту там сначала идут роли, найти в этом списке нужный объект очень затруднительно.
    • Соответственно, для этого я использую такой метод – я выгружаю файл конфигурации в отдельную папку, а потом из этой папки копирую файлы в хранилище GIT с учетом структуры каталогов. То есть эта структура повторяет то же дерево, которое у нас есть в конфигурации. Для этого у меня есть специальная обработка, которая по точке, методом «МассивРазложитьВСтроку» разносит файлы по каталогам. Это позволяет наглядно посмотреть. Опять-таки, нам в скором времени обещают в 8.3 ускорение работы с хранилищем, но, в принципе, при такой выгрузке с помощью GITвсе равно то же самое получается. Вы получаете ту же самую информацию – только быстро, удобно… даже при ее линейном формате. Так же, как это в хранилище и есть.
  • Еще немаловажный факт – обычные формы выгружаются во внутреннем формате. То есть файл форм «закодирован» во внутренний формат 1С. Почему так сделано, мне, если честно, непонятно, так как в 8.2, допустим, у нас есть возможность получить модуль формы. Еще раз уточню: это касается только «толстых» форм. Я понимаю, что управляемые формы «побеждают весь мир», но УПП 2.0 еще не вышло, а у нас еще есть УПП 1.3, которое еще на «толстых» формах – живет и здравствует.
    • для этого есть обходные пути – есть такая чудная программа V8Unpack, которая распаковывает эти формы на внутреннее представление формы и на модуль формы. Соответственно, эта проблема просто обходится.
  • Огромный объем выгрузки ролей в файлы.
    • для меня стало неожиданностью, когда я увидел, что, оказывается, роли выгружаются полностью, то есть имеется возможность указать для роли «Право по умолчанию» на объекты. Но, все равно, роли выгружаются полностью. И, соответственно, есть проблема в хранилище. У вас, допустим, роль не захвачена, и в то же время вы добавили какой-то реквизит в документ. Вроде как только изменения документа идут, да? Если вы сделаете выгрузку конфигурации в XML,то у вас окажется, что у всех ролей есть изменения – добавлено новое право на новый реквизит (явное разрешение на чтение этого реквизита). Подчеркну, в выгрузке XML – изменение во всех ролях!
    • Кроме этого, есть еще проблема, связанная с тем, что роли из всего каталога конфигурации занимают наибольший размер.
  • И, конечно же, нет выборочной выгрузки/загрузки. Я не говорю даже о скорости загрузки/выгрузки. Но хотя бы выборочно выгружать, чтобы как раньше – можно было частично выбирать – выгрузить только документы или определенные документы.У нас бы стало проще с работой, не так долго нам пришлось бы выгружать/загружать эти данные, мы могли бы быстрее получать готовый результат.

 

Выводы

Соответственно, краткие выводы:

  1. Как альтернатива, вы можете использовать сейчас и GIT, и SVN, и BZR, и fossil – это все поддерживаемые системы. Если говорить про какую-то интеграцию с системой баг-трекинга, то здесь побеждает SVN и GIT. Если вы еще захотите ветвления – то, конечно же, без альтернативы GIT. То есть вроде как у вас есть альтернатива – но, тем не менее, альтернативы нет.
  2. Синхронизация хранилища 1С с git работает.
  3. Ветвление, в принципе, работает.
  4. Единственный минус – просто так взять и воспользоваться в этом плане 8.3, к сожалению, нет возможности, то есть без доработок не обойтись

Еще что хотелось бы сказать по поводу версионного контроля.

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


upd:

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

Стали более развиты средства по синхронизации хранилища 1С с git, опробованы приемы использования разработки по методики git-flow, с отказом от хранилища (удачно).

 

p.s.: Не можете применить git, примените хотя-бы хранилище.

 

***********************

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. BorovikSV 1368 17.04.15 10:42 Сейчас в теме
(0) По моему версионник должен ПОМОГАТЬ в работе и навигации по коду. Но случае с 1С, использование того же GIT, похоже на какое то извращение.
Коммит должен быть мгновенным в идеале. Следуя же вашей методологии - коммит превращается в долговременный геморой.

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

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

Сам активно использую GIT (когда пишу на DELPHI)
Сервер на базе (Gitblit, маленький шустренький, с веб интерфейсом и не требует JAVA)
4. pumbaE 637 17.04.15 12:36 Сейчас в теме
(1) т.к. сейчас метаданные выгружаются в нормальный формат(не считая толстых форм и activex объектов) при небольшом изменении стандартный merge тоже справляется и для форм, и для ролей и для описания объектов метаданных. К сожалению в хранилище упустили момент захвата отдельно "Модуля формы, модуля объекта, модуля менеджера" , а эти объекты могут так-же независимо дорабатываться.

У меня разница между помещением в хранилище и обновлением коммита в git от 10-15 минут, при этом полностью автоматизированно (можно вспомнить фразу "почему не работаете? Так компилиться." Сейчас с выходом eclipse , 1с тоже пошла путем "быстрый коммит", но теперь обратная сторона долгий деплой. Когда добавят частичную выгрузку по подсистемам, думаю время коммита и разворачивания сравняются.
Проверка на уровне хранилища, нужна, но так же нужна и автоматизированная проверка конфигураци, которая при каждом помещении в хранилище прогонит тестами новый cf файл - я выбрал для себя автоматизированную проверку.

p.s.: я не запрещая пользоваться, я даже советую "пользуйтесь любой системой контроля версий, прошу пользуйтесь", но хранилищем не воспользуешься для внешних обработок и уже надо искать альтернативы.

p.s.s: на момент выступления, gitlab только поднимался и его установка была не тривиальна, а scm manager поддерживает из коробки как git, так и svn, hg...

17. bforce 446 04.05.15 11:54 Сейчас в теме
(4)
но хранилищем не воспользуешься для внешних обработок и уже надо искать альтернативы.

Я начал использовать типовое хранилище для обработок юнит-тестирования. Приходится только добавлять "пустые" объекты, чтобы типизация реквизитов не слетала, и общие модули с пустыми процедурами/функциями, чтобы проходила расширенная проверка конфигурации. Не супер, конечно, но хотя бы что-то.
2. orefkov 2061 17.04.15 11:13 Сейчас в теме
Выборочная по крайней мере выгрузка скорее всего будет :)
Kinestetik; lustin; JohnyDeath; +3 Ответить
3. ekaruk 5166 17.04.15 11:38 Сейчас в теме
Жень, а нет случайно параллельного ведения в одном хранилище нескольких версий конфигурации как отдельных ветотк?
Т.е. конфигурация-родитель и своя на ее основе.
У меня такая схема очень прижилась с бухгалтерией. Есть 2 ветки и в любой момент можно сравнить любую версию родительской с любой версией своей.
С УТ11 схема не работает. После нескольких сотен коммитов на сравнении веток гит просто умирает. GitEntensions еще как-то шевелится, Atlassian зависает намертво.
Подскажи, какую-то идею, как удобно сравнивать различные версии разных схожих конфигураций.
5. pumbaE 637 17.04.15 13:00 Сейчас в теме
(3) я у себя так использую.
Все конфигурации которые у меня поставлены на поддержку находятся в отдельных ветках, т.е.:
origin_ut23
origin_bsp
origin_IR
origin_UOS
origin_agentplus

с префиксом origin у меня все типовые которые есть на поддержке в итоговой конфигурации, базовая ut23, все остальные создавалась ветка или же добавлялось как remote репозитарий и делался merge.

Так же использую ветки develop и еще 3 ветки от master на основе которых создаются свои отдельные поставки, т.е. по факту долгоиграющих веток у меня 10 в одном git репозитарии.
(origin_ut23, origin_bsp, ...) --> develop --> master , а master распадается на поставки(ветки) develop_simferopol, develop_dnepr, develop_kirovograv .

В принципе тормозов сильных не замечал, переодически делаю git gc, но у меня всего 15 000 объектов при выгрузки конфигурации.




8. ekaruk 5166 17.04.15 13:31 Сейчас в теме
(5) Кстати, а ветки идут полностью независимо или периодически пересекаются?
С учетом того, что Гит хранит только различия, теоретически это может помочь в сопоставлении файлов веток.
Я вообще не совсем понимаю, как сейчас Гит сравнивает ветки, если они пересекаются только у корня.
Технически для их сравнения необходимо применить всю историю изменений с самого начала для обоих веток и лишь потом их можно будет сравнить между собой.
9. pumbaE 637 17.04.15 13:47 Сейчас в теме
(8) как мнимум БСП у меня не пересекается, остальные периодически пересекаются, но бывает на 200-500 коммитов могут отличатся. С другой стороны linux kernel спокойно такие diff показывает, т.е. имхо проблема не в этом.

(7) т.е. Catalog.апОтчетыДляМобильныхУстройств.Form.ФормаЭлемента.Form.Module.txt у тебя превращается в Catalog/апОтчетыДляМобильныхУстройств.Form.ФормаЭлемента.Form.Module.txt ? Но тогда это не сильно отличается от линейной структуры....
10. ekaruk 5166 17.04.15 13:59 Сейчас в теме
(9) Да, структура такая.
Вроде хватает для ориентирования по объектам.
Думаешь, может влиять на скорость работы?
11. pumbaE 637 17.04.15 14:36 Сейчас в теме
(10) как вариант, я пока не знаю где та граница когда начинает тормозить на 10 000 файлов в папке или же на 2000 ... Все таки при разбивке по двум точкам в одном каталоге будет значительно меньше файлов Catalog/апОтчетыДляМобильныхУстройств/Form.ФормаЭлемента.Form.Module.txt
6. pumbaE 637 17.04.15 13:11 Сейчас в теме
(3) надеюсь, у тебя по каталогам же конфигурация раскидана, а не в линейном виде?
7. ekaruk 5166 17.04.15 13:24 Сейчас в теме
(6) У меня в бухгалтерии было 4 отдельные конфигурации как ветки. Работало отлично.
Сейчас с УТ плохо получается. Внутри веток сравнение нормально работает. Между ветками неприемлемо медленно.
Структура дувхуровневая. Часть по первой точки - папка, внутри файлы.
12. sashocq 191 17.04.15 16:05 Сейчас в теме
Может, не придется больше нам так извращаться: http://habrahabr.ru/company/infostart/blog/255757/
13. ekaruk 5166 17.04.15 16:42 Сейчас в теме
(12) sashocq, Думаю, все те кто дочитал до этой строки, Eclipse не только видели на картинках, но и к Гиту уже подключали.
На самом деле среда не важна.
Что конфигуратор, что отдельная среда разработки.
Будет все то же самое, что в публикации, только не скриптами и обработками, а Джава-плагинами под Eclipse.
Т.е. публикация больше не о конкретной реализации, а о подходе.
autotrade; awa; JohnyDeath; pumbaE; +4 Ответить
14. lustin 17.04.15 17:05 Сейчас в теме
(0) для тех кто хочет прочувствовать как это было - в статью все же нужно добавлять еще и ссылку на открытое видео http://infostart.ru/video/w193627/
Quasar; artbear; +2 Ответить
15. JohnyDeath 298 18.04.15 07:20 Сейчас в теме
На моем сервере типовая БП 3,0 раскладывается на исходники минут 30. Поэтому использовать все эти прелести децентрализованных cvs приходится только как дублирующее хранение исходников конфигурации, где можно быстро посмотреть изменения в самих модулях и их авторство. Для git-flow такое время не приемлемо. (пользуясь случаем, передаю привет Алексею Л. ;) )
16. awk 718 18.04.15 23:12 Сейчас в теме
Пять копеек: CVS и SVN хоть и централизованные, но блокировщиками не являются. Они просто поддерживают данный функционал.
18. ИНТЕГРА 24 07.06.15 07:31 Сейчас в теме
Прочитал публикацию и для себя определил, что она скорее для расширения кругозора. На практике удобства в моём конкретном случае не представляю.
Возможно потому что конфигурации, которые сопровождаю, находятся на разных серверах в разных частях города и связи между ними как таковой нет (несколько УППэх, несколько КАшек и по мелочи БП/УТ).
Если бы кто-нибудь поделился гениальными идеями как собрать мой огород в одну кучу - был бы только рад.
А пока для себя ничего лучше, чем грамотное оформление кода не придумал :)
19. pumbaE 637 08.06.15 08:43 Сейчас в теме
(18) ИНТЕГРА, не понял вопроса. Чего хотите в итоге добиться? Улучшение качества кода? Уменьшения fail-ов после обновления рабочей базы? Управления кодом (codereview, анализ где,кто и что добавил, по каким задачам был изменено тот или иной участок кода)?
20. ИНТЕГРА 24 08.06.15 16:18 Сейчас в теме
(19) Инкапсулировать все свои доработки/наработки в одном месте, но если у Вас есть конкретное предложение, То почему отвечаете вопросом на вопрос? :)
21. roofless 22 21.06.16 08:55 Сейчас в теме
а потом из этой папки копирую файлы в хранилище GIT с учетом структуры каталогов.То есть, эта структура повторяет то же дерево, которое у нас есть в конфигурации. Для этого у меня есть специальная обработка, которая по точке, методом «МассивРазложитьВСтроку» разносит файлы по каталогам

видел, что в 8.3.7.1759 и 8.3.8.1652 уже добавили такую фичу, но мы сидим на 8.3.6 и пока обновиться нет возможности.
если можно, прикрепите обработку к публикации
23. kolya_tlt 24 13.09.17 15:36 Сейчас в теме
пишут в заголовке темы, что альтернатива есть, а в комментариях - нет. где правда?
24. pumbaE 637 13.09.17 18:17 Сейчас в теме
(23) правды нет. Есть гит, есть тема про гит на предстоящем евенте, есть релиз едт финальный, для расширений только выгрузка в исходники без хранилища.
25. ifilll 14.09.17 14:40 Сейчас в теме
Приступая к чтению статьи догадывался что GIT выйдет победителем, и не ошибся.
Скорей всего не один я такой, спасибо что сделали обзор, про другие системы контроля версий ничего не знал.
Оставьте свое сообщение

См. также

Использование программных перечислений, ч.1: строковые константы Промо

Практика программирования v8 1cv8.cf Бесплатно (free)

Часто ли у вас возникает необходимость в коде выполнять сравнение на строку?

10.12.2016    37241    unichkin    74    

Программная работа с настройками СКД

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Нюансы программной работы с настройками системы компоновки данных в отчетах и динамических списках. Обзор всех видов настроек компоновки. Что в каких случаях правильно применять. В качестве примера рассмотрена работа с отборами и группировками.

27.01.2020    25577    ids79    26    

[СКД] Программное создание схемы компоновки данных

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Сделаем отчет на СКД полностью программно, без использования макета "схема компоновки данных".

15.01.2020    23046    John_d    22    

Последовательности событий. Шпаргалка

Практика программирования v8 Россия Бесплатно (free)

Собрал информацию о событиях/подписках/расширениях в одном месте.

30.12.2019    17605    kuzyara    33    

Вспомогательные инструкции в коде 1С Промо

Практика программирования v8 1cv8.cf Бесплатно (free)

Помогаем редактору кода 1С помогать нам писать и анализировать код.

15.10.2018    30099    tormozit    100    

30 задач. Странных и не очень

Практика программирования v8 Бесплатно (free)

30 задач на знание языка программирования 1С и некоторого поведения платформы. Маленьких. Странных и не очень.

02.12.2019    16877    YPermitin    72    

Как передать IP адрес, который вызвал HTTP запрос в 1C (для веб-сервера Apache)

Практика программирования v8 Бесплатно (free)

Столкнулся с задачей получения IP адреса, который вызывает http сервис 1С. Итак, решение:

22.11.2019    8274    Sibars    19    

Таблица значений. Нюансы

Практика программирования v8 Бесплатно (free)

Обзор некоторых аспектов использования общеизвестного инструмента 1С.

01.10.2019    32548    Yashazz    50    

Оформление и рефакторинг сложных логических выражений Промо

Практика программирования v8 Россия Бесплатно (free)

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

20.09.2012    77861    tormozit    131    

О программе Postman для тестирования API и для чего она нужна 1С-нику

Практика программирования Программное обеспечение (software) v8 Бесплатно (free)

Для чего нужна программа Postman для тестирования API и какая от него польза для 1С-программиста.

24.09.2019    11615    budidich    28    

[Шпаргалка] Программное создание элементов формы

Практика программирования Работа с интерфейсом v8 1cv8.cf Бесплатно (free)

Программное создание практически всех популярных элементов формы.

06.09.2019    48565    rpgshnik    63    

Агрегатные функции СКД, о которых мало кто знает

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Пользуетесь ли Вы всеми возможными агрегатными функциями, которые предоставляет система компоновки данных? Если Вы используете только: СУММА, КОЛИЧЕСТВО, МИНИМУМ, МАКСИМУМ, СРЕДНЕЕ, то эта статья для Вас.

05.09.2019    48485    ids79    54    

Запись значения в поле ввода/формы со срабатыванием события ПриИзменении Промо

Практика программирования v8 1cv8.cf Россия Бесплатно (free)

Иногда возникает необходимость после записи значения в какое либо поле ввода/формы вызвать для него обработчик события ПриИзменении, а о вызове самого события приходится только мечтать. В этой статье приводится программный способ вызова этого события.

11.07.2007    48205    tormozit    41    

Регистры бухгалтерии. Общая информация

Практика программирования Математика и алгоритмы v8 v8::БУ БУ Бесплатно (free)

Общая информация о внутреннем устройстве регистров бухгалтерии.

05.09.2019    27930    YPermitin    24    

Три костыля. Сказ про фокусы в коде

Практика программирования v8 Бесплатно (free)

Три интересных (или странных) костыля в коде, которые могут помочь в повседневных и не очень задачах.

03.09.2019    25336    YPermitin    80    

Отслеживание выполнения фонового задания

Практика программирования Универсальные функции Разработка v8 1cv8.cf Бесплатно (free)

Запуск фонового задания из модуля внешней обработки. Отслеживание выполнения задания в виде прогресса, расположенного на форме.

17.08.2019    31175    ids79    16    

Как сделать из &НаКлиентеНаСервереБезКонтекста почти &НаКлиентеНаСервере Промо

Практика программирования v8 1cv8.cf Россия Бесплатно (free)

Как сделать метод формы, доступный на клиенте и на сервере одновременно, и сохранить при этом удобство разработки

10.09.2017    44639    tormozit    74    

Функции СКД: ВычислитьВыражение, ВычислитьВыражениеСГруппировкойМассив

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Подробное описание и использование внутренних функций системы компоновки данных: Вычислить, ВычислитьВыражение, ВычислитьВыражениеСГруппировкойМассив, ВычислитьВыражениеСГруппировкойТаблицаЗначений.

08.08.2019    79849    ids79    49    

Фоновое выполнение кода в 1С - это просто

Практика программирования v8 1cv8.cf Бесплатно (free)

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

02.08.2019    34479    avalakh    22    

Разбираемся с параметрами редактирования СКД

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Связь по типу, Параметры выбора, Связи параметров выбора

31.07.2019    23315    json    13    

Выгрузка документа по условию Промо

Практика программирования Разработка v8 Бесплатно (free)

Что делать, если документы нужно выгружать не все подряд, а по какому-то фильтру: статусу, дате, набору условий... А что если он соответствовал этим условиям, а потом перестал? А если потом опять начал? Такие ситуации заставили попотеть не одного программиста.

25.04.2019    16013    m-rv    2    

СКД - наборы данных и связи между ними, создание собственной иерархии, вложенные отчеты

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Набор данных объект. Использование в схеме компоновки нескольких наборов данных. Различные варианты связи наборов: объединение, соединение. Использование иерархии в отчетах на СКД. Создание собственной иерархии, иерархия детальных записей. Использование вложенных схем в отчетах на СКД.

26.07.2019    58320    ids79    11    

СКД - использование расширений языка запросов, секция ХАРАКТЕРИСТИКИ

Инструментарий разработчика Практика программирования v8 v8::СКД Бесплатно (free)

Автоматическое и не автоматическое заполнение полей компоновки данных. Использование расширений языка запросов для СКД «{…}», секция ВЫБРАТЬ, секция ГДЕ, параметры виртуальных таблиц. Автоматизированное использование дополнительных данных в запросе: секция ХАРАКТЕРИСТИКИ.

17.07.2019    35435    ids79    27    

Регистры сведений. За кулисами

Практика программирования Разработка v8 1cv8.cf Бесплатно (free)

Небольшие заметки по внутреннему устройству регистров сведений.

09.07.2019    25867    YPermitin    14    

Как прикрутить ГУИД к регистру сведений Промо

Практика программирования Перенос данных из 1C8 в 1C8 Разработка v8 Бесплатно (free)

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

16.04.2019    20143    m-rv    17    

"Меньше копипаста!", или как Вася универсальную процедуру писал

Практика программирования Разработка v8 v8::СКД 1cv8.cf Бесплатно (free)

Программист Вася разбирает подход создания универсальных методов на примере программного вывода СКД.

04.07.2019    19554    SeiOkami    50    

Работа с настройками системы компоновки данных

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Варианты отчетов, работа с настройками вариантов: структура группировок, поля отчета, отборы, сортировка, условное оформление, другие настройки, настройки отображения диаграмм.

02.07.2019    45561    ids79    17    

Создание отчетов с помощью СКД - основные понятия и элементы

Практика программирования Математика и алгоритмы v8 v8::СКД Бесплатно (free)

Основные принципы работы СКД. Понятия схемы компоновки и макета компоновки. Описание основных элементов схемы компоновки: наборы данных, поля, вычисляемые поля, ресурсы, параметры.

25.06.2019    51763    ids79    25    

Как сделать запрос на изменение данных Промо

Практика программирования v8 v8::Запросы 1cv8.cf Бесплатно (free)

В статье приведены особенности внутренней архитектуры и примеры работы с расширением языка запросов 1С.

01.06.2018    30488    m-rv    21    

Многопоточное ускорение однопользовательских нагрузок в 1С + Microsoft SQL Server 2017

Практика программирования Производительность и оптимизация (HighLoad) v8 v8::Запросы Бесплатно (free)

Взаимодействие с Microsoft SQL Server нередко вызывает трудности у 1С-ников, а потому интересны любые моменты, связанные с его использованием. О своем опыте работы с новым SQL Server 2017 участникам конференции Infostart-2018 рассказал директор ООО «Аналитика софт» Дмитрий Дудин.

11.06.2019    24839    dmurk    145    

Регистры накопления. Структура хранения в базе данных

Практика программирования Разработка v8 1cv8.cf Бесплатно (free)

Структура хранения регистров накопления в базе данных для платформы 1С:Предприятие 8.x. Первая часть в серии публикаций.

16.05.2019    42474    YPermitin    30    

О расширениях замолвите слово...

Практика программирования Разработка v8 Бесплатно (free)

О чём стоит задуматься при принятии решения о создании расширения конфигурации…

07.04.2019    35152    ellavs    126    

Метод формирования движений в типовых регистрах нетиповыми регистраторами Промо

Практика программирования v8 1cv8.cf Бесплатно (free)

Вариант решения задач с проведением по типовым регистрам нетиповыми регистраторами. Зачем - чтобы при сравнении конфигурации не обращать внимание на свойства регистров и исключить вероятность допущения горькой оплошности при обновлении информационных баз, заменив типы регистраторов основной конфигурации типами конфигурации поставщика. Для программных продуктов, имеющих в своем составе метаданных документ "Корректировка регистров"("Корректировка записей регистров").

05.12.2017    28205    itriot11    34    

Git-репозитории для 1С-кода (опыт использования при небольших проектах)

Практика программирования v8 Бесплатно (free)

Инструкции по взаимодействию с Git-репозиторием, которые писались для тех наших программистов, которые вообще никогда не работали с Git (руководства в духе "Как получить код из git-репозитория?", "Как отправить код в git-репозиторий")...

28.03.2019    27298    ellavs    89    

Трюки с внешними источниками данных

Практика программирования Разработка v8 1cv8.cf Бесплатно (free)

Некоторые трюки для преодоления ограничений внешних источников данных.

14.03.2019    31157    YPermitin    53    

Ошибки при работе с хранилищем конфигурации и способы их решения

Практика программирования v8 Бесплатно (free)

В статье собраны наиболее распространенные ошибки при работе с хранилищем конфигурации и способы их обхода и решения.

01.03.2019    38672    Смешной 1С    28    

Использование классов .Net в 1С для новичков Промо

Практика программирования Разработка внешних компонент Универсальные функции v7.7 v8 Бесплатно (free)

Руководство для новичков. Написав статью http://infostart.ru/public/238584/, я понял, что многие не понимают того, что написано. Поэтому в этой статье постараюсь более подробно остановиться на азах и без кода на вражеском языке (C#)

27.01.2016    76210    Serginio    108    

Разработка и сценарное тестирование с Vanessa-ADD. Отчетность Allure. Автоматизация запуска сценариев

Практика программирования Vanessa Automation v8 Россия Бесплатно (free)

Формируем отчетность о результатах выполнения сценариев. Автоматизируем запуск.

26.02.2019    21788    Vladimir Litvinenko    27    

Автоматические и управляемые блокировки применительно к типовым конфигурациям 1С Промо

Математика и алгоритмы Практика программирования v8 v8::blocking 1cv8.cf Бесплатно (free)

Основные принципы работы с режимами автоматических и управляемых блокировок в 1С Предприятие 8. Теория и применение в типовых конфигурациях: БП, УТ, ЕРП

10.11.2018    34532    ids79    40    

Возможности типовых шаблонов ограничения доступа на уровне записей (RLS)

Практика программирования БСП (Библиотека стандартных подсистем) Роли и права v8 v8::Права Бесплатно (free)

Краткий обзор применения типовых шаблонов ограничения доступа на уровне записей в конфигурациях, созданных на базе БСП: #ПоЗначениям, #ПоНаборамЗначений, #ПоЗначениямРасширенный, #ПоЗначениямИНаборамРасширенный

03.02.2019    38937    ids79    9    

EnterpriseData – часть 2. Процесс выгрузки данных

Практика программирования Обмен через XML v8 v8::УФ Россия Бесплатно (free)

Основные этапы выгрузки данных через ED, обработчики событий выгрузки, правила обработки данных, правила конвертации объектов, конвертация свойств первого и второго этапов, процедуры БСП, используемые при выгрузке данных, структура «КомпонентыОбмена».

26.12.2018    26617    ids79    31    

Тестер: частые вопросы Промо

Практика программирования v8 Бесплатно (free)

Ошибкам бой - тесты норма жизни!

25.07.2018    29175    grumagargler    28    

Новый подход к обмену данными EnterpriseData

Практика программирования Обмен через XML v8 v8::УФ Россия Бесплатно (free)

Хочу предложить Вашему вниманию цикл статей, посвященных обмену данными через универсальный формат (EnterpriseData или ED).

14.12.2018    41102    ids79    72    

EnterpriseData - пример доработки правил конвертации без использования КД 3.0 в расширении конфигурации

Практика программирования Обмен через XML v8 v8::УФ БП3.0 УТ11 Россия Бесплатно (free)

В статье подробно описан реальный пример доработки обмена данными через EnterpriseData (универсальный формат обмена) между конфигурациями УТ 11.4 и Бухгалтерия 3.0

16.11.2018    36768    ids79    42    

Программное заполнение пользовательских параметров и отборов СКД

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

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

13.11.2018    46904    Unk92    25    

Ускоряем 1С: модули с повторным использованием возвращаемых значений Промо

Практика программирования v8 Бесплатно (free)

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

04.09.2017    52498    m-rv    61