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

25.07.19

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

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

 

Расскажу немного о нашей компании. Мы являемся бизнес-интегратором, уже более 10 лет занимаемся разработкой различных программных продуктов для крупного бизнеса. У нас большое количество крутых специалистов в разных областях, с некоторыми из которых вы знакомы по секции Highload.
 

 

Я собираюсь рассказать про процесс перехода наших команд с использования хранилищ 1С на системы контроля версий Git:

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

 

Что было в 1С разработке, почему мы решили меняться?

 

 

Итак, что у нас было в самом начале.
Как и у всех организаций, разрабатывающих решения на платформе 1С, их было некоторое количество. Числа я привел здесь для сравнения, чтобы потом просто было видно, как они меняются. Будем считать, что на старте было более 20 разнородных решений. Это были не информационные системы, а именно конфигурации.
Было большое количество разработчиков. Как опытных, так и стажеров, молодых специалистов. Почему я их здесь выделил? Потому что они, как ни странно, были одним из двигателей прогресса. С более опытными было гораздо сложнее работать, сложнее поменять мировоззрение с классического подхода на новый. 

 

 

Что было еще? У нас при активной разработке начались постоянные проблемы с хранилищем, такие как:

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

 

Далее, проблемы при самой разработке, также всем прекрасно известные:

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

 

Код-ревью не проводился. Понять, кто и зачем это сделал, было невозможно. 
Из-за того, что объекты постоянно были заблокированы, качество решений начало активно страдать. Нередко возникали просьбы: «Дай, пожалуйста, мне объект на 15 минут, я сейчас прогружу, оно точно ни на что не повлияет, обещаю». А потом это приводило к различным проблемам и разборкам, кто виноват и почему.

 

 


Но кроме 1С в нашей компании был еще и соседний параллельный мир – большое количество разработчиков, использующих прикладные веб-технологии и прочие вещи. У них было счастье – CI/CD, Git, интеграция с различными системами «из коробки». Про виртуализацию и контейнеризацию я вообще молчу. Это просто какие-то чудеса. 
А мы жили в каменном веке – грустно, печально. И мы решили что-то поменять.

 

Основные этапы перехода.

 

 

Просто так дернуть рубильник, и перейти на Git или на Mercurial, который тоже рассматривался, мы не решились. Нужно было сначала немного подготовиться.
Мы решили, что всех сразу переводить не будем – сначала возьмем пилотную команду, пилотный проект и попробуем поэкспериментировать, посмотреть, что произойдет.
Выбрали варианты, которые будем рассматривать. Были варианты с пачкой хранилищ и переносами между ними – релизными и нерелизными. Хранилище с GIT, с Mercurial, и просто Git.
И начали пробовать эти варианты – осторожно, с болью. 
Часть вариантов отметалась достаточно быстро. В частности, вариант с массой хранилищ и связка хранилища с Git, так как эти решения приводили к еще большему количеству проблем.

 

 

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

 

 

Все работает... Почти все… Почти всегда… За исключением некоторых ситуаций. В общем, все хорошо, жить можно.
 

 

Что для этого нужно? Для того, чтобы заняться этим процессом, нужно все это подготовить. Неподготовленного человека окунуть в этот процесс – это боль, отторжение, непонимание – зачем, почему, что мне делать.
Потому что инструменты, которые используются в этом процессе, чужеродны для основной массы разработчиков 1С. Они про них даже не знают. Поэтому нужно подготовить docker, рассказать, как это работает и, желательно, людей научить – предоставить им соответствующие материалы.
Так как появляется куча дополнительных действий, лучше эти действия все-таки автоматизировать. Потому что программист – существо ленивое. Если его заставлять что-то делать руками, он будет это саботировать. Поэтому нужно добиться, чтобы какие-то операции перестали требовать его сил и времени. По сути, получилось комплексно. 
И после этого можно внедрять.

 

 

Таким образом, начался очередной этап подготовки – подготовка к внедрению. Я уже говорил – так как нужно автоматизировать часть операций и сохранить связь с предыдущими наработками, которые все-таки велись многие годы, то мы подняли в качестве CI-сервера Jenkins, подняли на нем задачки для переноса изменений из хранилищ 1С в соответствующие им репозитории Git.
И между делом настроили задачи по сборке из исходников конфигурации и выполнению тестов. Это как раз то преимущество, которое мы предоставили разработчикам – то, что не нужно cf-ники собирать, тестировать вручную – оно само работает. Достаточно закоммитить, отправить, и дальше оно само.

 

 

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

  • в ветке master находятся релизы;
  • в feature-ветках ведется разработка;
  • после тестирования feature-ветка закрывается, попадает в develop (по сути, ночная сборка из нее собирается);
  • потом запускается процесс выпуска релиза, и, если все хорошо, изменения приходят в ветку master;
  • ветка master накатывается на Production, если так настроено. Если не настроено, то выпускается инсталлятор с необходимыми файлами, которые мы отдаем админам для разворачивания на Production.

 

Дальше мы подготовили саму документацию и курс обучения, который мы сделали Step by Step.
Наша компания распределена по стране, ее филиалы находятся в разных городах. И провести очное обучение – это долго, дорого и бессмысленно. 

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

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

 

 

Следующим этапом было проведение семинаров и рассказ о том, как же это все будет работать.
Для большинства все это казалось «китайской грамотой» - что-то нарисовано, и мы говорим: «Оно работает». Кто-то верил, кто-то не очень.

 

 

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

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

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

 

 

Самые основные моменты, которыми они поделились:

  • Это то, что теперь отсутствуют проблемы с захваченными объектами, никто никому не мешает, разрабатывай сколько хочешь. 
  • Не требуется помещать непроверенный код. 
  • Для редактирования конфигурации можно использовать свой любимый редактор – VSC, IDEA, vim, Notepad++ – кому что нравится. Потому что в большинстве случаев разработка связана именно с доработкой функциональности и разработкой методов в модулях.

 

Запускаем процесс внедрения. Берем всех разработчиков, делим на потоки, переводим все проекты на платформе 8.3 с управляемым интерфейсом в Git, переносим все изменения, указанной командой архивируем все хранилища, чтобы обратной дороги не было. И, «полетели».
Все было хорошо. Процесс перехода всех команд на новую схему разработки в общей сложности занял где-то порядка 3-х месяцев.

Что получилось в итоге?

 

После того, как прошло какое-то время и прошел процесс адаптации, мы подвели некоторые итоги:

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

 

В итоге – ура, мы все сделали, все классно. Сейчас вы все, наверное, думаете, что все это – чудеса, так не бывает, что никаких проблем нет. 

 

 

Действительно, не все так хорошо. Есть некоторый набор проблем. Я выбрал ключевые, и сейчас по ним пробегусь.

 

 

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

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

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

Версия используемой платформы должна быть не ниже 8.3.10 – там решены многие проблемы с экспортом данных в файлы. И, опять же, это минимальная версия платформы, с которой работает EDT в наиболее стабильном режиме.

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

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

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

Интересное следствие – это повышение стоимости таких разработчиков на рынке. Можете посмотреть на HeadHunter, там сейчас уже много вакансий, где для 1С-разработчиков указаны требования по владению технологиями работы с Git, с тестами и т.д. Если вы хотите, чтобы ваши разработчики об этом не узнали, единственный вариант – отбирайте паспорта, отключайте интернет и т.д. Других вариантов нет.

 

Что делаем сейчас, куда движемся?

 

 

Небольшое хвастовство: 

  • Мы продвигаем развитие CI/CD. Очень много контрибьютить в OpenSource не получается, но все-таки, немного в сообщество мы возвращаем.
  • Продолжаем развивать процесс автотестирования и инструментарий разработчиков.
  • У нас есть несколько вариантов, с помощью которых мы все-таки планируем «затянуть» конфигурации на обычных формах в Git.

 

Резюме.

 

 

  1. Не стоит бояться этой схемы. Надеюсь, мой рассказ помог кому-нибудь сдвинуться с места. Но вы должны понимать, что нужно развиваться. 
  2. Быть первым в этом процессе, как и в любом другом, всегда сложно. 
  3. Нельзя просто заставить людей что-то сделать. Это не работает. Нужно именно провести процесс внедрения. Комплексно: тестирование, обучение, опытная эксплуатация, релиз. По-другому никак.
  4. И, самое главное, верить в себя.

 

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

  • сообщество OneScript;
  • команда, развивающая sonarqube;
  • Visual Studio Code;
  • Allure;
  • GitLab;
  • Atlassian;
  • и коллеги из команды «Серебряная пуля», генераторы идей и некоторых инструментов.

 

Вопросы:

А как вы все-таки решаете вопросы с объединением форм, когда они рушатся?

Первое: если вы используете EDT, не используйте его возможности работы с Git. Второе: мы уже достаточно неплохо разобрались со структурой, знаем ключевые моменты. Поэтому – распределение задач. Если мы понимаем, что с одним объектом будет работать несколько человек, то мерж проводится с дополнительным контролем, когда человек выполняет закрытие фичи, ему прилетает изменение из dev, инструменты Git позволяют показать изменения и показать конфликты. Конфликты правятся в kDiff с включением интеллекта и использованием некоторых скриптов на OneScript. Есть интересная утилита для мержа XML от компании Oxygen, только она очень дорого стоит.


Речь идет не о типовых конфигурациях? Потому что я знаю, что в EDT нельзя снимать с поддержки и т.д.


По поводу поддержки – пример с типовыми конфигурациями. У меня есть ветка в репозитории, которая называется HRM, и там лежит поставка от вендора. А в корне проекта у меня лежит .gitattribute, в котором написано, что 
parentconfiguration.bin merge=ours
То есть, я его не переношу из этой ветки. Когда мне нужно обновить типовую, я ее обновляю из соответствующей ветки, потом переношу эти изменения в основной ствол, а там у меня версия без поставки. И я продолжаю разрабатывать. Потому что я не лезу в объекты, которые на поставке. А для типовых – берите расширения, они отлично работают. С небольшими хаками они вообще хорошо работают.


Почему именно Git, а не Mercurial и не Bazaar?


У Mercurial проблемы с длинными именами и русским языком. Питонисты ничего про русский язык не знают, для них код и файлы не должны быть на русском. А по поводу Bazaar – чтобы проверить, возьмите ERP, откройте конфигуратор, выгрузите в файлы и попробуйте закоммитить 5,5 миллионов строк в Git и в Bazaar. И посмотрите, кто из них первый рухнет. Git выдерживает. Все остальное – нет.


Есть ли какие-то советы по оттачиванию этого навыка мержа, потому что вы озвучили пример форм, а там еще есть роли, общие реквизиты и прочее. Мы пользуемся Git, но мержить в голом виде какие-то сложные изменения – это что-то невероятное. А этот вопрос вообще нигде практически не затронут.


Во-первых, у вас никто не отбирал конфигуратор. Если у вас проблемы с мержем в Git, вы можете воспользоваться конфигуратором и средствами сравнения-объединения, привычными вам. Это – первый вариант. Второе – есть скриптинг. У всех XML-файлов вполне понятная структура, которая неплохо разбирается. И здесь можно использовать самописные мерж-хуки Git под формат роли, чтобы выполнять их объединение по структуре. Подобная ситуация есть у коллег из сообщества C# - они тоже мержат XML-файлы при слиянии проектов. Можно по аналогии сделать и для 1С-ных файлов. Нормальных, всеядных утилит для объединения XML, к сожалению, нет.

Когда вы вносите изменения, вы же понимаете, какие изменения вы вносите. Если вы роли не трогали, а они у вас изменились – а они изменяются, если у вас стоит автоматическое назначение прав и т.д. Соответственно, это вполне прогнозируемая ситуация. При объединении с другой ветвью, вы можете посмотреть, какие изменения были внесены другим разработчиком и просто перенести эти изменения к себе. Есть такая вещь, как cherry-pick, можно забрать коммит разработчика, связанный с этой ролью, в свою ветку. 

А все-таки, вы разработку ведете именно в конфигураторе, а потом выгружаете это все в файлы и в Git, или непосредственно, в EDT?
И так, и так. Сейчас в приоритете разработка через конфигуратор, а EDT мы пока что активно тестируем. Там есть набор нюансов. У нас, допустим, на данный момент проблема в том, что часть конфигураций работает под интерфейсом 8.2, а EDT умеет работать только под «такси». Вторая глобальная проблема – EDT не умеет работать с внешними источниками данных, он их определяет, как undefined, тут без конфигуратора никак. Но в ближайшее время, как только в EDT еще некоторые баги поправят, мы планируем полностью перейти на него.

 

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2018 EDUCATION.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

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

Подробнее о конференции.

 


См. также

Системы контроля версий для 1С-разработчиков.

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Платформа 1С v8.3 Платные (руб)

Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8

4900 руб.

29.06.2022    9138    78    4    

110

Особенности национального Workflow: Github Actions и OneScript

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

Сегодня мы посмотрим на Github Actions - встроенный инструментарий Github для автоматизации рабочих процессов. Разберем, что это такое, зачем и причем тут OneScript.

25.03.2024    1153    bayselonarrend    3    

35

Автоматизация процесса разработки с помощью сервиса GitFlic

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

GitFlic – первая в России полностью самостоятельная реализация сервиса для хранения репозиториев с исходным кодом. За три года разработки сервис GitFlic стал полноценным инструментом, которым можно заменить GitLab, GitHub и BitBucket. Расскажем о том, как выстроить в GitFlic процесс автоматического тестирования, статического анализа кода и сборки приложений.

05.03.2024    1862    user1989937    6    

15

OpenYellow - рейтинг открытых GitHub репозиториев для платформы 1С:Предприятие

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

Обновляемый топ GitHub репозиториев для 1С по всем языкам программирования и еще немного рассуждений про open-source.

05.02.2024    3779    bayselonarrend    15    

61

Насколько глубок 1С-ный GitHub?

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

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

22.01.2024    7839    bayselonarrend    50    

86

TCP прокси-сервер хранилища конфигурации 1С

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

Продолжение истории с прокси хранилища, но уже не на HTTP, а на TCP и без падений по памяти веб-сервера. Проверяем комментарии хранилища, вызываем веб-хуки, старты пайплайнов, gitsync по событию помещения версии в хранилище. И все это полностью на знакомом и понятном OneScript.

17.01.2024    2771    kamisov    17    

57

Отдай корень! Библиотека OneScript для получения информации о захваченных объектах в хранилище

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

Хранилище конфигурации 1С - это инструмент групповой разработки. Работают с хранилищем следующим образом: захватывают какой-либо объект, редактируют, потом отдают его в хранилище. Хранилище помечает уже захваченные объекты и не дает возможности захватить их другим пользователям. Это рождает и самый большой недостаток хранилища - невозможность работы с одним объектом нескольких пользователей, например в случае доработки разных методов в одном большом модуле. Корень конфигурации - это самый верхний ее узел. Только захватив корень, мы можем добавить в конфигурацию новые общие модули, документы, справочники, регистры и подобное. Только захватив корень можно изменить настройки поддержки конфигурации. Соответственно, если корень захвачен одним программистом, другой программист не может добавить новые объекты или снять что-то с поддержки. Потому то и всплывает эта фраза - отдай корень, мне нужно тоже что-то добавить.

26.12.2023    1336    ardn    1    

26

Git Code Review - инструмент для рецензирования кода

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Конфигурации 1cv8 1С:ERP Управление предприятием 2 Абонемент ($m)

Git Code Review - инструмент, позволяющий быстро анализировать изменения из git-репозитория прямо в 1С

1 стартмани

20.12.2023    3951    59    salexdv    26    

81
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Drfreeman 135 25.07.19 11:20 Сейчас в теме
"Для редактирования конфигурации можно использовать свой любимый редактор – VSC, IDEA, vim, Notepad++"... ой не знаю. А отладку как вести? Я часто пишу код прямо в отладке, так наглядно видно с чем работаешь.
EvgeTrofi; Andreeei; sansys; +3 Ответить
2. theshadowco 238 25.07.19 11:22 Сейчас в теме
(1) Отладку можно вести и в VSC.

По прошествии года могу сказать, что для работы EDT неплохо подходит.
3. frkbvfnjh 785 25.07.19 11:52 Сейчас в теме
Хорошая попытка, но нет... Сколько лет с хранилищем работаем и чёт не было проблем, наверное я не работал в команде из 100 человек. Вы там чё, операционку на 1С пишите что ли?
maksa2005; EvgeTrofi; sansys; user774630; Vovan1975; oleg974; omut; AllexSoft; Йожкин Кот; manlak; noprogrammer; +11 1 Ответить
4. theshadowco 238 25.07.19 11:59 Сейчас в теме
(3) Команд несколько по 5-25 человек, в зависимости от проекта
7. Waanneek 97 25.07.19 14:24 Сейчас в теме
(3)
Сколько лет с хранилищем работаем и чёт не было проблем, наверное я не работал в команде из 100 человек


Вы точно работаете с хранилищем 1с ? =)

Постоянно проблемы:
1) Примерно за год хранилище до ходит до предельного размера и если во время на срезать - рушится (около 1,5 тыс коммитов потом ломается) и это пожалуй самое безобидное.
2) Не редки глюки с КЭШем и подключением, зависают ранее подключеные пользователи, хотя конфигуратор уже закрыт давно
3) на 12х или 13 версиях платформы был глюк с помещением в хранилище - изменения были видны в конфигураторе но не помещались в хранилище и если продобать эти изменения в конфигураторе в котором велась разработка, то делай заного по памяти, когда обнаружится что в хранилище коммита нет.
4) Не применялись к ИБ, в конфигураторе код виден, к базе не применяется (глюки кэша)...

и все это при совместной разработке от 2 до 4х разработчиков на одно хранилище.
eden_gmail; izidakg; +2 Ответить
8. pbabincev 132 25.07.19 21:43 Сейчас в теме
(7)
Наш опыт на одном проекте:
3 года активного развития продукта, около 10 разработчиков, все в одном хрнилище (коммиты не считали)
Ни одной проблемы
Переезжали на новый сервер, хранилище переносили прежнее без обрезания.
НО мы использовали только Сервер хранилища tcp, может поэтому всё было очень стабильно.
В общем, проблем никаких при использовании хранилища мы не видели.
13. Xershi 1474 27.07.19 23:50 Сейчас в теме
(7) 1. Предельный размер это какой? Версия хранилища последняя?
2. Криво вышли, зайти еще раз и выйти, ну или чистить нулевые файлы.
3 и 4 это скорее кривая разработка, сначала нужно получать объекты, а только потом захватывать, некоторые думают что 1С всегда при захвате отработает как надо!
5. acanta 25.07.19 12:27 Сейчас в теме
Можно попросить картинки уменьшить немного, на планшете долго загружается.
6. Fox-trot 156 25.07.19 12:38 Сейчас в теме
(5) они никак к теме не относятся, не парься
for_sale; +1 Ответить
9. ellavs 1022 26.07.19 08:14 Сейчас в теме
если вы используете EDT, не используйте его возможности работы с Git

Поясните, пожалуйста, этот момент. Почему рекомендуете не использовать?
Сама работаю с EDT около полугода и тоже не использую его встроенный GIT (но у меня причина вполне банальная - использую git-репозиторий VisualStudioOnline, а там аутентификация по учетной записи от MS не стыкуется с EDT, нужно заморачиваться, чтобы настроить через ключи доступа, поэтому вместо встроенного механизма использую TortoiseGit).
10. theshadowco 238 26.07.19 10:09 Сейчас в теме
(9) В ранних версиях EDT была масса проблем и, откровенно, было неудобно использовать.

В последних версиях (с 1.10) стало гораздо лучше, но по привычке у себя продолжаем испольовать сторонние решения для взимодействия - консоль + gitextensions. Как минимум, не готовы использовать встроенные средства по причине отсутствия поддержки gitflow, а плагин для eclipce в EDT работает не стабильно.
11. for_sale 971 26.07.19 18:05 Сейчас в теме
Очередная статья из серии "Смотрите, как мы умеем!". Думал, будут какие-то инструкции, делёж опыта, картинки. А оказалось - презентация и "верьте в себя, у вас всё получится, гугл в помощь".
ZOMI; retr0; Drivingblind; agent00mouse; Andreeei; user774630; +6 Ответить
12. theshadowco 238 27.07.19 07:25 Сейчас в теме
(11) Анатолий, мне жаль, что вы потратили время, читая эту статью, что вы не нашли в ней ничего интересного для себя.
14. Xershi 1474 27.07.19 23:51 Сейчас в теме
(12) самое вкусное зажали)))
Или ждать в ближайшее время?
17. theshadowco 238 29.07.19 09:09 Сейчас в теме
(14) Какие "вкусности" вы ожидали? Возможно, найду время для публикации.
20. Xershi 1474 29.07.19 10:41 Сейчас в теме
(17) обучающие видео.
Набор скриптов и технические рекомендации.
BaphoBush; Cmapnep; acanta; Fox-trot; theshadowco; +5 Ответить
15. omut 28.07.19 15:31 Сейчас в теме
Не верю в гит и ему подобное до тех пор, пока обычные текстовые файлы не станут исходниками конфигурации по умолчанию. До тех пор, пока существует все эти "выгрузить в файлы" и обратно ничего путного придумать не получится. И все преимущества гит продолжат болтаться одних весах с временем выгрузки-загрузки. Среда разработки должна поддерживать гит нативно или - как минимум - файлы проекта должны поддерживаться гитом нативно. Все остальное жуткое извращение. Хранилище глючит иногда. Но выигрыш от перехода на гит в 99% случаев не оправдает затрат и усложнений. Пробовал подключать к редмайну в связке с сабвершн, с гит. Выгружать файлы... Это кошмар разработчика. Есть места, где все расписано по минутам, где коммиты делаются как-то ночью что ли. Где не нужно вдруг срочно залить обновление и что-то еще поделав вложить свои доделки... Вот там, в местах неторопливого вдумчивого разработчика это все в состоянии выжить. Но не в реальном мире багов, дэдлайнов, живых людей.
16. theshadowco 238 29.07.19 05:49 Сейчас в теме
(15)посмотрите в сторону EDT, там как раз одни исходники и ничего более
18. omut 29.07.19 09:22 Сейчас в теме
(16) обычные формы? В целом проект чудной. Может он стал нормальным по функционалу и полностью заменяет конфигуратор?
19. theshadowco 238 29.07.19 09:42 Сейчас в теме
(18)
Пока полностью во всех случаях не заменяет.
Если проект не использует обычные формы, не находится на поддержке, то конфигуратор не нужен.
21. omut 29.07.19 11:47 Сейчас в теме
(19) Об этом и написал выше. В этом и причина. По совокупности факторов выходит, что нужен конфигуратор. Отсюда вытекает работа с хранилищем. На самом деле, 1С не помешало бы отказаться от хитроумных форматов хранения конфигурации и перейти к человечьим исходникам. И вот с этого момента мы станем полноценными пользователями систем управления версиями :-) Штука очень нужная. Реально не хватает гита или сабвершна. Особенно во время групповой разработки.
BaphoBush; Ozulon; Fox-trot; +3 Ответить
22. acanta 29.07.19 11:52 Сейчас в теме
(21) Как по вашему, такой ресурс как инфостарт( или миста например, если про нее еще не забыли, или ресурс Гилева) в том виде как сейчас, потянет нечто вроде гита? Сколько это может стоить? Сколько может потребовать времени?
Сколько например вы как предприятие-разработчик ПО готовы платить дополнительно за такой сервис из коробки от 1С?
Как по вашему, должна быть организована регистрация пользователей в личных кабинетах 1С для того, чтобы появилась возможность создания сервиса, подобного гиту?
Сколько таких как вы может быть сразу и сколько разработчиков перейдет на сервис в результате реализации данного пожелания, если гит уже есть, и тех, кто в нем работает все устраивает?
Напоминаю, что в 8ке было принято осознанное маркетинговое решение - работать без внешних исходников конфигурации. Почему вы считаете, что оно было ошибочным?
23. Fox-trot 156 29.07.19 12:09 Сейчас в теме
(22) потому как все сделано по аналогии например с фокспро. где сейчас фокспро знаешь?
24. acanta 29.07.19 12:11 Сейчас в теме
(23) А как же, похоронено под грудой потомков и последователей.
Например клиппер компилируемый, в отличие от фокса, работали они оба с одними и теми же DBF.
25. omut 29.07.19 13:59 Сейчас в теме
Коллега вам уже ответил. Аналогия с фокспро верная. Могу только присоединиться. Было ли ошибочным? На мой взгляд: да. В принципе, конфигуратор вполне устраивает. И с этой точки зрения вроде как все нормально. И хранилище устраивает. Кроме тех случаев, когда возникает необходимость организовать ветвление. Ну вот захотелось замутить какое-то альтернативное направление развития, делать много, долго. Не известно что и как в результате выйдет и понадобится ли. А конфигурация на поддержке и постоянно обновляется. Вот было бы неплохо сделать ветку и в ней мутить свои задумки. А параллельно в основной ветке делать текущие обновления. Сейчас для этого приходится делать отдельную конфигурацию...
Но все же идеальная ситуация: конфигурация = проект. Исходники текстовые (может файлы ресурсов еще). И управление версиями какое захотим.
26. Darklight 32 30.07.19 14:53 Сейчас в теме
было
Из-за того, что объекты постоянно были заблокированы, качество решений начало активно страдать. Нередко возникали просьбы: «Дай, пожалуйста, мне объект на 15 минут, я сейчас прогружу, оно точно ни на что не повлияет, обещаю». А потом это приводило к различным проблемам и разборкам, кто виноват и почему.


стало

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

Теперь качество решения страдает из-за неправильных или зятянувшихся сложных мерджей xml файлов

То есть раньше - очередь выстраивалась через блокировку в процессе работы - хоть и всё равно "очередь" - тут это понятие условное
То теперь отдельному человеку(ам) нужно выстраивать эту очередь вручную, на этапе постановки задач - ИМХО "заменили шило на мыло"!

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

Но ведь есть xml ещё и в метаданных. И если через 1С хранилище, скажем, можно было захватывать реквизиты по отдельности - то через GIT - мерджить придётся весь объект
BaphoBush; 7OH; +2 Ответить
29. theshadowco 238 31.07.19 07:50 Сейчас в теме
(26) Напомните пожалуйста, с какой версии можно захватывать реквизиты объекта по отдельности. Много лет не пользуюсь хранилищем и пропустил эту возможность.

Что значит "придется мержить весь объект"?
Объект в исходниках представляет собой набор файлов, содержащих как описание самого объекта, его некоторых частей (таких как формы, макеты и т.д.), а также модули с кодом. В зависимости от того, что было изменено в IDE, изменится часть соотвествующего файла. Если вы уйдете от схемы "я неделю/месяц/год попилю, а потом зафиксирую изменения в scm", а будете фиксировать изменения чаще, то и объединение будет гораздо понятнее. Это как с оновлением типовой для допиленной своей - можно накатить релизы друг за другом, наблюдая процесс изменения, а можно пропустить десяток и потом разом, мужественно накатывать последний, пытаясь догадаться куда делся любимый доработанный объект.
AKnyazkov; +1 Ответить
31. Darklight 32 31.07.19 09:19 Сейчас в теме
(29)

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

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


Что значит "придется мержить весь объект"?


Имелась ввиду структура метаданных (понимая, что внутренняя структура некоторые метаданных - ака форм или макетов - вынесена в отдельные файлы)
AKnyazkov; +1 Ответить
30. theshadowco 238 31.07.19 07:57 Сейчас в теме
(26)
Теперь качество решения страдает из-за неправильных или зятянувшихся сложных мерджей xml файлов


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

Дальше мы подготовили саму документацию и курс обучения, который мы сделали Step by Step.
27. 7OH 69 30.07.19 16:59 Сейчас в теме
Верю, что существуют фирмы, где выделят ещё одного(или более человек) - которые все эти изменения будут вручную собирать потом (особенно формы).
При этом у этих людей будет абсолютное понятие ЧТО было сделано и ДЛЯ ЧЕГО.
С трудом представляю, как потом человек садится хотя бы раз в неделю и пытается собрать в одно целое пачки коммитов от каждого программиста.
Пока что даже при количестве 20 человек - как бы убого хранилище не работало, но в реалиях когда бизнес процесс нарисовать это что-то из рода фантастики - удобнее нету.
28. theshadowco 238 31.07.19 07:38 Сейчас в теме
(27) У нас нет таких людей, если вы предположили такое. Честно говоря даж не представлю, как его назвать, такого специалиста: "разборщик конфликтов", "merge-man", "ведущий объединятор"?

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

Как гласит народная мудрость "Не так страшен черт, как его малюют".
AKnyazkov; +1 Ответить
32. ZOMI 444 09.03.23 16:41 Сейчас в теме
(1) Какой процент разработчиков во время внедрения и плюс 2-3 месяца покинул компанию по "собственному" ?
33. theshadowco 238 14.03.23 10:51 Сейчас в теме
Оставьте свое сообщение