Кровь, пот и GIT
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(5) все-таки не соглашусь, git клиент как расширение vs code не столь удобен, как отдельный git клиент, как минимум, для меня показалось не удобным переключение между ветками, также отмечу, что там также нельзя запускать произвольные скрипты из интерфейса, как это есть в git extensions, для меня vscode, это удобный инструмент редактирования кода, или его поиска по структуре каталога, но точно не удобный git клиент.
Пока читал статью, в очередной раз понял нафига оно не надо... чтоб это поддерживать нужно тоже специалистов держать и гуру по решению нештатных ситуаций, которых не возникает при использовании "1С Хранилище конфигураций" + сервера хранилищ.
Я уже 10 лет пользуюсь со своей командой "1С Хранилищами конфигураций", никаких биений лбами практически не происходит, захват корня минимизируем вполне может быть и смешным способом, например на примере обработок и отчетов.
Создаешь в структуре метаданных: Отчет01, Отчет02,... ОтчетХХ, Обработка01, Обработка02,..., ОбработкаХХ.
Если кому требуется создать новый отчет или обработку, у него полно болванок, захватил и играйся от души. Создание болванок минутное дело, Ctrl+C, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V,...
Общие модули делим по типа ХХ_ПечатныеФормыПродажи, ХХ_ПечатныеФормыЗакупки, ХХ_Производство, ХХ_УправлениеСвойствами, ХХ_Константы, ХХ_ТЕкстЗапросов, ХХ_ОбщегоНазначения.... по итогу дробится функционал и редко кто-то пересекается из разработчиков.
Разработка вся только в расширении конфигурации, ОДНОМ ЕДИНОМ, а не зоопарке!!! Упрощен поиск ошибок, легко обновлять базу на новые релизы.
Да все знают, что "Хранилище конфигураций" и конфигуратор не навороченный VisualStudio, но блин его мне хватает на все 100%, ибо и отладка пашет хорошо, и интерфейс не вырви глаз как в EDT, легкая среда разработки имеющаяся везде, даже часто на тачках пользователей. Устанавливается крайне быстро. Прикручивать всякие гиты почти кощунство. Надеюсь 1С просто доработку проведет у "Хранилища конфигураций" может не зря они опрос и провели недавно.
Я уже 10 лет пользуюсь со своей командой "1С Хранилищами конфигураций", никаких биений лбами практически не происходит, захват корня минимизируем вполне может быть и смешным способом, например на примере обработок и отчетов.
Создаешь в структуре метаданных: Отчет01, Отчет02,... ОтчетХХ, Обработка01, Обработка02,..., ОбработкаХХ.
Если кому требуется создать новый отчет или обработку, у него полно болванок, захватил и играйся от души. Создание болванок минутное дело, Ctrl+C, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V, Ctrl+V,...
Общие модули делим по типа ХХ_ПечатныеФормыПродажи, ХХ_ПечатныеФормыЗакупки, ХХ_Производство, ХХ_УправлениеСвойствами, ХХ_Константы, ХХ_ТЕкстЗапросов, ХХ_ОбщегоНазначения.... по итогу дробится функционал и редко кто-то пересекается из разработчиков.
Разработка вся только в расширении конфигурации, ОДНОМ ЕДИНОМ, а не зоопарке!!! Упрощен поиск ошибок, легко обновлять базу на новые релизы.
Да все знают, что "Хранилище конфигураций" и конфигуратор не навороченный VisualStudio, но блин его мне хватает на все 100%, ибо и отладка пашет хорошо, и интерфейс не вырви глаз как в EDT, легкая среда разработки имеющаяся везде, даже часто на тачках пользователей. Устанавливается крайне быстро. Прикручивать всякие гиты почти кощунство. Надеюсь 1С просто доработку проведет у "Хранилища конфигураций" может не зря они опрос и провели недавно.
(8) Отмечу только, что поиск ошибок в хранилище не такой уж и удобный, а просмотр чем текущая форма конфигурации отличается от предыдущей вообще превращается в геморрой, так как быстро сравниваются только изменения в модуле. Также без комментария, по какой задаче сделано, и авторства очень сложно определить, кто именно сделал доработку. Плюс невозможно вести крупные долгоиграющие проекты на несколько недель или месяцев, у тебя тогда должно быть постоянно захвачены объекты из хранилища, либо целиком отключено хранилище, и это при том, что ты должен выполнять работу и по другим задачам. Плюс использование больше одного расширения с хранилищем превращается в ад подключения. А так каждый волен использовать собственный инструмент, какой ему удобней использовать.
(10) Ну как бы в хранилище есть функция выборочного сравнения объектов, где не тянется вся конфигурация целиком для сравнения, а только то что ты сравнивать хочешь. Мы доработками ERP занимаемся не снимая замков, и все дорабатываем в расширении, а поскольку расширение не такой гигант как сама типовая конфигурация, то даже полное сравнение в расширении происходит довольно быстро.
По поводу долгоиграющих доработок. Ну вот сижу я пилю реально два с лихом месяца что-то. И тут кому-то понадобилось внести правку там, он как и принято всегда просит отпустить объект, я же понимаю что не могу. Но на самом деле могу. Сохраняю CFE, отпускаю объект. Там человек делает правку быстро. Я смотрю, что он менял. Захватываю объект, делаю сравнение и объединение, вношу такую же правку как тот человек и продолжаю работать. Это краааайне редко так делать приходится ибо как правило все разработчики занимаются разными областями.
Я реально много чего переписывал комплексно и не один месяц, и я не сцу за свои доработки, я могу их сдавать тупо частями, освобождаю объекты, а есть (не в моей команде) туча программистов сыкунов, которые не могут гарантировать работу своего кода и потому будут миллион захваченных объектов держать. Я при том сдавая частями что-то могу уже даже наблюдать как что-то частично уже жить начинает, а я достраиваю все остальное, шаг за шагом. А могут мои сданные кусочки функционала начинать использовать и другие программисты.
Меня веселят люди пытающиеся использовать докеры шмокеры для отладок, создают себе кучу работы искусственно, вместо того чтобы просто сесть и хорошо продумать систему чтобы она обладала свойствами самотестирования там где ну прям вообще труба и сложные алгоритмы расчетов. Вот и Git у меня ассоциируется с бесполезной созданной искусственной работой, где перед руководством потом можно козырять красивыми и все равно не понятными ему словами.
Я не отрицаю, может для некоторых команд Git единственный выход, но я в такую опу еще не попадал к счастью!
По поводу долгоиграющих доработок. Ну вот сижу я пилю реально два с лихом месяца что-то. И тут кому-то понадобилось внести правку там, он как и принято всегда просит отпустить объект, я же понимаю что не могу. Но на самом деле могу. Сохраняю CFE, отпускаю объект. Там человек делает правку быстро. Я смотрю, что он менял. Захватываю объект, делаю сравнение и объединение, вношу такую же правку как тот человек и продолжаю работать. Это краааайне редко так делать приходится ибо как правило все разработчики занимаются разными областями.
Я реально много чего переписывал комплексно и не один месяц, и я не сцу за свои доработки, я могу их сдавать тупо частями, освобождаю объекты, а есть (не в моей команде) туча программистов сыкунов, которые не могут гарантировать работу своего кода и потому будут миллион захваченных объектов держать. Я при том сдавая частями что-то могу уже даже наблюдать как что-то частично уже жить начинает, а я достраиваю все остальное, шаг за шагом. А могут мои сданные кусочки функционала начинать использовать и другие программисты.
Меня веселят люди пытающиеся использовать докеры шмокеры для отладок, создают себе кучу работы искусственно, вместо того чтобы просто сесть и хорошо продумать систему чтобы она обладала свойствами самотестирования там где ну прям вообще труба и сложные алгоритмы расчетов. Вот и Git у меня ассоциируется с бесполезной созданной искусственной работой, где перед руководством потом можно козырять красивыми и все равно не понятными ему словами.
Я не отрицаю, может для некоторых команд Git единственный выход, но я в такую опу еще не попадал к счастью!
(11) данная статья не агитирует за git, она только показывает какие ошибки могут быть, вы вольны использовать собственный инструментарий. Не понимаю такого негатива. И докеры и шмокеры хороши в определенных ситуациях, если вы их не используете это не значит, что они не нужны.
Я правильно понимаю, что вы ERP дорабатываете через расширение? это проект на сколько программистов и пользователей? Лично мое мнение, если ERP находится на поддержке у команды разработчиков, что нужно всячески уходить от расширений, они только усложняют дальнейшую работу и поддержку, а расширение использовать как патчи, вместо динамического обновления. Также хотелось уточнить, а как вы храните документацию, или внешние обработки и отчеты, вы их не версионируете, или например доработанные внешние регламентированные отчеты? Использование GIT призвано стандартизировать работу команды, а не выделять личность, которая может сдавать проект частями (правда непонятно, зачем неготовые объекты в системе, еще не протестированные пользователями), и те кто имеют меньше квалификацию. Процесс разработки делится на этапы выполнения работы и дополнительного контроля со стороны более квалифицированного коллеги, который и принимает решение о корректности выполнения задачи, дополнительно может проводиться код ревью, плюс задачи проходит этап тестирования, которая проводится заказчиком или ответственным сотрудником, и после переезжает в рабочую базу. Все это можно делать и через хранилище 1С, и через GIT , просто через git это проще. В хранилище при такой реализации нужно как-то покрывать дополнительно скриптами для переезда доработок между отдельными хранилищами: разработка, тестирование, рабочие. Конечно, если ты сам себе постановщик, разработчик, тестировщик, и тимлид, то такая схема работа вообще не нужна.
Я правильно понимаю, что вы ERP дорабатываете через расширение? это проект на сколько программистов и пользователей? Лично мое мнение, если ERP находится на поддержке у команды разработчиков, что нужно всячески уходить от расширений, они только усложняют дальнейшую работу и поддержку, а расширение использовать как патчи, вместо динамического обновления. Также хотелось уточнить, а как вы храните документацию, или внешние обработки и отчеты, вы их не версионируете, или например доработанные внешние регламентированные отчеты? Использование GIT призвано стандартизировать работу команды, а не выделять личность, которая может сдавать проект частями (правда непонятно, зачем неготовые объекты в системе, еще не протестированные пользователями), и те кто имеют меньше квалификацию. Процесс разработки делится на этапы выполнения работы и дополнительного контроля со стороны более квалифицированного коллеги, который и принимает решение о корректности выполнения задачи, дополнительно может проводиться код ревью, плюс задачи проходит этап тестирования, которая проводится заказчиком или ответственным сотрудником, и после переезжает в рабочую базу. Все это можно делать и через хранилище 1С, и через GIT , просто через git это проще. В хранилище при такой реализации нужно как-то покрывать дополнительно скриптами для переезда доработок между отдельными хранилищами: разработка, тестирование, рабочие. Конечно, если ты сам себе постановщик, разработчик, тестировщик, и тимлид, то такая схема работа вообще не нужна.
(13) Сейчас программистов 6 человек включая меня. Пользователей более ста. На предыдущей работе пользователей было свыше 300. Да как и писал выше сейчас нет того ада наверное, который есть у других, что они вынуждены использовать более так сказать серьезные системы типа Git. Я не негатювлю, просто люди должны понимать, что Git не панацея и не всегда нужен, можно обходиться и более простым функционалом.
Да дорабатываем через расширения все, при этом стремимся чтобы расширение было только одно, но сейчас их два. Второе заточено под интеграции с 1С ДО 2.1 (в нем тоже одно расширение). С Самого начала как начали использовать ERP, все дорабатывали только через расширения. Эта практика пока не подводила не считая иногда встречавшиеся глюки платформы. Разработка с применением расширений проходит куда интереснее чем портить типовой код, обновления на новые релизы протекают гладко, большое подспорье это проверка возможности применения расширений с автоматическим поиском проблем, хоть и не всех. В свое время я услал восстанавливать допилы в БП 2.0 - 3.0 при обновлении, в начале своей карьеры, кошмарная рутина стала. На ERP это было бы еще то удовольствие, не завидую тем кто пилит типовую.
Если снимать замки с типовой ERP, то банально как было замечено, обновление ставится не 30 минут, а 3 часа. Применять хранилище на типовой конфигурации пробовал, лютый трэш с длительностью захвата всех объектов, со сдачей в хранилище. Само по себе хранилище растет в размере большими темпами...
Документации к сожалению мало, по сути как и везде кто-то ставит ТЗ на ломанном языке, мы пытаемся реализовать. В сложных отчетах или обработках сразу в расширении пишется справка, чего вполне хватает.
От внешних отчетов и обработок планомерно уходим, разгребаем технический долг доставшийся в конце 2021 года, все переносим в то самое расширение где и версионируется оно уже хранилищем конфигураций.
До этого программисты 1С на предприятии пытались Git использовать для внешних обработок и отчетов, посмотрев на что я прекратил эту практику на корню ибо времени на то чтобы запихнуть в Git обработку или отчет, а потом положить в базу в справочник внешних обработок, уходило больше чем просто работать с хранилищем (свыше 300 обработок и отчетов было внешних). А ведь те программисты гавкались даже на этапе размещения в базе своей обработки ибо кто-то на несколько минут раньше туда положил такую же, но со своими доработками, ну и закономерно доработки одного терялись, так что внешние файлики это очень плохое решение. Позволительно только с нуля что-то как внешнее писать, отлаживается, а потом вживляется в расширение и уже потом групповая доработка через хранилище.
Вы там видимо в каки-то тепличных условиях доработки ведете, видимо в столице родины нашей. Мы тут в глубинке не избалованы огромным количеством тестировщиков, кодревьверов и еже с ними. Приходится полагаться на свой многолетний опыт и то как ты изначально код пишешь, то есть не как курица лапой, где ничего не понятно. Я гоняю за несоблюдения аккуратности. Так и вот сдается код в котором ты уверен и конечно же протестирован хоть даже и бегло на тестовых базах. От того, что ты например выполняя большую работу в некотором общем модуле изобрел новую функцию получения минимума из двух чисел и сдал ее в хранилище, система не упадет, зато другой программист получает возможность и свое что-то в модуль сдать, а ты в каких-то других частях еще не дописанной программы уже используешь свою функция получения минимума.
И разве кто-то мешает допустим сделать костяк некоторого справочника, без блэк джэка и ... и сдать его в хранилище и применить. Потом юзеры возможно без некоторого комфорта начинают туда вбивать данные, а ты тем временем пилишь кнопочки, которые добавят в будущем комфорта. Стоит упомянуть, что все же между программистами и юзерами у нас есть и только одна линия обороны в виде пяти специалистов 1С, которые в отличии от юзеров в состоянии материалы с 1С ИТС читать и так же проверить за программистом потыкав кнопочки в новом или допиленном старом функционале и то чисто для успокоения и отрапортованию юзеру, что работа сделана.
У нас кощунство, мы и разрабатываем и тестируем, и применяем в боевые базы все из одного хранилища, экономия времени катастрофичная, отладке не мешает, ибо у программистов и так у всех свои базы, где еще до сдачи доработок может проверить функционал как он сам, так специалист 1С и юзер.
Вот вот, ближе к истине, я тимлид, а моя команда программистов молодцы, каждый сочетает в себе: постановщика (под контролем меня), разработчика, тестировщика.
Такой состав функций у каждого программиста позволил за пол года без лишних соплей перевести 15 (1С КА 1.1) филиалов крупной фирмы в ERP, под знаменем новой одной организации. Потом в эту же базу за 3 месяца завести крупное производственное предприятие (1С УПП 1.3) являющейся материнским для той первой организации. Потом выполнить там же слияние организаций за 3 месяца. Предприятие видя, что программистов мало, а работ море пыталось привлечь много разных франчей. Только они слились все уже на этапе коммерческих предложений. И только из Первого Бита пару ребят удалось все же на процентов 5 работ задействовать на момент объединения фирм.
На новой работе применяя тот же подход, за 2.5 месяца удалось перевести фирму с релиза ERP 2.4 на 2.5.7, очень запущенная база. Ударными темпами, но вытянули, теперь разгребаем технический долг доставшийся по наследству (и это не только ERP). И тут хранилищ конфигураций за глаза хватает. В каждый момент времени программисты видят, что кто-то уже колупает некий объект и что можно просто заняться или другой работой или узнать, а нужен ли он еще, решается все без конфликтов и быстро. Проблем со слиянием доработок разных программистов нет ибо разработка и изменения последовательные получаются, сначала один допилил, потом другой, и так далее. Мы уже готовы ставить 2.5.11 релиз ERP, как только он перекочует в колонку стабильных. При этом нужно переименовать в расширении только одну подсистему и мы обновились (проверено на тестовой).
По сути можно или волокиту разводить бумажную с кучей прослоек специалистов разных уровней, чтобы перекладывать ответственность (обезьянку), или просто работать без лишних бесполезных порой людей, делать работы частями и отдавать в работу частями, если это возможно, нечего так сказать тянуть известно кого за известно что. Если работы сдавать частями, то и обратную связь от пользователей начнешь раньше получать и не придется переписывать все ибо они хотели по другому.
Ладно все это не о Git.
Кому надо тот его будет использовать.
Но я надеюсь, что все же на волне санкций, фирма 1С развивать будет свой инструментарий.
Я правильно понимаю, что вы ERP дорабатываете через расширение?
Да дорабатываем через расширения все, при этом стремимся чтобы расширение было только одно, но сейчас их два. Второе заточено под интеграции с 1С ДО 2.1 (в нем тоже одно расширение). С Самого начала как начали использовать ERP, все дорабатывали только через расширения. Эта практика пока не подводила не считая иногда встречавшиеся глюки платформы. Разработка с применением расширений проходит куда интереснее чем портить типовой код, обновления на новые релизы протекают гладко, большое подспорье это проверка возможности применения расширений с автоматическим поиском проблем, хоть и не всех. В свое время я услал восстанавливать допилы в БП 2.0 - 3.0 при обновлении, в начале своей карьеры, кошмарная рутина стала. На ERP это было бы еще то удовольствие, не завидую тем кто пилит типовую.
Если снимать замки с типовой ERP, то банально как было замечено, обновление ставится не 30 минут, а 3 часа. Применять хранилище на типовой конфигурации пробовал, лютый трэш с длительностью захвата всех объектов, со сдачей в хранилище. Само по себе хранилище растет в размере большими темпами...
Также хотелось уточнить, а как вы храните документацию,
Документации к сожалению мало, по сути как и везде кто-то ставит ТЗ на ломанном языке, мы пытаемся реализовать. В сложных отчетах или обработках сразу в расширении пишется справка, чего вполне хватает.
От внешних отчетов и обработок планомерно уходим, разгребаем технический долг доставшийся в конце 2021 года, все переносим в то самое расширение где и версионируется оно уже хранилищем конфигураций.
До этого программисты 1С на предприятии пытались Git использовать для внешних обработок и отчетов, посмотрев на что я прекратил эту практику на корню ибо времени на то чтобы запихнуть в Git обработку или отчет, а потом положить в базу в справочник внешних обработок, уходило больше чем просто работать с хранилищем (свыше 300 обработок и отчетов было внешних). А ведь те программисты гавкались даже на этапе размещения в базе своей обработки ибо кто-то на несколько минут раньше туда положил такую же, но со своими доработками, ну и закономерно доработки одного терялись, так что внешние файлики это очень плохое решение. Позволительно только с нуля что-то как внешнее писать, отлаживается, а потом вживляется в расширение и уже потом групповая доработка через хранилище.
(правда непонятно, зачем неготовые объекты в системе, еще не протестированные пользователями),
Вы там видимо в каки-то тепличных условиях доработки ведете, видимо в столице родины нашей. Мы тут в глубинке не избалованы огромным количеством тестировщиков, кодревьверов и еже с ними. Приходится полагаться на свой многолетний опыт и то как ты изначально код пишешь, то есть не как курица лапой, где ничего не понятно. Я гоняю за несоблюдения аккуратности. Так и вот сдается код в котором ты уверен и конечно же протестирован хоть даже и бегло на тестовых базах. От того, что ты например выполняя большую работу в некотором общем модуле изобрел новую функцию получения минимума из двух чисел и сдал ее в хранилище, система не упадет, зато другой программист получает возможность и свое что-то в модуль сдать, а ты в каких-то других частях еще не дописанной программы уже используешь свою функция получения минимума.
И разве кто-то мешает допустим сделать костяк некоторого справочника, без блэк джэка и ... и сдать его в хранилище и применить. Потом юзеры возможно без некоторого комфорта начинают туда вбивать данные, а ты тем временем пилишь кнопочки, которые добавят в будущем комфорта. Стоит упомянуть, что все же между программистами и юзерами у нас есть и только одна линия обороны в виде пяти специалистов 1С, которые в отличии от юзеров в состоянии материалы с 1С ИТС читать и так же проверить за программистом потыкав кнопочки в новом или допиленном старом функционале и то чисто для успокоения и отрапортованию юзеру, что работа сделана.
В хранилище при такой реализации нужно как-то покрывать дополнительно скриптами для переезда доработок между отдельными хранилищами: разработка, тестирование, рабочие.
У нас кощунство, мы и разрабатываем и тестируем, и применяем в боевые базы все из одного хранилища, экономия времени катастрофичная, отладке не мешает, ибо у программистов и так у всех свои базы, где еще до сдачи доработок может проверить функционал как он сам, так специалист 1С и юзер.
Конечно, если ты сам себе постановщик, разработчик, тестировщик, и тимлид, то такая схема работа вообще не нужна.
Вот вот, ближе к истине, я тимлид, а моя команда программистов молодцы, каждый сочетает в себе: постановщика (под контролем меня), разработчика, тестировщика.
Такой состав функций у каждого программиста позволил за пол года без лишних соплей перевести 15 (1С КА 1.1) филиалов крупной фирмы в ERP, под знаменем новой одной организации. Потом в эту же базу за 3 месяца завести крупное производственное предприятие (1С УПП 1.3) являющейся материнским для той первой организации. Потом выполнить там же слияние организаций за 3 месяца. Предприятие видя, что программистов мало, а работ море пыталось привлечь много разных франчей. Только они слились все уже на этапе коммерческих предложений. И только из Первого Бита пару ребят удалось все же на процентов 5 работ задействовать на момент объединения фирм.
На новой работе применяя тот же подход, за 2.5 месяца удалось перевести фирму с релиза ERP 2.4 на 2.5.7, очень запущенная база. Ударными темпами, но вытянули, теперь разгребаем технический долг доставшийся по наследству (и это не только ERP). И тут хранилищ конфигураций за глаза хватает. В каждый момент времени программисты видят, что кто-то уже колупает некий объект и что можно просто заняться или другой работой или узнать, а нужен ли он еще, решается все без конфликтов и быстро. Проблем со слиянием доработок разных программистов нет ибо разработка и изменения последовательные получаются, сначала один допилил, потом другой, и так далее. Мы уже готовы ставить 2.5.11 релиз ERP, как только он перекочует в колонку стабильных. При этом нужно переименовать в расширении только одну подсистему и мы обновились (проверено на тестовой).
По сути можно или волокиту разводить бумажную с кучей прослоек специалистов разных уровней, чтобы перекладывать ответственность (обезьянку), или просто работать без лишних бесполезных порой людей, делать работы частями и отдавать в работу частями, если это возможно, нечего так сказать тянуть известно кого за известно что. Если работы сдавать частями, то и обратную связь от пользователей начнешь раньше получать и не придется переписывать все ибо они хотели по другому.
Ладно все это не о Git.
Кому надо тот его будет использовать.
Но я надеюсь, что все же на волне санкций, фирма 1С развивать будет свой инструментарий.
(19)
Я и не говорил о том что это одно и тоже. Может написал неудачно, согласен.
Просто когда все хвалят технологию системы контроля версий Git как правило игнорируют, что для ее использования часто применяют множество забугорного сопровождающего ПО и сервисов.
Когда я писал пример про сервис для хостинга и совместной разработки "GitHab", я "троллил" всю тему поклонения технологии Git.
Отдельно добавлю: Я работаю в компании, попавший под санкции. И в один день мы потеряли продукты adobe, KMS ключи мелкомягких (закрыли доступ к административному кабинету), Autocad и возможность оплачивать множество сервисов.
(15) Brawler я полностью поддерживаю. Двумя руками за.
Специально перешли на движок 8.3.20 а в дальнейшем на 8.3.21, что бы все изменения перенести в расширения и радоваться быстрым обновлениям. Команда из 5 программистов за год перевели 2 завода (производство табачных изделий) и одну крупную дистрибьюцию на ЕРП. Сейчас хотим перейти на движок 8.3.22, что бы решить еще несколько бизнес задач исключительно через расширения. 38 баз 1С на поддержке.
Недавно пополняли штат... новых сотрудников в ИТ правда найти так и не смогли (150к в КЛД или 200к в СПБ), те кто приходили и тестировались не могут простейшие задачи решить, зато каждый считает, что нужно выносить сервера в облако и внедрять git.
так git и github это разные вещи,
\
Я и не говорил о том что это одно и тоже. Может написал неудачно, согласен.
Просто когда все хвалят технологию системы контроля версий Git как правило игнорируют, что для ее использования часто применяют множество забугорного сопровождающего ПО и сервисов.
Когда я писал пример про сервис для хостинга и совместной разработки "GitHab", я "троллил" всю тему поклонения технологии Git.
Отдельно добавлю: Я работаю в компании, попавший под санкции. И в один день мы потеряли продукты adobe, KMS ключи мелкомягких (закрыли доступ к административному кабинету), Autocad и возможность оплачивать множество сервисов.
(15) Brawler я полностью поддерживаю. Двумя руками за.
Специально перешли на движок 8.3.20 а в дальнейшем на 8.3.21, что бы все изменения перенести в расширения и радоваться быстрым обновлениям. Команда из 5 программистов за год перевели 2 завода (производство табачных изделий) и одну крупную дистрибьюцию на ЕРП. Сейчас хотим перейти на движок 8.3.22, что бы решить еще несколько бизнес задач исключительно через расширения. 38 баз 1С на поддержке.
Вот вот, ближе к истине, я тимлид, а моя команда программистов молодцы, каждый сочетает в себе: постановщика (под контролем меня), разработчика, тестировщика.
... у меня абсолютно также, каждый программист по факту и архитектор и тестировщик. Стоит ли говорить, что еще в 2018 мы реализовали маркировку табачных изделий в УПП задолго до реализации маркировки в самой 1С. Проводил круглый стол сотрудниками из самой 1С и указывал на их ошибки при внедрении маркировки в ЕРП.
Недавно пополняли штат... новых сотрудников в ИТ правда найти так и не смогли (150к в КЛД или 200к в СПБ), те кто приходили и тестировались не могут простейшие задачи решить, зато каждый считает, что нужно выносить сервера в облако и внедрять git.
(24) у многих был похожий опыт, но "git" это не какая-то вражеская технология, это то же хранилище 1С, просто в чем-то более удобное, а в чем-то и более шустрое. Вы немного путаете, использование git c другими инструментами уже относится к CI, сейчас рассматривается замена хранилища, а тут не нужны дополнительные утилиты. Вы можете поставить сервер gitlab, но также вы можете и не ставить его, а сделать центральный репозиторий, который просто хранится на том же диске, что и ваш. А дальше например уже можно использовать redmine вместо jira, или просто скрипты на onescript, которые будут делать для вас нужные задачи. Я лично также не отказался от хранилища, но использую его только на проектах как привлеченный разработчик, и также разработку веду в основном через расширение. Однако на основной работе предпочитаю именно GIT, так как если процесс разработки поставлен, и все в команде понимают, что делать, то разработка становится в разы проще. Работа в хранилище начинает раздражать в команде разработчиков более 4-х человек, начинаются уже пересечения. Эта два не противоборствующих лагеря их можно использовать в паре, воспользуйтесь gitsync и раз в день выгружайте доработки в git репозиторий (скрипт можно добавить просто в планировщик windows), поставьте разработчикам vscode, в нем воспользуйтесь командой "открыть каталог" и просто оцените насколько удобный и быстрый поиск по всей конфигурации 1С, при этом с информацией о том, кто и когда вносил доработки, это просто дополнительная фишка, которая упростит вам жизнь, при этом вы также можете продолжать работу в хранилище, а репозиторий использовать чисто для более быстрого поиска.
(27)
Да, вы правы. Загнали меня в логический тупик.
Любой функционал по параллельной разработке, будь то CVS или более поздний и популярный сегодня Git, это всегда подспорье программисту и с этим не поспоришь.
Но поскольку мы работаем в России, с Российской программой 1С, имеющий свою специфику и свой вариант решения одновременного программирования, на мой взгляд, целесообразней использовать по максимуму внутренние средства 1С, и только когда вам станет "тесно", можно добавлять дополнительные затраты на внедрение дополнительных инструментов. Лично я не сторонник новых внедрений, только ради внедрений.
PS/ и не нужно принимать еще одно соглашение от MS, при установке vscode, где я согласен что они передают код в MS и я обязан выполнять их экспортную политику, включая санкционные ограничения.
вы уже используете основную фишку git в своей работе, это обновление функции с директивой "изменение и контроль" в расширении на более новое содержимое, если подключить kdiff, то в принципе получится самый настоящий мердж.
Да, вы правы. Загнали меня в логический тупик.
Любой функционал по параллельной разработке, будь то CVS или более поздний и популярный сегодня Git, это всегда подспорье программисту и с этим не поспоришь.
Но поскольку мы работаем в России, с Российской программой 1С, имеющий свою специфику и свой вариант решения одновременного программирования, на мой взгляд, целесообразней использовать по максимуму внутренние средства 1С, и только когда вам станет "тесно", можно добавлять дополнительные затраты на внедрение дополнительных инструментов. Лично я не сторонник новых внедрений, только ради внедрений.
PS/ и не нужно принимать еще одно соглашение от MS, при установке vscode, где я согласен что они передают код в MS и я обязан выполнять их экспортную политику, включая санкционные ограничения.
(32) вы меня тоже подловили, я не читал лицензионное соглашение:) в крайнем случае вы можете запретить vscode доступ в интернет, если не хотите утечки данных, я не предлагаю вам отказаться от хранилища, но попробовать новый функционал как дополнение - почему нет
(20) Вы путаете инструмент GIT и облачные сервисы а-ля GitHub.
Не так уж и много команд в продуктовой 1С-разработке используют именно облачный GitHub. Большинство в качестве сервера для управления репозиториями используют инструменты, которые можно поставить на свой сервер, да еще бесплатно. Чаще всего это GitLab CE. Также встречается Gitea или (реже) ее прямой родитель - китайский GOOGs.
Не так уж и много команд в продуктовой 1С-разработке используют именно облачный GitHub. Большинство в качестве сервера для управления репозиториями используют инструменты, которые можно поставить на свой сервер, да еще бесплатно. Чаще всего это GitLab CE. Также встречается Gitea или (реже) ее прямой родитель - китайский GOOGs.
(21) про облачные сервисы все ясно ). Я про надежность в целом при использовании всего бесплатного:
если западники решат что open-source на РФ не распространяется, то как руководитель ИТ будет оправдываться, что все стало колом? Мы экономили 3 копейки и ведь все долгое время работало... кто бы мог подумать...
____
я понимаю, что что доклад от 2021 года. И были дружба ... жвачка ... , про будущую безопасность никто особо не задумывался. Но на дворе 2023 год со всеми сложностями. Теперь в РФ есть "Реестр программного обеспечения" в котором нет нет голого open-source, но есть "Astra Linux" , и "Postgres Pro".
И есть "GitFlic". Видимо это и есть Git с сертификатом РФ - "Уязвимости отсутствуют". Но будет ли он работать так как в докладе?
Ждем новый доклад в 2025 году :)
если западники решат что open-source на РФ не распространяется, то как руководитель ИТ будет оправдываться, что все стало колом? Мы экономили 3 копейки и ведь все долгое время работало... кто бы мог подумать...
____
я понимаю, что что доклад от 2021 года. И были дружба ... жвачка ... , про будущую безопасность никто особо не задумывался. Но на дворе 2023 год со всеми сложностями. Теперь в РФ есть "Реестр программного обеспечения" в котором нет нет голого open-source, но есть "Astra Linux" , и "Postgres Pro".
И есть "GitFlic". Видимо это и есть Git с сертификатом РФ - "Уязвимости отсутствуют". Но будет ли он работать так как в докладе?
Ждем новый доклад в 2025 году :)
(38) я вот не понимаю, откуда такой негатив, обязательно тема про GIT должна включать, что "не нужон нам ваш GIT". Не считаю, что тот комментарий как-то затыкает людей, что используют git. Почему то, все пытаются противопоставить git и хранилище 1С, упуская, что их можно использовать в паре, и можно пользоваться плюсами и хранилища и git.
Про edt+git ничего не могу сказать. так как не пользовался, но знакомые говорили, что нет смысла, edt ты используешь ради плюшек, а не версионирования. так как там переключение между ветками требует обязательной актуализации конфигурации базы данных, а это значит, что каждое переключение может занимать от получаса и более, так что да, выглядит как сумасшествие.
Каждый инструментарий хорош в определенной ситуации, мое личное мнение, если ведется командная разработка на предприятии на упр формах, а не проект, то лучше GIT и полностью отказаться от хранилища, если же проектная работа, где есть разработчики с разным уровнем разработки, или небольшая команда разработчиков, то лучше хранилище, но git можно использовать чисто для себя, чтобы видеть весь цикл разработки и быстро сравнивать например с конфигурацией поставщика.
Про edt+git ничего не могу сказать. так как не пользовался, но знакомые говорили, что нет смысла, edt ты используешь ради плюшек, а не версионирования. так как там переключение между ветками требует обязательной актуализации конфигурации базы данных, а это значит, что каждое переключение может занимать от получаса и более, так что да, выглядит как сумасшествие.
Каждый инструментарий хорош в определенной ситуации, мое личное мнение, если ведется командная разработка на предприятии на упр формах, а не проект, то лучше GIT и полностью отказаться от хранилища, если же проектная работа, где есть разработчики с разным уровнем разработки, или небольшая команда разработчиков, то лучше хранилище, но git можно использовать чисто для себя, чтобы видеть весь цикл разработки и быстро сравнивать например с конфигурацией поставщика.
Прикрепленные файлы:
(17) Я не знаю как там в Wiki, честно) Есть Code Complete: A Practical Handbook of Software Construction от Steve McConnell - я ему доверяю полностью) И есть Naming conventions в том же JavaScript, где белым по черному (темная тема же ну) пишут что для переменных рекомендуется использовать сamelCase (без Upper и Lower), а вот PascalCase запрещают использовать в именах классов.
А по теме - статья отличная, но делать мы так пока не будем)
А по теме - статья отличная, но делать мы так пока не будем)
(35) привет, так докладу уже 2 года, сейчас это далекое сытое прошлое, саму технологию вроде не запретили, пусть импортозамещение останется в госкомпаниях, коммерческое справляется пока с open source решениями, плюс у меня предыдущая компания до сих пор jira и bitbucket используют, просто не обновляют.
@Karpik666
"До выхода релиза 8.3.15, разработчикам пришлось сделать скрипт, который бы сравнивал два коммита, а разницу загружал в конфигурацию. При этом автоматически формировался актуальный ConfigDumpInfo.xml."
А что за скрипт? Ссылочкой поделитесь
"До выхода релиза 8.3.15, разработчикам пришлось сделать скрипт, который бы сравнивал два коммита, а разницу загружал в конфигурацию. При этом автоматически формировался актуальный ConfigDumpInfo.xml."
А что за скрипт? Ссылочкой поделитесь
(37) Привет, вот относительная строка запуска "C:\Program Files (x86)\OneScript\bin\oscript.exe ПутьКСкрипту\load_changes.os -repo "Путь к репозиторию" -branch {cBranch} -srvname ИмяСервера -ibname ИмяБазы -usr ИмяПользователя -pwd ПарольПользователя -dpath КаталогСЛогом -fastupdate true -fromHash {sHash} -toHash {cHash} -loadchanges true -loadextension false -updatecfgdump true -syntaxctrl false -updatedb true -deploycfg false -deployext false" и скрипты во вложении.
Прикрепленные файлы:
скрипты.zip
Однако! Значит для работы с гитом обязательно надо поставить какое-нибудь гуёвое расширение, ибо в консоли сложно. А запоминать все эти нюансы в текстовичках херачить, скриптовать - это не сложно. Разработчики такой интересный народ - избирательно ленивые…
Мне кажется, если вы на столько выросли, что стандартная концепция разработки в 1С вас не устраивает и вы готовы вот на то, что описано в статье, вам пора менять язык программирования на более подходящий для этого. Этот вывод относится и к самой компании.
Статья -огонь! Сам люблю гит. Использовал его как средство ведения доработок индивидуально.
Не вижу смыла всё запихивать в него. Это больше средство фиксации изменений. И изменения нужно фиксировать только те, которые нужны разработчику. А не так, что загонять все, с изменениями портить то, что не должно было испортиться, скриптовать, разбираться.
Мне позволяло прекрасно получать пользу от гит использование его консольной версии без дополнений. Обработки, отчёты я загонял бинарником и отдельно текстом модули их. Всё это в процессе возникновения задач, доработок позволяло формировать картину происходящего, пробовать различные варианты решений, откатываться к нужному результату.
Но вот после такой статьи с подробным разбором реальных проблем, я точно не стану повторять ошибки андрюши и тащить это на весь проект, как средство внедрения.
Мне кажется, если вы на столько выросли, что стандартная концепция разработки в 1С вас не устраивает и вы готовы вот на то, что описано в статье, вам пора менять язык программирования на более подходящий для этого. Этот вывод относится и к самой компании.
Статья -огонь! Сам люблю гит. Использовал его как средство ведения доработок индивидуально.
Не вижу смыла всё запихивать в него. Это больше средство фиксации изменений. И изменения нужно фиксировать только те, которые нужны разработчику. А не так, что загонять все, с изменениями портить то, что не должно было испортиться, скриптовать, разбираться.
Мне позволяло прекрасно получать пользу от гит использование его консольной версии без дополнений. Обработки, отчёты я загонял бинарником и отдельно текстом модули их. Всё это в процессе возникновения задач, доработок позволяло формировать картину происходящего, пробовать различные варианты решений, откатываться к нужному результату.
Но вот после такой статьи с подробным разбором реальных проблем, я точно не стану повторять ошибки андрюши и тащить это на весь проект, как средство внедрения.
(39) можно и в консоли, но зачем? круг задач выполняемые с помощью git полностью покрывается интерфейсом, и для 1с-ника запоминать команды нет смысла, не в нашем стиле, консоль имхо нужна когда тебе уже не хватает интерфейса. По поводу скриптов, так их и не нужно запоминать и дорабатывать, конечный разработчик, должен это только использовать, и приходить на все готовое, с четко описанным инструкциям, и вроде концепция "под ключ" уже есть, только не описаны подводные камни. К git-у приходишь еще потому, что в одном пространстве невозможно версионировать внешние отчеты и обработки. расширения, конфигурацию, данные, которые хранятся в базе и возможно что-то еще, что было сделано по задаче, например те же самые ТЗ, если их как-то ставили в текстовом варианте.
Вакансии
Ведущий разработчик 1С / Team lead отдела разработки 1С
Москва
зарплата от 300 000 руб. до 300 000 руб.
Полный день
Москва
зарплата от 300 000 руб. до 300 000 руб.
Полный день