gifts2017

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

Опубликовал Евгений Сосна (pumbaE) в раздел Программирование - Практика программирования

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

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

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

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

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

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

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

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

В 

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

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

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

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

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

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

В 

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

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

Открытыми системами этого типа являются CVS и SVN. До вчерашнего дня я думал, что CVS (ConcurrentVersionsSystem) уже можно выкинуть на свалку истории, но, оказывается, есть в нем некоторые моменты, которые все-таки до сих пор применимы и в наших сегодняшних жизненных реалиях.

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 2016 DEVELOPER.

См. также

Подписаться Добавить вознаграждение

Комментарии

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

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

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

Сам активно использую GIT (когда пишу на DELPHI)
Сервер на базе (Gitblit, маленький шустренький, с веб интерфейсом и не требует JAVA)
2. Александр Орефков (orefkov) 17.04.15 11:13
Выборочная по крайней мере выгрузка скорее всего будет :)
lustin; JohnyDeath; +2 Ответить
3. Евгения Карук (ekaruk) 17.04.15 11:38
Жень, а нет случайно параллельного ведения в одном хранилище нескольких версий конфигурации как отдельных ветотк?
Т.е. конфигурация-родитель и своя на ее основе.
У меня такая схема очень прижилась с бухгалтерией. Есть 2 ветки и в любой момент можно сравнить любую версию родительской с любой версией своей.
С УТ11 схема не работает. После нескольких сотен коммитов на сравнении веток гит просто умирает. GitEntensions еще как-то шевелится, Atlassian зависает намертво.
Подскажи, какую-то идею, как удобно сравнивать различные версии разных схожих конфигураций.
4. Евгений Сосна (pumbaE) 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...

5. Евгений Сосна (pumbaE) 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 объектов при выгрузки конфигурации.




6. Евгений Сосна (pumbaE) 17.04.15 13:11
(3) надеюсь, у тебя по каталогам же конфигурация раскидана, а не в линейном виде?
7. Евгения Карук (ekaruk) 17.04.15 13:24
(6) pumbaE, У меня в бухгалтерии было 4 отдельные конфигурации как ветки. Работало отлично.
Сейчас с УТ плохо получается. Внутри веток сравнение нормально работает. Между ветками неприемлемо медленно.
Структура дувхуровневая. Часть по первой точки - папка, внутри файлы.
8. Евгения Карук (ekaruk) 17.04.15 13:31
(5) pumbaE, Кстати, а ветки идут полностью независимо или периодически пересекаются?
С учетом того, что Гит хранит только различия, теоретически это может помочь в сопоставлении файлов веток.
Я вообще не совсем понимаю, как сейчас Гит сравнивает ветки, если они пересекаются только у корня.
Технически для их сравнения необходимо применить всю историю изменений с самого начала для обоих веток и лишь потом их можно будет сравнить между собой.
9. Евгений Сосна (pumbaE) 17.04.15 13:47
(8) как мнимум БСП у меня не пересекается, остальные периодически пересекаются, но бывает на 200-500 коммитов могут отличатся. С другой стороны linux kernel спокойно такие diff показывает, т.е. имхо проблема не в этом.

(7) т.е. Catalog.апОтчетыДляМобильныхУстройств.Form.ФормаЭлемента.Form.Module.txt у тебя превращается в Catalog/апОтчетыДляМобильныхУстройств.Form.ФормаЭлемента.Form.Module.txt ? Но тогда это не сильно отличается от линейной структуры....
10. Евгения Карук (ekaruk) 17.04.15 13:59
(9) pumbaE, Да, структура такая.
Вроде хватает для ориентирования по объектам.
Думаешь, может влиять на скорость работы?
11. Евгений Сосна (pumbaE) 17.04.15 14:36
(10) как вариант, я пока не знаю где та граница когда начинает тормозить на 10 000 файлов в папке или же на 2000 ... Все таки при разбивке по двум точкам в одном каталоге будет значительно меньше файлов Catalog/апОтчетыДляМобильныхУстройств/Form.ФормаЭлемента.Form.Module.txt
12. Александр Кузин (sashocq) 17.04.15 16:05
Может, не придется больше нам так извращаться: http://habrahabr.ru/company/infostart/blog/255757/
13. Евгения Карук (ekaruk) 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) 18.04.15 07:20
На моем сервере типовая БП 3,0 раскладывается на исходники минут 30. Поэтому использовать все эти прелести децентрализованных cvs приходится только как дублирующее хранение исходников конфигурации, где можно быстро посмотреть изменения в самих модулях и их авторство. Для git-flow такое время не приемлемо. (пользуясь случаем, передаю привет Алексею Л. ;) )
16. Василий Казьмин (awk) 18.04.15 23:12
Пять копеек: CVS и SVN хоть и централизованные, но блокировщиками не являются. Они просто поддерживают данный функционал.
17. Никита Коротаев (bforce) 04.05.15 11:54
(4) pumbaE,
но хранилищем не воспользуешься для внешних обработок и уже надо искать альтернативы.

Я начал использовать типовое хранилище для обработок юнит-тестирования. Приходится только добавлять "пустые" объекты, чтобы типизация реквизитов не слетала, и общие модули с пустыми процедурами/функциями, чтобы проходила расширенная проверка конфигурации. Не супер, конечно, но хотя бы что-то.
18. Александр Отр (ИНТЕГРА) 07.06.15 07:31
Прочитал публикацию и для себя определил, что она скорее для расширения кругозора. На практике удобства в моём конкретном случае не представляю.
Возможно потому что конфигурации, которые сопровождаю, находятся на разных серверах в разных частях города и связи между ними как таковой нет (несколько УППэх, несколько КАшек и по мелочи БП/УТ).
Если бы кто-нибудь поделился гениальными идеями как собрать мой огород в одну кучу - был бы только рад.
А пока для себя ничего лучше, чем грамотное оформление кода не придумал :)
19. Евгений Сосна (pumbaE) 08.06.15 08:43
(18) ИНТЕГРА, не понял вопроса. Чего хотите в итоге добиться? Улучшение качества кода? Уменьшения fail-ов после обновления рабочей базы? Управления кодом (codereview, анализ где,кто и что добавил, по каким задачам был изменено тот или иной участок кода)?
20. Александр Отр (ИНТЕГРА) 08.06.15 16:18
(19) pumbaE, Инкапсулировать все свои доработки/наработки в одном месте, но если у Вас есть конкретное предложение, То почему отвечаете вопросом на вопрос? :)
21. Алексей Ларин (roofless) 21.06.16 08:55
а потом из этой папки копирую файлы в хранилище GIT с учетом структуры каталогов.То есть, эта структура повторяет то же дерево, которое у нас есть в конфигурации. Для этого у меня есть специальная обработка, которая по точке, методом «МассивРазложитьВСтроку» разносит файлы по каталогам

видел, что в 8.3.7.1759 и 8.3.8.1652 уже добавили такую фичу, но мы сидим на 8.3.6 и пока обновиться нет возможности.
если можно, прикрепите обработку к публикации
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа