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

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.

 

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

 

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    8995    78    4    

107

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

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

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

05.03.2024    1743    user1989937    6    

15

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

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

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

05.02.2024    3683    bayselonarrend    15    

59

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

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

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

22.01.2024    7711    bayselonarrend    50    

86

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

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

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

17.01.2024    2645    kamisov    17    

56

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

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

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

26.12.2023    1281    ardn    1    

24

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

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

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

1 стартмани

20.12.2023    3829    56    salexdv    26    

80

Захват в хранилище по составу подсистем

Групповая разработка (Git, хранилище) Управляемые формы 8.3.8 Конфигурации 1cv8 Абонемент ($m)

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

1 стартмани

21.11.2023    1292    7    ImHunter    0    

17
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. user-z99999 67 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. Светлый ум 406 29.10.19 12:45 Сейчас в теме
(4) вы и не два такой)
- На создании прототипов и первых версий продуктов редко используется большая команда.
Bassgood; +1 Ответить
5. fenixnow 267 29.10.19 07:31 Сейчас в теме
Гит, гит, гит, я ахитектор, я архитектуру архитектуру! Статья сплошная вода.
wowik; kar911; aexeel; RhelasTgav; user1298446; w.r.; loda; mrChOP93; +8 Ответить
7. GROOVY 2503 29.10.19 13:20 Сейчас в теме
EDT нативно работает с гитом.
ellavs; acanta; +2 Ответить
14. w.r. 643 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. Алексей Воробьев 291 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. Алексей Воробьев 291 31.10.19 08:28 Сейчас в теме
(12)
Я так думаю, что в большинстве случаев в командах, в которых реально поставлен процесс групповой разработки, используются исключительно четкие инструкции по следованию этому самому процессу и от "умения" или "неумения" работать в команде будет мало что зависеть. Понимать, чего требуют эти инструкции, это да - было бы неплохо. Но скорее всего сходу и необязательно... Просто выполнять их для начала.
Обучение сведется к инструктажу и все.

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

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