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

Публикация № 1146242 28.10.19

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

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

Немного о личном

ГК «Невада» занимается дистрибьюцией, оптово-розничной торговлей. У нас сеть гипермаркетов и сеть минимаркетов по всему Дальнему Востоку.

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

С чего все начиналось

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

Но чуть раньше, еще в августе 2014 года, всеми нами уважаемый Алексей Лустин проводил вебинар на тему «Git-flow в 1С». Кто-нибудь видел этот вебинар? А кто уже перешел на Git, вообще пользуется им? А есть такие, кто еще думает переходить на Git? Или может быть только-только начал? Отлично, это я удачно зашёл.

Почему не взлетело

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

В ходе своего доклада я постараюсь развеять эти сомнения.

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

Для начала рассмотрим, что такое система контроля версий. Не все еще начали ею пользоваться. Это некое мероприятие или комплекс мероприятий, который позволяет нам ответить на следующие вопросы:

  • что и когда менялось;

  • кем менялось;

  • с какой целью.

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

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

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

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

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

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

Преимущества распределенной системы контроля версий Git

В чем прелесть распределенной системы контроля версий, коей как раз является Git?

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

Но в чем прелесть Git? Работать можно локально и не обязательно иметь постоянное подключение к сети Интернет. Даже если вы улетите в космос, вы можете продолжать коммитить на своём ноутбуке. А вернувшись на землю, подключиться к интернету, синхронизироваться с сервером и радоваться актуальной версии вашего проекта.

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

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

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

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

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

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

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

Говоря о преимуществах Git, мы возвращаемся немного в историю его происхождения. Когда Линус Торвальдс в 2005 году дал задачу разработать систему контроля версий, ключевыми требованиями были:

  • производительность;

  • возможность работы большого количества разработчиков (больше тысячи разработчиков);

  • высокая скорость работы.

Все эти цели были достигнуты. 

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

Ветвление разработки. В хранилище мы знаем, что коммиты у нас происходят строго линейно, и когда мы собираем релиз, то выколупать доработки определенных задач или подзадач становится проблематично. У нас был такой инцидент, когда в нашей основной товаро-учетной системе накопилось очень много ошибок. На их устранение подключили целую армию программистов. Было очень много фиксаций в хранилище конфигураций, и мы зашли в тупик с вопросом: «А что же делать со всеми этими задачами? Кто их будет тестировать? Армии тестировщиков нет!». 

Решили, что надо их как-то ранжировать по приоритетам, протестировать немного в другой последовательности, нежели они были закоммичены в разработку, и пустить в релиз. Как это сделать с хранилищем? Никак! 

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

Другое дело, когда мы говорим о работе с Git. 

Я не зря на предыдущем слайде показал именно этот фрагмент нашего репозитория. Это огромная пачка фич, которая стекается в ветку develop – не что иное, как одна пачка задач, которые сделали несколько разработчиков и одновременно послали pull request в основной ствол разработки. В любой момент эти задачи можно было принять и отправить в продакшен. Очень удобно. Да, Git позволяет управлять именно такой очень гибкой и удобной системой ветвления.

Детальная история. Я про нее уже упомянул. 

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

Немного холивара

Представлю плюсы и минусы Git и хранилища, о которых чаще всего мы сами говорим или слышим от наших коллег.

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

Возможность параллельной работы с объектом, то, как работать с объектом – это самое популярное возражение сторонников хранилища. Здесь мы приходим к тому, что при переходе на Git, мы принимаем на себя иную культуру работы с кодом. Если раньше мы не задумывались о том, какие изменения мы вносим, как они повлияют и будут коррелироваться с изменениями других разработчиков, то теперь, работая с Git, параллельно дорабатывать один и тот же модуль может хоть сотня разработчиков. Но при слиянии кода перед нами встает задача дополнительно проанализировать конфликты и принять решение о том, какие изменения в каждой строке кода мы принимаем для того, чтобы в продуктиве получить то, что мы хотим получить. Здесь на передний план выходит та самая пресловутая операция Code Review (инспекции кода), которая для нас становится неизбежной частью процесса разработки. Те, кто начинает работать с Git, думает, что это плохо, что это неудобно, что это дополнительные трудозатраты. Но это хорошо, потому что это повышает качество вашей разработки и, в конце концов, откликается снижением себестоимости строки кода. Это та самая «чистая архитектура», о которой писал Роберт Мартин.

Open Source – вишенка на торте. Если у вас есть какой-то интересный проект, стартап, которым вы хотите поделиться с сообществом и желаете, чтобы в ваш проект коллеги со всего мира (да что там мира, России!) вносили изменения и добавляли полезную функциональность, то welcome на GitHub. Выкладывайте свои разработки и добро пожаловать в мир Open Source.

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

Ну что, появилось желание пощупать Git? 

Подумаем о том, где и какие инструменты мы будем использовать, и как вообще можно выстроить работу нашей группы при использовании Git.

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

Есть интересный подход, который выложен на ИТС, – это разветвлённая система разработки с использованием хранилищ, которая очень напоминает Git-Flow, реализованное на хранилищах. Поэтому если у вас нет возможности использовать Git, но хочется попробовать схему Git-Flow, можете попробовать эту схему.

Если же вас не ограничивают возможности платформы, то самое время попробовать Git.

Как его начал использовать я? И один из вопросов, который мне задали в кулуарах, – начиная с какого количества разработчиков стоит начать использовать Git? Отвечаю: от одного. Я начал пользоваться Git сам для себя. Начал с того, что запушил в репозиторий шаблоны текстов кода, которыми я активно пользуюсь. Мне показалось это очень удобным, и я решил подключить к этому свою группу разработки. Мы добавили туда внешние отчеты, обработки и расширения конфигурации, потом правила обмена. 

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

Дальше - больше: всё, что прямо или косвенно касается этого проекта, добавляется в Git. Ничего не теряется. Более того, после того как мы начали использовать Git, освободилось много времени на действительно полезную работу. Голова и руки освобождаются от необходимости следить за версиями, мучиться вопросами, что куда положить, как хранить. Все это на себя успешно берет Git.

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

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

Что нужно, чтобы начать?

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

Спасибо!

 

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

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

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


 

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

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. user-z99999 57 28.10.19 16:00 Сейчас в теме
Code Review или инспекция кода, контроль чистоты архитектуры – это обязательная операция

Расскажите как это происходит? Это обучение молодых сотрудников?
Какой регламент этой операции (каждый день или раз в неделю)?
PLAstic; maXon777; +2 Ответить
2. acanta 28.10.19 16:06 Сейчас в теме
В любом случае в коллективную разработку на 8ке без гита лучше не соваться.
3. vadver 39 28.10.19 20:26 Сейчас в теме
(2)Ну почему... Лично у меня есть пара-тройка примеров успешных разработок с совершенно обычным хранилищем конфигураций. Даже без сервера.... Дело не в инструменте, а в организации
Papay72; aexeel; Bassgood; jaroslav.h; CyberCerber; jONES1979; sapervodichka; mrChOP93; acanta; +9 Ответить
4. acanta 28.10.19 20:48 Сейчас в теме
(3) вы не один такой
sapervodichka; +1 Ответить
6. Светлый ум 277 29.10.19 12:45 Сейчас в теме
(4) вы и не два такой)
- На создании прототипов и первых версий продуктов редко используется большая команда.
Bassgood; +1 Ответить
5. fenixnow 246 29.10.19 07:31 Сейчас в теме
Гит, гит, гит, я ахитектор, я архитектуру архитектуру! Статья сплошная вода.
wowik; kar911; aexeel; RhelasTgav; user1298446; w.r.; loda; mrChOP93; +8 Ответить
7. GROOVY 2475 29.10.19 13:20 Сейчас в теме
EDT нативно работает с гитом.
ellavs; acanta; +2 Ответить
14. w.r. 628 30.10.19 17:47 Сейчас в теме
(7) только с сам edt нифига не нативный и очень тормозной
Bassgood; +1 Ответить
8. MaCCapAkIII 29.10.19 14:53 Сейчас в теме
Все здорово, но где мне как единственному разработчику, работающему с конфигурацией 1С, прочитать про конкретные шаги по работе с Git? Я лично столкнулся с рядом существенных проблем, решить которые помочь мне так никто и не смог - все отправляют учиться и читать. Вот примерная последовательность действий, которая у меня приводит к неутешительным результатам:

1. Завел репозиторий в bitbucket.
2. Клонировал этот репозиторий на локальный диск.
//вообще только начинаю общаться с системами контроля версий, работаю один, показалось интересным контролировать все стадии доработок и не держать в голове кучу информации.
3. В папку, которая локальная копия репозитория выгрузил конфигурацию в файлы через "Конфигурация - Выгрузить конфигурацию в файлы". То есть была создана структура каталогов с файлами xml, bsl и прочими.
//конфигурации пробовал разные. Сильно переписанную УТ, Розницу, БП2
//при выгрузке конфигурация часто ругается на длинные имена файлов и длинные имена каталогов. Игнорирую. Так как если с каталогами я еще что-то могу поделать, то с именами файлов на данном этапе своего развития - нет.
4. Далее делал первоначальную синхронизацию локального каталога с облаком и тянул в облако все гигабайты выгруженных файлов.
5. Дальнейшая разработка влекла за собой повтороные инкрементные выгрузки (как я понял сама платформа по записям в служебном файле контролирует что изменилось и выгружает) и обмен с облачным репозиторием. Все изменения в модулях bsl видел. Про синхронизацию изменений (возможно проблемную) форм услышал только на форуме и даже боюсь пока об этом думать. Как решать такие коллизии если возникнут пока не знаю.
6. Проблемы начались при попытке загрузки. Дорабатывал УТ. Все пункты с 1 по 5 делал дома, после возникла необходимость доработать на рабочем комьютере. Клонировал облачный репозиторий на локальный компьютер, попробовал загрузить из файлов "Конфигурация - Загрузить конфигурацию из файлов" и начал получать ошибки. Первый вариант - некая ошибка в xml, подробно не вспомню, но что-то про неуникальное имя. Второй вариант - загрузка проходит, но конфигурация становится пустой, пропадают все объекты...

Если брать работу с обработками - там вроде все более или менее понятно. Вместе с текстовой информацией из файлов обработки можно синхронизировать также сам файл обработки. Но тут вопрос. Если мне надо перейти на версию обработки с ветки №6 из десяти веток - epf тоже версионируется при синхронизации или нет? Подозреваю, что нет.
А вот с конфигурациями совсем не понимаю. Концептуально не понимаю. Вот выгрузил я конфигурацию в файлы. Каждая ветка имеет некие доработки в неких файлах и если мне надо перейти/вернуться на определенный этап разработки - как это сделать? Что-то читал про "автоматическую сборку cf из файлов, но так и не нашел как и что. Или я в принципе неверно работаю? Хранилищем конфигурации не пользуюсь в принципе, так как не знаю, что это такое.
Сумбурно, но это суть проблемы. )

Забыл. Бинарные файлы, как мне сказали, с Git не версионируются.
aleksey2; GetNight; ntemny; Summer_13; +4 Ответить
10. Алексей Воробьев 154 30.10.19 09:43 Сейчас в теме
(8)Да, очень сумбурно. Ну да ладно...

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

Для чего? Чтобы гонять разработку из дома в офис и наоборот? Для этого существует удаленный рабочи стол, не нужно ничего таскать туда-сюда да еще через облако...

Опять же увидел: БП2. То есть пытаетесь прикрутить Git к обычным формам? Такое себе, хотя теоретически возможно...

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

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

Если аппаратные ресурсы позволяют (хороший проц, много памяти и диск SSD) можно начать знакомство с Git из EDT. Встроенный функционал Git'а в EDT вполне работоспособен. Но тут только конфигурации на УФ.

Если разработчик один - да не нужно вам облако! Хватит локального репозитория и удаленного рабочего стола, если работаете из нескольких мест. Локальный репо можно бэкапить как простую папку...
Если таки сильно нужно (несколько разрабов) - можно развенуть Git-сервер в локальной сети (какой-нить Bonobo гит-сервер)

Но для начала - хранилище... Это несложно. Сделайте для хранилища папку локально или в шаре. Поместите конфигурацию в хранилище из конфигуратора. Далее захватывайте отдельные объекты, редактируйте и помещайте назад в хранилище. Подключаете другую конфу (у другого разраба или боевую базу) - все изменения автоматически применятся к этой конфе. Можно относительно безболезненно обновлять конфигурацию из хранилища и т.п.
12. MaCCapAkIII 30.10.19 10:40 Сейчас в теме
(10)
Если разработчик один - да не нужно вам облако! Хватит локального репозитория и удаленного рабочего стола, если работаете из нескольких мест. Локальный репо можно бэкапить как простую папку...
Если таки сильно нужно (несколько разрабов) - можно развенуть Git-сервер в локальной сети (какой-нить Bonobo гит-сервер)

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

Это понятно. Просто хочу изучит md кратчайшие сроки технологию групповой разработки, возможно впоследствии получится поменять текущий вид деятельности на 1С, а работать в команде не умею. И на обучение, боюсь, работодатель времени не даст.
Если у меня в работе 7+ конфигураций - работать с 7+ хранилищами для разных конфигураций? Я когда пробовал с СКВ работать визуально нагляднее показалась работа с несколькими различными репозиториями.
Понравилась идея с локальным репозиторием для одного меня. С удаленным рабочим столом - тоже вопрос интересный. На работе все данные хранятся локально, после окончания рабочего дня все обесточивается и подключиться возможности нет...
15. Алексей Воробьев 154 31.10.19 08:28 Сейчас в теме
(12)
Я так думаю, что в большинстве случаев в командах, в которых реально поставлен процесс групповой разработки, используются исключительно четкие инструкции по следованию этому самому процессу и от "умения" или "неумения" работать в команде будет мало что зависеть. Понимать, чего требуют эти инструкции, это да - было бы неплохо. Но скорее всего сходу и необязательно... Просто выполнять их для начала.
Обучение сведется к инструктажу и все.

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

Если работодатель заинтересован в вашей работе в нерабочее время, то, думаю, в его интересах обеспечить необходимые для этого ресурсы типа удаленного рабочего стола и т.п.
Если "в этой конторе все сложно!", как иногда бывает, то точно вы на верном пути в плане смены вида деятельности и(или) места работы...
16. Snitkovski 88 17.11.19 17:49 Сейчас в теме
(8) привет! ничего сложного там нет, нужно просто осознать некоторые ограничения... если ещё не разобрались и если ещё нужна помощь - напишите в личку - от получаса до часа и всё взлетит (как минимум - проЯснится)
9. PLAstic 288 30.10.19 09:13 Сейчас в теме
А где "другие технологии групповой разработки"? Надо или переименовать статью, или добавить их всё же.
11. ImHunter 247 30.10.19 09:45 Сейчас в теме
(9) Например:
Есть интересный подход, который выложен на ИТС, – это разветвлённая система разработки с использованием хранилищ, которая очень напоминает Git-Flow, реализованное на хранилищах.
13. RuslanZ 410 30.10.19 12:27 Сейчас в теме
Надо же, именно сегодня обработка в тему https://infostart.ru/public/1147220/
17. sikuda 666 16.08.21 16:40 Сейчас в теме
Я бы в конце добавил картинку
Прикрепленные файлы:
Оставьте свое сообщение

См. также

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

Групповая разработка (Git, хранилище) Обмен между базами 1C v8 КД Бесплатно (free)

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

25.06.2018    31218    olegtymko    48    

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

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

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

16.06.2022    678    ImHunter    0    

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

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

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

08.06.2022    589    curdate    10    

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

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

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

17.04.2022    814    malikov_pro    0    

Выгрузка версии хранилища в XML файлы

Файловые протоколы обмена (TXT, XML, DBF), FTP Групповая разработка (Git, хранилище) v8 Бесплатно (free)

Скрипт, выполняющий выгрузку произвольной версии из хранилища в XML.

17.03.2022    673    kraynev-navi    2    

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

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

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

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

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

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

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

01.06.2021    3458    Dipod    13    

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

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

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

31.05.2021    2060    grumagargler    0    

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

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

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

19.05.2021    8445    sinichenko_alex    45    

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

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

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

03.11.2020    19484    Yashazz    15    

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

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

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

14.11.2019    3200    biimmap    34    

История одного проекта обновления

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

История одного проекта обновления, хранилище, групповая разработка.

06.11.2019    5903    vasilev2015    20    

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

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

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

29.09.2019    9690    malikov_pro    14    

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

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

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

29.06.2019    9504    johnnyshut23    34    

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

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

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

26.05.2019    16518    tormozit    21    

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

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

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

28.03.2019    34258    ellavs    90    

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

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

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

01.03.2019    80610    Смешной 1С    35    

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

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

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

28.01.2019    33802    stas_ganiev    31    

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

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

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

25.01.2019    3367    Lucifer93    2    

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

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

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

18.10.2018    117369    stas_ganiev    86    

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

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

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

23.08.2018    14197    shaa2    3    

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

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

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

15.08.2017    25215    stas_ganiev    16    

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

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

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

02.03.2016    26459    balanton    2    

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

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

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

22.04.2014    19450    Franco    12    

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

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

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

03.06.2013    45612    _also    33    

Настройка удаленного хранилища 1С 8.2 IIS6 (server 2003)

Групповая разработка (Git, хранилище) v8 1cv8.cf ИТ-компания Бесплатно (free)

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

26.11.2012    14610    alex.msk    3    

1с v8.2.13 ХранилищеЗначений в Табличной части объекта

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

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

21.12.2011    23790    kostia.ck    8    

Механизм хранения реквизитов в хранилище значений информационной базы

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

Хранение реквизитов внешних печатных форм в информационной базе

21.11.2011    31784    alnovin    14    

Сравнение значений типа Хранилище

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

Сравнение значений типа Хранилище (простое решение для тех, кто не нашел ничего подобного на просторах интернета и не имеет навыков быстрого формирования контрольных сумм CRC, md5 средствами 1С, но имеет желание или необходимость выполнения такого сравнения). * было актуально для платформы 8.2, платформа 8.3 уже позволяет получить хеш MD5 или CRC32

18.10.2011    17067    yandextesting    6    

Хранилище конфигурации

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

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

28.12.2010    22670    German    24    

Настройка удаленного хранилища конфигурации 1С 8.1 ( HTTP)

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

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

08.06.2010    33452    Veratis1c    12    

Хранилище конфигурации: создание и использование

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

Заметка про Хранилище конфигурации 1С:8.х Зачем, кому и для чего оно может быть полезно? Как создать, как использовать, как организовать работу программистов с ней? "Неочевидные" и "невероятные" методики для чайников :)

12.01.2010    156300    kote    58