Кровь, пот и GIT

Публикация № 1791661 17.01.23

Приемы и методы разработки - Групповая разработка (Git, хранилище)

Ведущий разработчик 1С Андрей Карпов на конференции Infostart Event 2021 Post-Apocalypse поделился ошибками, которые совершают новички в работе с GIT. В докладе четыре кейса с пошаговыми инструкциями, которые позволят не допускать конфликтов в разработке.

GIT – это система для хранения и ведения истории изменения файлов. Это своего рода аналог хранилища 1С, но со своими особенностями и ограничениями.

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

 

Как обычно внедряется GIT

 

 

Как обычно внедряется GIT:

  • фаза 1 – внедрили GIT;

  • фаза 2 – ?

  • фаза 3 – все отлично.

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

 

 

Чтобы не возникало вопросов, давайте определимся с терминологией.

  • Репозиторий – это каталог, где хранятся все версионируемые данные GIT.

  • Commit – это фиксация текущих изменений и внесение их в историю вашей ветки.

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

  • Merge – объединение одной ветки GIT с другой.

  • Pull request – запрос на добавление ваших изменений в другую ветку. Он используется в том случае, если вам запрещен доступ для обновления через commit (пул-реквесты часто используются для объединения веток master и develop).

 

 

Дисклеймер: образ Андрюши является собирательным. Все возможные совпадения с реальным человеком случайны.

 

 

На слайде разработчик Андрюша. У него есть мечта – разрабатывать правильно, в большом коллективе единомышленников, и чтобы каждый был доволен процессом.

В свои молодые годы Андрюша уже “осознал” каково это – использовать хранилище 1С на практике. А может и вы сталкивались с таким?

 

 

Не приходилось ли вам восстанавливать затертые доработки форм в хранилище?

 

 

Или, может, просили “корень” у коллеги? А может быть, у вас была доработка одного и того же объекта?

Из-за таких вот ситуаций казалось, что GIT – это решение всех проблем.

 

Рекомендации для разработки через хранилище

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

  • не захватывать надолго корень конфигурации;

  • либо захватывать объекты только перед помещением в хранилище;

  • или вообще воспользоваться рекомендациями фирмы 1С «Технология разветвленной разработки».

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

По счастливой случайности, а может и божественному провидению, Андрюша все же нашел ту самую “компанию мечты”, где 1С-ники недавно отказались от хранилища 1С в пользу использования GIT и вместе с нашим Андрюшей им предстояло пройти тернистый путь командной разработки.

 

 

В процессе разработки поддерживалось две конфигурации.

  1. Жутко старый «Документооборот» еще первой версии, который был подключен к хранилищу;

  2. 1С:ERP, разработка которой перешла на GIT.

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

Помимо этого, использовался:

  • Redmine – для учета задач и трудозатрат;

  • Bamboo – для тестирования, формирования релизов и дополнительных служебных операций (в частности, для обновлений баз разработчиков);

  • сервер Bitbucket, как система для версионирования, хранения и рецензирования кода;

  • GIT Extension – локальный клиент для GIT. Он удобен тем, что бесплатный, имеет простой и удобный интерфейс, логирует действия пользователей и не вылетает при большом количестве файлов в одном коммите.

 

 

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

 

Как выглядит схема ветвления GIT и какие данные можно поместить

 

 

Схема ветвления веток GIT похожа на GitFlow:

  • основная ветка «develope»,

  • от нее формировались задачи «feature», соответствующие номерам задач из Redmine;

  • при выполнении задачи, разработчик мерджил эту ветку с веткой «test»;

  • ветка «test» была подключена к отдельной базе, на которой отдел сопровождения проверял доработки;

  • после проверки ветку разработчика объединяли с веткой «develope»;

  • раз в день, после проведения автоматизированных тестов, ветку «develope» объединяли уже с веткой «master», и из нее формировался релиз, который загружался в продуктив;

  • помимо этого существовала ветка «origin1c» – в ней была размещена конфигурация поставки, ее использовали для обновления конфигураций через GIT и для сравнения, чем модуль из «develope» отличается от типового.

 

 

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

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

  2. Правила обмена – для выгрузки использовалась утилита Gitrules, разработанная Олегом Тымко. Утилиту пришлось немного доработать, добавив поддержку выгрузки не только правил конвертации, но и правил регистраций и их сборку.

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

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

Пример команды для выгрузки конфигурации в файлы с помощью утилиты:

"C:\Program Files (x86)\1cv8\8.3.18.1334\bin\ibcmd.exe" infobase --dbms=MSSQLServer --db-server="Имя сервера" --db-name="Имя базы" --db-user="Имя пользователя SQL" --db-pwd="Пароль пользователя SQL" config export "Путь к репозиторию GIT" --base="Путь к ConfigDumpInfo.xml"

 

 

В таком процессе и начались рабочие будни нашего Андрюши.

Все было бы хорошо, и можно было бы сказать, что GIT – это удобный и практичный инструмент, но точно не для 1C:ERP.

В ней все очень тормозило: переключение между ветками, сравнение 2-х коммитов или веток.

Неприятной проблемой стало обновление на новый релиз – при этом коммитился cf-файл поставки, и в изменения попадали сразу все объекты конфигурации.

Разработчиков это сильно не устраивало. Стали искать способы ускорения - один из них стал GIT LFS.

 

 

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

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

Таким образом в GIT LFS были перемещены все бинарные общие макеты конфигурации и сам cf-файл поставки.

Общая схема выглядела так:

  • включаем GIT LFS на сервере Bitbucket;

  • на рабочем месте разработчика устанавливаем расширение https://git-lfs.github.com/ , сейчас git-lfs уже включен в дистрибутив git по умолчанию;

  • в консоли репозитория прописываем команду

git lfs install
  • указываем список файлов, которые необходимо отслеживать, командой

git lfs track "*.cf"
git lfs track "/Config/CommonTemplates/*/Ext/*.bin"

Стоит обратить внимание, что GIT LFS по факту удаляет файлы из каталога. Чтобы корректно загрузить конфигурацию из файлов, необходимо вначале получить их из центрального хранилища командой:

git lfs fetch --all

И заменить текстовые ссылки на реальные файлы командой:

git lfs checkout

 

Популярные задачи с GIT, частые ошибки и их решение

 

Задача №1: перенести из актуального релиза новый регламентированный отчет

 

Андрюше поручили перенести из актуального релиза новый регламентированный отчет по 6-НДФЛ. Да так, чтобы все объекты при обновлении сопоставились.

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

Задача отправилась на тестирование и прошла его.

Позже конфигурацию на сервере обновили до актуального релиза – для этого объединили ветку «origin1c» с «develop».

 

 

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

В чем же была причина?

 

 

Ошибка: весь список метаданных в выгруженном виде содержится в одном файле configuration.xml. Когда Андрюша добавил новый отчет, он был автоматически добавлен в конец этого списка.

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

 

Решение: вручную отредактировать файл Configuration.xml, удалив задублированные метаданные.

Чтобы ситуация не повторялась, необходимо:

  • либо перед выгрузкой конфигурацией файла, отсортировать метаданные конфигуратором по алфавиту;

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

 

Способы сохранения ConfigDumpIngo.xml

 

 

Объекты из 1С попадают в GIT с помощью команды конфигуратора «Выгрузить конфигурацию в файлы». Чтобы выгрузка проходила быстрее, разработчики 1С в версии платформы 8.3.10 добавили возможность инкрементальной выгрузки.

При этом формируется файл ConfigDumpInfo.xml, в котором содержатся идентификаторы всех выгружаемых объектов.

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

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

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

ConfigDumpInfo.xml – это файл Шредингера.

Его наличие в репозитории обязательно, но его нежелательно коммитить. Иначе он попадет в конфликты при объединении. И добавить в .gitignore нельзя, так как тогда он пропадет из видимости репозитория, и ты не поймешь, есть он в каталоге, или нет.

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

  • для этого необходимо запускать конфигуратор в пакетном режиме с командой «load-config-from-files» и параметром «--update-config-dump-info only»;

  • либо воспользоваться утилитой автономного сервера ibcmd и выгружать с помощью режима «infobase config export info».

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

Этот файл ConfigDumpInfo.xml они прятали из видимости GIT с помощью команды git stash – она перемещает выбранный файл в специальное отдельное хранилище, не добавляя в репозиторий.

Из хранилища его можно доставать командой git stash pop. Единственное ограничение – чтобы git stash работал - надо один раз поместить configdumpinfo.xml в коммит репозитория.

 

 

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

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

 

Задача №2: создать «ОченьВажныйСправочник»

 

 

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

 

 

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

Протестированную задачу Андрюши тоже отправили в рабочую базу, но при этом произошел конфликт версий xml.

 

Ошибка: в основном, файлы 1С в выгруженном виде представляют собой XML. В зависимости от версии платформы, структура XML для одного и того же объекта может меняться.

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

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

 

Решение: для правильного решения, Андрюше пришлось бы взять ветку до обновления и загрузить конфигурацию из файлов с этим обновлением. После этого сделать мердж его ветки с веткой «develope» с актуальным релизом. И заново выгрузить конфигурацию в файлы.

При этом 1С обновит структуру метаданных в соответствии с новым форматом. И тогда уже можно делать пул-реквест.

Однако кто в здравом уме будет этим заниматься? Достаточно просто вручную поменять версию XML через блокнот. Ошибок совместимости при этом не замечено.

 

 

Задача №3: исправить ошибку версии формата XML

С переходом на GIT появилась возможность редактировать конфигурацию, не прибегая к конфигуратору. Ведь правильно, зачем нам такая громоздкая IDE, если есть Notepad++ или Visual Studio Code? С более мелкими задачами они прекрасно справляются.

Вернемся к задаче про справочник.

 

Хитрый и ленивый Андрюша, чтобы исправить версию XML, решил воспользоваться глобальным поиском Visual Studio Code. Правда, когда коммитил, заметил небольшую странность – текст запроса динамического списка почему-то отображался, как «измененный». Хотя никаких изменений он не вносил.

«Видимо глюк», подумал Андрюша GIT, и смело отправил задачу на тестирование.

За такие смелые и быстрые решения его уже стали считать косячником.

 

 

Но как ни странно, у Андрюши получилось сформировать конфигурацию.

Однако ошибка есть. Она не существенная: в рамках текущей задачи ни на что не влияет. Андрюше не пришлось краснеть перед коллегами.

 

Возможная ошибка:

  • Ошибка из-за преобразования переносов строк LF и CRLF. Проблема была бы, если бы изменения внесли в типовые объекты конфигурации.

  • Редактор VS Code автоматически преобразовывает переносы строк LF и CRLF к единому стилю, которые соответствуют форматам Linux и Windows.

    То, что Андрюша увидел как глюк GIT – это, на самом деле, было преобразованием формата переноса строк Linux на формат Windows.

    Для 1С – это некритично, но неприятно, потому что перенос строк LF содержится в XML-файлах, которые содержат теги с многострочным текстом. В частности, «ТекстЗапроса» динамического списка или шаблон RLS ролей.

  • Невнимательность разработчика может привести к появлению конфликтов в тех объектах, в которые не планировалось вносить изменения. Очень сложно мониторить изменения, когда в списке измененных появляются непонятные доработки.

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

    Если конфигурация использует механизм представлений, запрос парсится и заменяется на другой. А из-за автоматического преобразования LF на CRLF такой парсинг просто не работает, так как он рассчитан на другие переносы строк.

  • В типовых конфигурациях добавили заглушку, которая подменяет переносы строк формата Windows на Linux.

 

 

Решение:

  • откатиться на предыдущую версию файла через GIT;

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

  • либо оставить все как есть. Главное знать, что могут быть проблемы с зарплатными модулями – других проблем не будет;

  • и еще в GIT можно настроить автоматическое преобразование переносов строк.

 

 

В GIT нет попроцедурного сравнения. С этим просто надо смириться. Реализовать сравнение модулей как в конфигураторе никак не получится.

 

Задача №4: сменить неприятное имя документа и добавить верхний регистр

 

 

Андрюша увидел, что «ОченьважныйДокументДляУчета» называется неправильно, нарушая стандарт CamelCase – буква «в» должна быть в верхнем регистре.

Руководствуясь благими намерениями, он поправил букву.

Однако в GIT отобразились только два измененных файла: файл Configuration и сам объект, хотя должно быть больше. Не чувствуя подвоха, Андрюша отправил задачу на тестирование.

 

 

Тестирование она не прошла.

 

Ошибка: проблема встречалась только на старых версиях GIT, потому что он не понимал смену регистра букв в именах файлов на файловых системах NTFS и Fat32.

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

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

 

Решение: необходимо воспользоваться консолью GIT и переименовать файл через консоль с параметром -f командой

git mv filename.txt FileName.txt -f

Он вносит эти изменения насильно, чтобы это фиксировалось в GIT.

 

В команде Андрюши все формы редактировались программно. На это были объективные причины, так как, если это сделать интерактивно, возникали проблемы. Например, в таблицу товаров документа реализации добавили колонку «Себестоимость».

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

 

 

Но ручное редактирование форм может привести к неприятным последствиям:

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

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

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

  • расширение также выгружается в GIT в виде XML-файлов, и теряется наглядность понимания, что именно поменялось на форме;

  • разработчики не раз сталкивались с тем, что когда нажимаешь кнопку «Обновить форму», в захваченной форме слетал фильтр измененных объектов. Измененными становились сразу все объекты. И тогда уже не понять, что именно было доработано.

 

 

Также в GIT есть механизм автоматического переименования файлов: в одном коммитe ищется удаленный или/и добавленный файл с одинаковым расширением и определенным уровнем схожести.

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

Как убрать такое поведение GIT, Андрюша просто не знал. Он привык, что в каждой системе для каждого параметра есть соответствующий флажок и галочка, как в 1С. Но в GIT он ничего такого не нашел: ни в Git Extensions, ни на форумах разработчиков.

Ситуация разрешилась случайно.

 

Блуждая по интернету, он забрел на официальный сайт платформы EDT, где на одной из страниц был текст: «Для комфортной работы воспользуйтесь следующими настройками». Последние два параметра как раз и убирают поиск переименования в GIT.

 

 

Мораль: не будьте Андрюшами и читайте документацию.

Наверное вы заметили, что здесь практически не упоминается EDT. Это связано с тем, что в компании Андрюши его практически не использовали.

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

 

Итоги

 

Прошли месяцы. Если вы решили, что Андрюша сбежал, то это не так.

Хотя и описанные в докладе проблемы позволяют думать, что GIT – это пытка, но Андрюша уже привык.

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

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

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

 

 

Так данный доклад и не агитирует переходить на GIT. Это просто инструмент, который вы используете. Но надо знать, что у него есть определенные плюсы.

 

В отличие от хранилища, GIT позволяет работать с большим пулом задач, когда:

  • часть задач на тестировании;

  • часть в разработке;

  • а часть ждет, когда ты к ним вернешься, спустя полгода.

Если рассматривать такую доработку не через GIT, то для каждой мало-мальски крупной задачи приходится создавать отдельное хранилище.

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

 

Вопросы.

 

На последней картинке с коммитами GIT я не увидел нормального описания, что сделал разработчик. Я бы посоветовал в тексте описания коммита все-таки писать, что сделал разработчик.

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

Какая конфигурация компьютера использовалась у разработчика? И почему он не мог использовать EDT для разработки ERP?

Был достаточно мощный удаленный сервер – 240 Гб оперативной памяти. Но поскольку это удаленный сервер, на нем одновременно через RDP работало много разработчиков, и в EDT тормозила даже контекстная подсказка – в таких условиях работать было невозможно.

На сайте 1С есть рекомендации по серверам для малых, больших и очень больших конфигураций. Если брать для ERP конфигурацию компьютера, на которой была запущена EDT, то это минимум 16 гигов оперативной памяти и все на SSD дисках. При нормальной конфигурации компьютера это рабочий вариант. Но да, не для RDP, а на одного человека.

Для ЗУПа, для Бухгалтерии, для домашнего компьютера с 32-гиговой оперативкой, я использовал EDT, но на рабочем сервере это было проблематично.

 

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

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.

Больше статей можно прочитать здесь.

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. kuzyara 1432 17.01.23 12:12 Сейчас в теме
> GIT Extension
Рекомендую попробовать gitkraken
2. karpik666 3665 17.01.23 12:29 Сейчас в теме
(1) пробовал, очень красивый, только интерфейсно показался сильно не привычным, и так и не нашел где можно запускать произвольные скрипты прямо из интерфейса, плюс он вроде платный
3. Segate 165 17.01.23 14:04 Сейчас в теме
(1) Vsode наше все ) Зачем еще что-то, когда в иде есть отличный гит клиент )
pavlov_dv; +1 Ответить
4. karpik666 3665 17.01.23 14:18 Сейчас в теме
(3) vscode также используем, с подсветкой синтаксиса 1С, но это все равно целиком не заменит работу с конфигуратором, это хорошее дополнение, но не его полная замена, имхо.
5. Segate 165 17.01.23 14:20 Сейчас в теме
(4) Ни в коем случае это не заменит конфигуратор. Но вот другой гит клиент -имхо ни к чему )
6. karpik666 3665 17.01.23 14:24 Сейчас в теме
(5) все-таки не соглашусь, git клиент как расширение vs code не столь удобен, как отдельный git клиент, как минимум, для меня показалось не удобным переключение между ветками, также отмечу, что там также нельзя запускать произвольные скрипты из интерфейса, как это есть в git extensions, для меня vscode, это удобный инструмент редактирования кода, или его поиска по структуре каталога, но точно не удобный git клиент.
kuntashov; +1 Ответить
7. user1559729 17.01.23 16:52 Сейчас в теме
Хорошая статья. Легко читается. Написано просто и доступно.
karpik666; +1 Ответить
8. Brawler 438 17.01.23 18:31 Сейчас в теме
Пока читал статью, в очередной раз понял нафига оно не надо... чтоб это поддерживать нужно тоже специалистов держать и гуру по решению нештатных ситуаций, которых не возникает при использовании "1С Хранилище конфигураций" + сервера хранилищ.

Я уже 10 лет пользуюсь со своей командой "1С Хранилищами конфигураций", никаких биений лбами практически не происходит, захват корня минимизируем вполне может быть и смешным способом, например на примере обработок и отчетов.
Создаешь в структуре метаданных: Отчет01, Отчет02,... ОтчетХХ, Обработка01, Обработка02,..., ОбработкаХХ.
Если кому требуется создать новый отчет или обработку, у него полно болванок, захватил и играйся от души. Создание болванок минутное дело, Ctrl+C, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V,...
Общие модули делим по типа ХХ_ПечатныеФормыПродажи, ХХ_ПечатныеФормыЗакупки, ХХ_Производство, ХХ_УправлениеСвойствами, ХХ_Константы, ХХ_ТЕкстЗапросов, ХХ_ОбщегоНазначения.... по итогу дробится функционал и редко кто-то пересекается из разработчиков.
Разработка вся только в расширении конфигурации, ОДНОМ ЕДИНОМ, а не зоопарке!!! Упрощен поиск ошибок, легко обновлять базу на новые релизы.

Да все знают, что "Хранилище конфигураций" и конфигуратор не навороченный VisualStudio, но блин его мне хватает на все 100%, ибо и отладка пашет хорошо, и интерфейс не вырви глаз как в EDT, легкая среда разработки имеющаяся везде, даже часто на тачках пользователей. Устанавливается крайне быстро. Прикручивать всякие гиты почти кощунство. Надеюсь 1С просто доработку проведет у "Хранилища конфигураций" может не зря они опрос и провели недавно.
triviumfan; Dimkasan; ivan1703; user658002_SvanMoscow; info1i; dima_home; ixijixi; +7 Ответить
10. karpik666 3665 17.01.23 19:30 Сейчас в теме
(8) Отмечу только, что поиск ошибок в хранилище не такой уж и удобный, а просмотр чем текущая форма конфигурации отличается от предыдущей вообще превращается в геморрой, так как быстро сравниваются только изменения в модуле. Также без комментария, по какой задаче сделано, и авторства очень сложно определить, кто именно сделал доработку. Плюс невозможно вести крупные долгоиграющие проекты на несколько недель или месяцев, у тебя тогда должно быть постоянно захвачены объекты из хранилища, либо целиком отключено хранилище, и это при том, что ты должен выполнять работу и по другим задачам. Плюс использование больше одного расширения с хранилищем превращается в ад подключения. А так каждый волен использовать собственный инструмент, какой ему удобней использовать.
kuntashov; +1 Ответить
11. Brawler 438 17.01.23 20:20 Сейчас в теме
(10) Ну как бы в хранилище есть функция выборочного сравнения объектов, где не тянется вся конфигурация целиком для сравнения, а только то что ты сравнивать хочешь. Мы доработками ERP занимаемся не снимая замков, и все дорабатываем в расширении, а поскольку расширение не такой гигант как сама типовая конфигурация, то даже полное сравнение в расширении происходит довольно быстро.
По поводу долгоиграющих доработок. Ну вот сижу я пилю реально два с лихом месяца что-то. И тут кому-то понадобилось внести правку там, он как и принято всегда просит отпустить объект, я же понимаю что не могу. Но на самом деле могу. Сохраняю CFE, отпускаю объект. Там человек делает правку быстро. Я смотрю, что он менял. Захватываю объект, делаю сравнение и объединение, вношу такую же правку как тот человек и продолжаю работать. Это краааайне редко так делать приходится ибо как правило все разработчики занимаются разными областями.
Я реально много чего переписывал комплексно и не один месяц, и я не сцу за свои доработки, я могу их сдавать тупо частями, освобождаю объекты, а есть (не в моей команде) туча программистов сыкунов, которые не могут гарантировать работу своего кода и потому будут миллион захваченных объектов держать. Я при том сдавая частями что-то могу уже даже наблюдать как что-то частично уже жить начинает, а я достраиваю все остальное, шаг за шагом. А могут мои сданные кусочки функционала начинать использовать и другие программисты.
Меня веселят люди пытающиеся использовать докеры шмокеры для отладок, создают себе кучу работы искусственно, вместо того чтобы просто сесть и хорошо продумать систему чтобы она обладала свойствами самотестирования там где ну прям вообще труба и сложные алгоритмы расчетов. Вот и Git у меня ассоциируется с бесполезной созданной искусственной работой, где перед руководством потом можно козырять красивыми и все равно не понятными ему словами.

Я не отрицаю, может для некоторых команд Git единственный выход, но я в такую опу еще не попадал к счастью!
Dimkasan; dima_home; +2 Ответить
13. karpik666 3665 17.01.23 22:22 Сейчас в теме
(11) данная статья не агитирует за git, она только показывает какие ошибки могут быть, вы вольны использовать собственный инструментарий. Не понимаю такого негатива. И докеры и шмокеры хороши в определенных ситуациях, если вы их не используете это не значит, что они не нужны.
Я правильно понимаю, что вы ERP дорабатываете через расширение? это проект на сколько программистов и пользователей? Лично мое мнение, если ERP находится на поддержке у команды разработчиков, что нужно всячески уходить от расширений, они только усложняют дальнейшую работу и поддержку, а расширение использовать как патчи, вместо динамического обновления. Также хотелось уточнить, а как вы храните документацию, или внешние обработки и отчеты, вы их не версионируете, или например доработанные внешние регламентированные отчеты? Использование GIT призвано стандартизировать работу команды, а не выделять личность, которая может сдавать проект частями (правда непонятно, зачем неготовые объекты в системе, еще не протестированные пользователями), и те кто имеют меньше квалификацию. Процесс разработки делится на этапы выполнения работы и дополнительного контроля со стороны более квалифицированного коллеги, который и принимает решение о корректности выполнения задачи, дополнительно может проводиться код ревью, плюс задачи проходит этап тестирования, которая проводится заказчиком или ответственным сотрудником, и после переезжает в рабочую базу. Все это можно делать и через хранилище 1С, и через GIT , просто через git это проще. В хранилище при такой реализации нужно как-то покрывать дополнительно скриптами для переезда доработок между отдельными хранилищами: разработка, тестирование, рабочие. Конечно, если ты сам себе постановщик, разработчик, тестировщик, и тимлид, то такая схема работа вообще не нужна.
kuntashov; +1 Ответить
15. Brawler 438 18.01.23 00:04 Сейчас в теме
(13) Сейчас программистов 6 человек включая меня. Пользователей более ста. На предыдущей работе пользователей было свыше 300. Да как и писал выше сейчас нет того ада наверное, который есть у других, что они вынуждены использовать более так сказать серьезные системы типа Git. Я не негатювлю, просто люди должны понимать, что Git не панацея и не всегда нужен, можно обходиться и более простым функционалом.

Я правильно понимаю, что вы ERP дорабатываете через расширение?

Да дорабатываем через расширения все, при этом стремимся чтобы расширение было только одно, но сейчас их два. Второе заточено под интеграции с 1С ДО 2.1 (в нем тоже одно расширение). С Самого начала как начали использовать ERP, все дорабатывали только через расширения. Эта практика пока не подводила не считая иногда встречавшиеся глюки платформы. Разработка с применением расширений проходит куда интереснее чем портить типовой код, обновления на новые релизы протекают гладко, большое подспорье это проверка возможности применения расширений с автоматическим поиском проблем, хоть и не всех. В свое время я услал восстанавливать допилы в БП 2.0 - 3.0 при обновлении, в начале своей карьеры, кошмарная рутина стала. На ERP это было бы еще то удовольствие, не завидую тем кто пилит типовую.

Если снимать замки с типовой ERP, то банально как было замечено, обновление ставится не 30 минут, а 3 часа. Применять хранилище на типовой конфигурации пробовал, лютый трэш с длительностью захвата всех объектов, со сдачей в хранилище. Само по себе хранилище растет в размере большими темпами...

Также хотелось уточнить, а как вы храните документацию,

Документации к сожалению мало, по сути как и везде кто-то ставит ТЗ на ломанном языке, мы пытаемся реализовать. В сложных отчетах или обработках сразу в расширении пишется справка, чего вполне хватает.
От внешних отчетов и обработок планомерно уходим, разгребаем технический долг доставшийся в конце 2021 года, все переносим в то самое расширение где и версионируется оно уже хранилищем конфигураций.
До этого программисты 1С на предприятии пытались Git использовать для внешних обработок и отчетов, посмотрев на что я прекратил эту практику на корню ибо времени на то чтобы запихнуть в Git обработку или отчет, а потом положить в базу в справочник внешних обработок, уходило больше чем просто работать с хранилищем (свыше 300 обработок и отчетов было внешних). А ведь те программисты гавкались даже на этапе размещения в базе своей обработки ибо кто-то на несколько минут раньше туда положил такую же, но со своими доработками, ну и закономерно доработки одного терялись, так что внешние файлики это очень плохое решение. Позволительно только с нуля что-то как внешнее писать, отлаживается, а потом вживляется в расширение и уже потом групповая доработка через хранилище.

(правда непонятно, зачем неготовые объекты в системе, еще не протестированные пользователями),

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

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

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

Конечно, если ты сам себе постановщик, разработчик, тестировщик, и тимлид, то такая схема работа вообще не нужна.

Вот вот, ближе к истине, я тимлид, а моя команда программистов молодцы, каждый сочетает в себе: постановщика (под контролем меня), разработчика, тестировщика.

Такой состав функций у каждого программиста позволил за пол года без лишних соплей перевести 15 (1С КА 1.1) филиалов крупной фирмы в ERP, под знаменем новой одной организации. Потом в эту же базу за 3 месяца завести крупное производственное предприятие (1С УПП 1.3) являющейся материнским для той первой организации. Потом выполнить там же слияние организаций за 3 месяца. Предприятие видя, что программистов мало, а работ море пыталось привлечь много разных франчей. Только они слились все уже на этапе коммерческих предложений. И только из Первого Бита пару ребят удалось все же на процентов 5 работ задействовать на момент объединения фирм.

На новой работе применяя тот же подход, за 2.5 месяца удалось перевести фирму с релиза ERP 2.4 на 2.5.7, очень запущенная база. Ударными темпами, но вытянули, теперь разгребаем технический долг доставшийся по наследству (и это не только ERP). И тут хранилищ конфигураций за глаза хватает. В каждый момент времени программисты видят, что кто-то уже колупает некий объект и что можно просто заняться или другой работой или узнать, а нужен ли он еще, решается все без конфликтов и быстро. Проблем со слиянием доработок разных программистов нет ибо разработка и изменения последовательные получаются, сначала один допилил, потом другой, и так далее. Мы уже готовы ставить 2.5.11 релиз ERP, как только он перекочует в колонку стабильных. При этом нужно переименовать в расширении только одну подсистему и мы обновились (проверено на тестовой).


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

Ладно все это не о Git.
Кому надо тот его будет использовать.
Но я надеюсь, что все же на волне санкций, фирма 1С развивать будет свой инструментарий.
Dimkasan; muskul; dima_home; zqzq; exitel; karpik666; +6 Ответить
18. dima_home 194 18.01.23 13:01 Сейчас в теме
GitHab та еще мина замедленного действия. Чего стоят только потуги блокировки в Git некоторых Российских компаний.
19. karpik666 3665 18.01.23 14:08 Сейчас в теме
(18) так git и github это разные вещи, git будет работать, даже если все будет заблокировано со стороны других стран.
kuntashov; +1 Ответить
24. dima_home 194 18.01.23 18:05 Сейчас в теме
(19)
так git и github это разные вещи,
\
Я и не говорил о том что это одно и тоже. Может написал неудачно, согласен.
Просто когда все хвалят технологию системы контроля версий Git как правило игнорируют, что для ее использования часто применяют множество забугорного сопровождающего ПО и сервисов.
Когда я писал пример про сервис для хостинга и совместной разработки "GitHab", я "троллил" всю тему поклонения технологии Git.

Отдельно добавлю: Я работаю в компании, попавший под санкции. И в один день мы потеряли продукты adobe, KMS ключи мелкомягких (закрыли доступ к административному кабинету), Autocad и возможность оплачивать множество сервисов.

(15) Brawler я полностью поддерживаю. Двумя руками за.
Специально перешли на движок 8.3.20 а в дальнейшем на 8.3.21, что бы все изменения перенести в расширения и радоваться быстрым обновлениям. Команда из 5 программистов за год перевели 2 завода (производство табачных изделий) и одну крупную дистрибьюцию на ЕРП. Сейчас хотим перейти на движок 8.3.22, что бы решить еще несколько бизнес задач исключительно через расширения. 38 баз 1С на поддержке.

Вот вот, ближе к истине, я тимлид, а моя команда программистов молодцы, каждый сочетает в себе: постановщика (под контролем меня), разработчика, тестировщика.
... у меня абсолютно также, каждый программист по факту и архитектор и тестировщик. Стоит ли говорить, что еще в 2018 мы реализовали маркировку табачных изделий в УПП задолго до реализации маркировки в самой 1С. Проводил круглый стол сотрудниками из самой 1С и указывал на их ошибки при внедрении маркировки в ЕРП.
Недавно пополняли штат... новых сотрудников в ИТ правда найти так и не смогли (150к в КЛД или 200к в СПБ), те кто приходили и тестировались не могут простейшие задачи решить, зато каждый считает, что нужно выносить сервера в облако и внедрять git.
26. karpik666 3665 18.01.23 18:47 Сейчас в теме
(24) у многих был похожий опыт, но "git" это не какая-то вражеская технология, это то же хранилище 1С, просто в чем-то более удобное, а в чем-то и более шустрое. Вы немного путаете, использование git c другими инструментами уже относится к CI, сейчас рассматривается замена хранилища, а тут не нужны дополнительные утилиты. Вы можете поставить сервер gitlab, но также вы можете и не ставить его, а сделать центральный репозиторий, который просто хранится на том же диске, что и ваш. А дальше например уже можно использовать redmine вместо jira, или просто скрипты на onescript, которые будут делать для вас нужные задачи. Я лично также не отказался от хранилища, но использую его только на проектах как привлеченный разработчик, и также разработку веду в основном через расширение. Однако на основной работе предпочитаю именно GIT, так как если процесс разработки поставлен, и все в команде понимают, что делать, то разработка становится в разы проще. Работа в хранилище начинает раздражать в команде разработчиков более 4-х человек, начинаются уже пересечения. Эта два не противоборствующих лагеря их можно использовать в паре, воспользуйтесь gitsync https://infostart.ru/1c/articles/1157400/ и раз в день выгружайте доработки в git репозиторий (скрипт можно добавить просто в планировщик windows), поставьте разработчикам vscode, в нем воспользуйтесь командой "открыть каталог" и просто оцените насколько удобный и быстрый поиск по всей конфигурации 1С, при этом с информацией о том, кто и когда вносил доработки, это просто дополнительная фишка, которая упростит вам жизнь, при этом вы также можете продолжать работу в хранилище, а репозиторий использовать чисто для более быстрого поиска.
27. karpik666 3665 18.01.23 18:56 Сейчас в теме
(24) также готов поспорить, что вы уже используете основную фишку git в своей работе, это обновление функции с директивой "изменение и контроль" в расширении на более новое содержимое, если подключить kdiff, то в принципе получится самый настоящий мердж.
32. dima_home 194 19.01.23 15:29 Сейчас в теме
(27)
вы уже используете основную фишку git в своей работе, это обновление функции с директивой "изменение и контроль" в расширении на более новое содержимое, если подключить kdiff, то в принципе получится самый настоящий мердж.

Да, вы правы. Загнали меня в логический тупик.
Любой функционал по параллельной разработке, будь то CVS или более поздний и популярный сегодня Git, это всегда подспорье программисту и с этим не поспоришь.
Но поскольку мы работаем в России, с Российской программой 1С, имеющий свою специфику и свой вариант решения одновременного программирования, на мой взгляд, целесообразней использовать по максимуму внутренние средства 1С, и только когда вам станет "тесно", можно добавлять дополнительные затраты на внедрение дополнительных инструментов. Лично я не сторонник новых внедрений, только ради внедрений.

PS/ и не нужно принимать еще одно соглашение от MS, при установке vscode, где я согласен что они передают код в MS и я обязан выполнять их экспортную политику, включая санкционные ограничения.
33. karpik666 3665 19.01.23 15:46 Сейчас в теме
(32) вы меня тоже подловили, я не читал лицензионное соглашение:) в крайнем случае вы можете запретить vscode доступ в интернет, если не хотите утечки данных, я не предлагаю вам отказаться от хранилища, но попробовать новый функционал как дополнение - почему нет
dima_home; +1 Ответить
34. dima_home 194 19.01.23 15:50 Сейчас в теме
20. VSvintsov1 18.01.23 14:11 Сейчас в теме
(18) после такого развития событий с Git только самые смелые руководители ИТ в РФ будут строить долгосрочные планы в отношении Git и в целом ПО от Microsoft.
Git видимо "пробный шар"..
21. kuntashov 422 18.01.23 14:18 Сейчас в теме
(20) Вы путаете инструмент GIT и облачные сервисы а-ля GitHub.

Не так уж и много команд в продуктовой 1С-разработке используют именно облачный GitHub. Большинство в качестве сервера для управления репозиториями используют инструменты, которые можно поставить на свой сервер, да еще бесплатно. Чаще всего это GitLab CE. Также встречается Gitea или (реже) ее прямой родитель - китайский GOOGs.
karpik666; +1 Ответить
29. VSvintsov1 19.01.23 05:59 Сейчас в теме
(21) про облачные сервисы все ясно ). Я про надежность в целом при использовании всего бесплатного:
если западники решат что open-source на РФ не распространяется, то как руководитель ИТ будет оправдываться, что все стало колом? Мы экономили 3 копейки и ведь все долгое время работало... кто бы мог подумать...
____
я понимаю, что что доклад от 2021 года. И были дружба ... жвачка ... , про будущую безопасность никто особо не задумывался. Но на дворе 2023 год со всеми сложностями. Теперь в РФ есть "Реестр программного обеспечения" в котором нет нет голого open-source, но есть "Astra Linux" , и "Postgres Pro".
И есть "GitFlic". Видимо это и есть Git с сертификатом РФ - "Уязвимости отсутствуют". Но будет ли он работать так как в докладе?
Ждем новый доклад в 2025 году :)
22. siamagic 18.01.23 15:29 Сейчас в теме
(8) Гит пришел из систем где нет хранилища, сейчас школота лезет из всех щелей и тоже по поводу и без суют свою хайповую куйню куда следует и нет вообще не понимаю что куда и зачем.
dima_home; muskul; Brawler; +3 2 Ответить
38. triviumfan 37 23.01.23 09:43 Сейчас в теме
(8) Единственный стоящий комментарий. Даже и добавить нечего - тупо заткнул всех "гитоводов")
Пробовали edt + git - какое-то сумашествие.
41. karpik666 3665 24.01.23 20:29 Сейчас в теме
(38) я вот не понимаю, откуда такой негатив, обязательно тема про GIT должна включать, что "не нужон нам ваш GIT". Не считаю, что тот комментарий как-то затыкает людей, что используют git. Почему то, все пытаются противопоставить git и хранилище 1С, упуская, что их можно использовать в паре, и можно пользоваться плюсами и хранилища и git.
Про edt+git ничего не могу сказать. так как не пользовался, но знакомые говорили, что нет смысла, edt ты используешь ради плюшек, а не версионирования. так как там переключение между ветками требует обязательной актуализации конфигурации базы данных, а это значит, что каждое переключение может занимать от получаса и более, так что да, выглядит как сумасшествие.
Каждый инструментарий хорош в определенной ситуации, мое личное мнение, если ведется командная разработка на предприятии на упр формах, а не проект, то лучше GIT и полностью отказаться от хранилища, если же проектная работа, где есть разработчики с разным уровнем разработки, или небольшая команда разработчиков, то лучше хранилище, но git можно использовать чисто для себя, чтобы видеть весь цикл разработки и быстро сравнивать например с конфигурацией поставщика.
Прикрепленные файлы:
43. triviumfan 37 25.01.23 09:30 Сейчас в теме
(41) Андрей, любая тема про git превращается в "Ура! Я смог! Наконец-то оно взлетело..." и преодоление боли и сколько было палок в колёсах :)
PS: конечно, это похвально, что добился своих целей, а не бросил как большинство)
9. moolex 889 17.01.23 18:48 Сейчас в теме
Используйте ВнешниеКоманды, Внешний Регламент и Defy, и забудьте про Git как про страшный сон.
Разработка и сопровождение 1с будет вам в радость и сэкономите кучу денег и нервов.
44. triviumfan 37 25.01.23 09:33 Сейчас в теме
(9) А можно поподробнее? Можно хотя бы ссылками.
45. karpik666 3665 25.01.23 09:34 Сейчас в теме
(44) сайт гуглится по нику:)
46. moolex 889 25.01.23 22:03 Сейчас в теме
(44)
(44)
е? Можно хотя бы ссылками.

В моем профиле все ссылки и публикации
12. PerlAmutor 129 17.01.23 20:58 Сейчас в теме
Про дубли идентификаторов элементов форм забыли слово замолвить.
14. karpik666 3665 17.01.23 22:23 Сейчас в теме
(12) так там указано, что все доработки формы делаются программно, даже доработка формы через расширение. Поэтому не было под рукой подобного примера:)
dima_home; +1 Ответить
16. kembrik 3 18.01.23 10:03 Сейчас в теме
Но ведь ОченьВажныйДокументДляУчета не сamelCase, это PascalCase
17. karpik666 3665 18.01.23 11:05 Сейчас в теме
(16) ну вот, удивительно, даже не задумывался, что это может еще как-то называться по-другому:) хотя на вики, вроде эти понятия объединены https://ru.wikipedia.org/wiki/CamelCase
23. kembrik 3 18.01.23 16:09 Сейчас в теме
(17) Я не знаю как там в Wiki, честно) Есть Code Complete: A Practical Handbook of Software Construction от Steve McConnell - я ему доверяю полностью) И есть Naming conventions в том же JavaScript, где белым по черному (темная тема же ну) пишут что для переменных рекомендуется использовать сamelCase (без Upper и Lower), а вот PascalCase запрещают использовать в именах классов.

А по теме - статья отличная, но делать мы так пока не будем)
25. user1881120 18.01.23 18:08 Сейчас в теме
Лучше день потерять, зато потом за пять минут долететь. Надежность и качество - превыше скорости.
28. Dimel 18.01.23 23:18 Сейчас в теме
Забавно, всего несколько дней назад откопал в закромах обработку, которую ты делал для проекта ЕКШ, вспомнил добрым словом. И как раз интересует тема перехода на GIT...
30. karpik666 3665 19.01.23 07:21 Сейчас в теме
(28) Привет, забавное совпадение, хотя, надеюсь, с тех пор мой скил подрос, а то там оформление кода хромало :)
31. Поручик 4607 19.01.23 10:26 Сейчас в теме
По-моему, вчера смотрел на ютубе.
35. xrrg 290 19.01.23 21:56 Сейчас в теме
Андрюша, а где же импортозамещение?)
36. karpik666 3665 20.01.23 08:09 Сейчас в теме
(35) привет, так докладу уже 2 года, сейчас это далекое сытое прошлое, саму технологию вроде не запретили, пусть импортозамещение останется в госкомпаниях, коммерческое справляется пока с open source решениями, плюс у меня предыдущая компания до сих пор jira и bitbucket используют, просто не обновляют.
37. adapter 405 22.01.23 13:01 Сейчас в теме
@Karpik666

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

А что за скрипт? Ссылочкой поделитесь
native-api; +1 Ответить
40. karpik666 3665 24.01.23 20:12 Сейчас в теме
(37) Привет, вот относительная строка запуска "C:\Program Files (x86)\OneScript\bin\oscript.exe ПутьКСкрипту\load_changes.os -repo "Путь к репозиторию" -branch {cBranch} -srvname ИмяСервера -ibname ИмяБазы -usr ИмяПользователя -pwd ПарольПользователя -dpath КаталогСЛогом -fastupdate true -fromHash {sHash} -toHash {cHash} -loadchanges true -loadextension false -updatecfgdump true -syntaxctrl false -updatedb true -deploycfg false -deployext false" и скрипты во вложении.
Прикрепленные файлы:
скрипты.zip
39. zurapa 24.01.23 09:40 Сейчас в теме
Однако! Значит для работы с гитом обязательно надо поставить какое-нибудь гуёвое расширение, ибо в консоли сложно. А запоминать все эти нюансы в текстовичках херачить, скриптовать - это не сложно. Разработчики такой интересный народ - избирательно ленивые…
Мне кажется, если вы на столько выросли, что стандартная концепция разработки в 1С вас не устраивает и вы готовы вот на то, что описано в статье, вам пора менять язык программирования на более подходящий для этого. Этот вывод относится и к самой компании.

Статья -огонь! Сам люблю гит. Использовал его как средство ведения доработок индивидуально.
Не вижу смыла всё запихивать в него. Это больше средство фиксации изменений. И изменения нужно фиксировать только те, которые нужны разработчику. А не так, что загонять все, с изменениями портить то, что не должно было испортиться, скриптовать, разбираться.
Мне позволяло прекрасно получать пользу от гит использование его консольной версии без дополнений. Обработки, отчёты я загонял бинарником и отдельно текстом модули их. Всё это в процессе возникновения задач, доработок позволяло формировать картину происходящего, пробовать различные варианты решений, откатываться к нужному результату.
Но вот после такой статьи с подробным разбором реальных проблем, я точно не стану повторять ошибки андрюши и тащить это на весь проект, как средство внедрения.
42. karpik666 3665 24.01.23 20:47 Сейчас в теме
(39) можно и в консоли, но зачем? круг задач выполняемые с помощью git полностью покрывается интерфейсом, и для 1с-ника запоминать команды нет смысла, не в нашем стиле, консоль имхо нужна когда тебе уже не хватает интерфейса. По поводу скриптов, так их и не нужно запоминать и дорабатывать, конечный разработчик, должен это только использовать, и приходить на все готовое, с четко описанным инструкциям, и вроде концепция "под ключ" уже есть, только не описаны подводные камни. К git-у приходишь еще потому, что в одном пространстве невозможно версионировать внешние отчеты и обработки. расширения, конфигурацию, данные, которые хранятся в базе и возможно что-то еще, что было сделано по задаче, например те же самые ТЗ, если их как-то ставили в текстовом варианте.
Оставьте свое сообщение

См. также

Прокси хранилища 1С (IIS, OneScript) Промо

Групповая разработка (Git, хранилище) OneScript DevOps и автоматизация разработки Платформа 1С v8.3 Платформа 1С v8.3 Россия Россия Бесплатно (free) Бесплатно (free)

Избавляемся от версионной зависимости, проверяем комментарии, вызываем веб-хуки, делаем красивые пути. И все это на привычном IIS и понятном OneScript.

08.12.2022    4137    kamisov    19    

Что, если Continuous Integration – это прежде всего практика, а не набор инструментов?

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) Бесплатно (free) Бесплатно (free)

Рано или поздно многие компании приходят к практикам DevOps. И начало этому – Continuous Integration. О том, что происходит в команде специалистов 1С, когда они переходят на Git, и почему простое внедрение CI-инструментов не решает проблему подходов к разработке, в докладе на Infostart Event 2021 Post-Apocalypse рассказал руководитель компании ПрогТехБизнес Александр Анисков.

07.12.2022    1119    vandalsvq    0    

Управление хранилищами без боли

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) Бесплатно (free) Бесплатно (free)

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

28.11.2022    5683    Evil Beaver    8    

Технология доработки типовой конфигурации с использованием конфигуратора

Групповая разработка (Git, хранилище) Бесплатно (free) Бесплатно (free)

Как обычно происходит процесс доработки типовой? Разворачивается и используется рабочая база из какой-то типовой поставки 1С (БП/ERP/ЗУП и т.д.). Далее бизнес постоянно приносит требования по доработке типового функционала (отдельный вопрос, зачем это нужно). Возникает задача организовать постоянное изменение типовой конфигурации группой программистов. На мой взгляд, это довольно частая задача. Хотелось бы рассмотреть возможные варианты ее решения. Нигде не нашел упоминаний о подходах решения такой задачи, хотя, думаю, многие работают в таком режиме.

16.07.2022    1503    partizand    13    

Повышаем эффективность разработки правил обмена Промо

Групповая разработка (Git, хранилище) Обмен между базами 1C Платформа 1С v8.3 Платформа 1С v8.3 1С:Конвертация данных 1С:Конвертация данных Бесплатно (free) Бесплатно (free)

Как повысить скорость и качество разработки правил обмена? Как вести групповую разработку правил обмена? Как облегчить сопровождение правил обмена после передачи в эксплуатацию? Об этом и многом другом вы можете узнать из этой статьи.

25.06.2018    31887    olegtymko    49    

Отражаем хранилище в репозиторий git, Jenkins'ом

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Бесплатно (free) Бесплатно (free)

Описание приемов по настройке копирования хранилища 1С в репозиторий git. С помощью gitsync, под управлением Jenkins.

16.06.2022    1301    ImHunter    1    

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

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Бесплатно (free) Бесплатно (free)

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

08.06.2022    1247    curdate    10    

Скрипт перепривязки базы к хранилищу конфигурации

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Бесплатно (free) Бесплатно (free)

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

17.04.2022    1121    malikov_pro    0    

Стек технологий для 1С

Инструментарий разработчика Рефакторинг и качество кода Групповая разработка (Git, хранилище) Механизмы платформы 1С Бесплатно (free) Бесплатно (free)

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

29.11.2021    27542    mrXoxot    63    

Девопсы в 1С: микросервис распознавания штрихкодов

Групповая разработка (Git, хранилище) Бесплатно (free) Бесплатно (free)

Распознавание штрихкода из сканированного документа в PDF.

09.08.2021    2342    alexey_kurdyukov    8    

Принципы разветвленной доработки конфигурации, находящейся на поддержке, и ее расширений. Объединение веток разработки

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Бесплатно (free) Бесплатно (free)

Для чего нужно ветвление доработки типовой конфигурации? Как быть с расширениями? Как все это потом связать в одно целое?

02.06.2021    3417    Алексей Воробьев    2    

Как подключиться к хранилищу конфигурации на сервере за NAT, если есть доступ по RDP?

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Бесплатно (free) Бесплатно (free)

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

01.06.2021    3999    Dipod    13    

Мастер-класс: Реализация цикла CI/CD на практическом примере с использованием системы Тестер

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Бесплатно (free) Бесплатно (free)

На онлайн-митапе Инфостарта «DevOps в 1С» выступил Дмитрий Решитко – руководитель отдела разработки в компании C.T. Consultants Inc. Дмитрий провел мастер-класс, в котором продемонстрировал, как создавать новую функциональность в конфигурации с одновременным использованием инструмента тестирования и реализовать автоматизированное тестирование конфигурации при помещении кода в репозиторий на GitLab.

31.05.2021    2339    grumagargler    0    

Технология разветвленной разработки конфигураций 1С

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Бесплатно (free) Бесплатно (free)

Вся групповая разработка любой организации, где работает более 2-х программистов, в превосходящем большинстве случаев строится вокруг хранилища конфигурации. Те из нас, кто обращался к стандартам разработки 1С как минимум раз в жизни и читал их полностью (а может, и просто слышал от коллег), наверняка знают, что существует «Технология разветвленной разработки конфигураций» https://its.1c.ru/db/v8std#content:709:hdoc но не все поняли, как на самом деле эту замечательную вещь применять на практике, а кто-то понял и вероятнее всего думает, что «это к нам не относится, командная разработка по такой технологии в нашей организации не получится в силу определённых причин и потому применять её, к сожалению, я один не могу и не буду», до конца не разобравшись во всех аспектах, но это ошибочное мнение. В этой статье я постараюсь описать свой опыт, рассказать о преимуществах использования данной технологии, дать понять, что технология разветвленной разработки конфигураций на самом деле вещь индивидуальная и каждый для себя решает сам, применять её или нет, а также внести понимание, что у вас вообще нет никакой зависимости от своих коллег, работая в хранилище конфигурации при использовании этой технологии.

19.05.2021    9470    sinichenko_alex    45    

Ненавязчивая локальная разработка с traefik2, docker и letsencrypt

Групповая разработка (Git, хранилище) DevOps и автоматизация разработки Бесплатно (free) Бесплатно (free)

Перевод статьи по проксированию HTTP траффика до сервисов развернутых в docker контейнерах. Оригинал от 24.09.2020.

16.05.2021    4722    malikov_pro    0    

Хранилище значения. Заметки

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Бесплатно (free) Бесплатно (free)

Некоторые подробности про общеизвестный инструмент.

03.11.2020    24648    Yashazz    15    

Технология разветвлённой разработки, использующая git, ci/cd

Групповая разработка (Git, хранилище) 1С:Франчайзи, автоматизация бизнеса 1С:Франчайзи, автоматизация бизнеса Россия Россия Бесплатно (free) Бесплатно (free)

Адаптация и расширение требований к разветвлённой разработке с использованием git и ci/cd, основанное на стандартах 1С

24.02.2020    9145    check2    10    

GitSync 3.0. Шпаргалка по использованию

Групповая разработка (Git, хранилище) Бесплатно (free) Бесплатно (free)

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

26.11.2019    15605    VKislitsin    48    

Минимизация изменений в коде / Использование Хранилища общих настроек

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Конфигурации 1cv8 Конфигурации 1cv8 Бесплатно (free) Бесплатно (free)

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

14.11.2019    3426    biimmap    34    

Git для 1С-ника и другие технологии групповой разработки

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Конфигурации 1cv8 Конфигурации 1cv8 Россия Россия Бесплатно (free) Бесплатно (free)

У многих специалистов в отношении Git сложились стереотипы, мешающие начать работу с этим прекрасным и удобным инструментом. Почему его не стоит бояться, и чем он может упростить жизнь 1С-никам, рассказал архитектор ГК «Невада» Станислав Ганиев.

28.10.2019    16181    stas_ganiev    17    

Переход на разработку с хранением в Git, часть 1, подготовка репозитория

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Конфигурации 1cv8 Конфигурации 1cv8 Россия Россия Бесплатно (free) Бесплатно (free)

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

29.09.2019    10010    malikov_pro    14    

Отказ от использования хранилищ 1С, переход на Git.

Групповая разработка (Git, хранилище) Бесплатно (free) Бесплатно (free)

Валерий Максимов в своем докладе на конференции INFOSTART EVENT 2018 EDUCATION делится опытом перехода нескольких команд (более 100 разработчиков) от использования хранилищ 1С на системы контроля версий Git.

25.07.2019    24254    theshadowco    31    

Как начать работать с Git

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 1С:Франчайзи, автоматизация бизнеса 1С:Франчайзи, автоматизация бизнеса Россия Россия Бесплатно (free) Бесплатно (free)

Если Вы 1С программист, то обязательно наткнетесь на людей, рассказывающих о OScript, DevOps, EDT, SilverBulleters и так далее. Сейчас уже нельзя скрыться от этой информации. Так же было и со мной. В корне всего этого зоопарка лежит понимание и умение работать с Git (Распределённая система управления версиями). Укрупненной информации о ней много, Вы легко её нагуглите сами. В этой статье я старался собрать основные команды, определить их последовательность выполнения и привести краткий пример. Попробуйте выполнить все команды, и Вам станет проще разобраться с остальными программами. Удачи!

29.06.2019    10408    johnnyshut23    34    

Исправляем медленное выполнение операций с хранилищем конфигурации

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Конфигурации 1cv8 Конфигурации 1cv8 Бесплатно (free) Бесплатно (free)

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

26.05.2019    17626    tormozit    21    

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

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Бесплатно (free) Бесплатно (free)

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

28.03.2019    35359    ellavs    90    

Как писать понятные коммиты

Групповая разработка (Git, хранилище) Россия Россия Бесплатно (free) Бесплатно (free)

Как писать сообщения коммитов так, чтобы потом не было мучительно больно.

06.03.2019    15414    Scorpion4eg    35    

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

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Бесплатно (free) Бесплатно (free)

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

01.03.2019    89572    Смешной 1С    38    

Git + 1С. Часть 2. Реализация Git workflow в 1С-разработке по шагам

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Конфигурации 1cv8 Конфигурации 1cv8 Бесплатно (free) Бесплатно (free)

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

28.01.2019    38115    stas_ganiev    32    

Еще раз про хранилище, или проблемы, с которыми мы столкнулись на практике

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Конфигурации 1cv8 Конфигурации 1cv8 Россия Россия Бесплатно (free) Бесплатно (free)

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

25.01.2019    3461    Lucifer93    2    

Git + 1С. Часть 1. Как подключиться к команде разработки и начать использовать Git

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Конфигурации 1cv8 Конфигурации 1cv8 Бесплатно (free) Бесплатно (free)

Первая статья из цикла инструкций по работе с Git в 1С-разработке. Рассмотрим, как настроить рабочее место, как получить свою "копию" проекта для разработки и приступить к полезным действиям. Все примеры будут изложены в рамках трёх практических кейсов: 1. Моя команда дорабатывает типовую конфигурацию, использует приватный репозиторий на BitBucket, в котором версионируются внешние отчеты/обработки, расширения конфигураций и правила обмена; 2. Я участвую в стартап-команде, которая разрабатывает свою конфигурацию с использованием Git и GitLab; 3. Я принимаю участие в развитии OpenSource-продукта на GitHub как заинтересованный разработчик (контрибьютор).

18.10.2018    137217    stas_ganiev    89    

Одновременное использование хранилища и расширений

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Бесплатно (free) Бесплатно (free)

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

23.08.2018    15130    shaa2    3    

Версионирование правил обмена в Git

Групповая разработка (Git, хранилище) Бесплатно (free) Бесплатно (free)

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

15.12.2017    16736    bforce    22    

Групповая разработка конфигураций в крупном холдинге

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Бесплатно (free) Бесплатно (free)

О чем мы сегодня поговорим? • О становлении и развитии групповой разработки конфигураций 1С в крупном холдинге с использованием хранилища конфигураций. • Обсудим практически все аспекты использования хранилища в командной разработке. • Я расскажу про те методы и идеи, которые мы пробовали использовать, какие используем до сих пор, от каких отказались и почему.

15.08.2017    26010    stas_ganiev    17    

Поиск несериализуемых значений при помещении в хранилище

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Бесплатно (free) Бесплатно (free)

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

02.03.2016    26933    balanton    2    

Работа с хранилищем конфигураций из командной строки

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Бесплатно (free) Бесплатно (free)

Данное изложение на примерах демонстрирует работу с хранилищем конфигураций из пакетного режима

22.04.2014    20204    Franco    12    

Коллективная разработка на 1С версии 7.7 и Git

Групповая разработка (Git, хранилище) Платформа 1С v7.7 Платформа 1С v7.7 Россия Россия Бесплатно (free) Бесплатно (free)

В данной статье я не буду рассматривать работу с системой контроля версий Git, для этого есть специальные ресурсы, например http://git-scm.com/book/ru. Я только расскажу тем, кто привык и любит Git, подружить старую добрую 7-ку и систему контроля версий Git.

17.09.2013    18744    s.nek    12    

Хранилище конфигурации: не очевидные особенности групповой разработки

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Платформа 1С v8.3 Конфигурации 1cv8 Конфигурации 1cv8 Бесплатно (free) Бесплатно (free)

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

03.06.2013    46668    _also    33