Почти правильная разработка на 1С, без революций

Знаете ли вы, почему сейчас так модно внедрять Agile/Scrum/Kanban в командах разработки? Если быть совсем и до конца честным, то внедрение гибких методик разработки преследует только одну цель — приблизить команду к пользователям продукта. Сделать так, чтобы разработчики каждые две недели задумывались не о паттернах проектирования, не о том, выбрать ли для реализации нового, интересного алгоритма LinkedList, или всё таки будет достаточно ArrayList, а также не о том, какая крутая технология protobuf или не включить ли вам в проект ZeroMQ; а о том, какая от этого польза будет работающим на предприятии операторам на складе, грузчикам и водителям, токарям в цеху и продавцам-кассирам в магазине. В SCRUM обычно это называется двумя терминами Minimal Valuable Product и Bussiness Value. По большому счету, дело не в моде, а в эффективности, без ущерба комфорту обеих сторон — бизнеса и ИТ команды.

Теоретическая вводная


Прежде чем вы начнете рассказывать свои «истории неуспеха с 1С», попробую немного рассказать про DSL языки. А точнее — про концепцию «проблемно-ориентированных языков».

Domain Specific language, DSL — «предметно-специфичный язык») язык программирования, специализированный для конкретной области применения, является ключевым понятием языково-ориентированного программирования.
Здесь нет проблемы, здесь есть предмет
На самом деле я немного хитрю, давая вам определение из русскоязычной википедии. Так как добавляя слово «проблема» пытаюсь Вас отправить к первоисточнику, где автор Мартин Уорд cформулировал основы языко-ориентированного программирования


Любой новый язык в мире (будь-то PHP, ruby, python, Erlang, LISP, Closure или 1С) изначально создавался в качестве ответа на проблему. То есть если вы серьезно собираетесь изучать какой-либо язык или «фреймворк», вам необходимо вспомнить, «для чего» автор его создавал, вспомнить, что «не нравилось» автору в других платформах. В этом смысле, например, интересна история, как появился тот же Node.JS. Изначально хотелось сделать простой способ создания масштабируемых сетевых серверов, во что это выродилось в итоге, уважаемое хабрасообщество, я думаю, и так знает.

Поэтому я расскажу о проблеме «автоматизации бизнес-процессов» и появлении Business DSL.

Enterprise DSL(eDSL) или Business DSL (bDSL)


Основная проблема, которую надо было решить, на языке разработчика из 90-ых примерно звучала так:

Много людей, которые формируют множество пожеланий — все хотят автоматизации
select * from * as requirements
. Уходишь писать на C|C++ на три месяца, а они вечно чего-то требуют и не дают спокойно поработать. Вместе с этим большинство бизнес требований во-первых давно известны, во-вторых оперируют конечным количество объектов: «Ввести вводную справочную информацию, зафиксировать чего-нибудь, рассчитать чего-нибудь, вывести отчет о результатах расчета чего-нибудь» и большего как-бы не нужно.


Если, согласно ТРИЗ, идеальная система — это система, которой нет, а функции её выполняются, то идеальный DSL язык для этого казался примерно таким:





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

Можно кстати и на украинском, если пользователь хочет

//накидано навскидку, мог ошибиться в написании
Система = ВстановитиСистемуАвтоматизації();

Система.ЗапуститВведенняДовідковоїІнформації();
Система.ЗапуститиОблікПрибутковихНакладних();
Система.СтворитиСховищаДанихДляРозрахунку();
Система.СтворитиЗвітиДляПерегляду();

Система.ЗапуститиОператорівНаСкладі();



Как вы понимаете, в итоге даже сам пользователь может себя немного автоматизировать, если в школе изучал Basic. C таким вот посылом и создавалась обсуждаемая нами платформа, хотя как было в реальности — знают только её авторы. Дальше по тексту я буду называть эту платформу, иногда 1С, а иногда eDSL., чтобы вы привыкли к обоим понятиям и понимали, что я имею ввиду именно платформу, а не юридических лиц.

Повышение качества разработок и уровня разработчика


Но как вы уже поняли, за всё надо платить — наличие быстрой платформы для автоматизации бизнеса ведет нас к тому, что из фразы «быстро, дешево, хорошо — выберите любые два», платформа eDSL делает за нас выбор в сторону быстро и дешево. Таково её конкурентное преимущество. И если играть «в короткую» — это дает быстрый эффект, или наоборот быстрое понимание ошибочности процесса (что-то автоматизировали, не получилось, сделали по другому). Но в любом случае дальше потребуется развитие — а НЕ хорошие продукты развивать почти не получается.

Для того чтобы, ни в коем случае не терять скорость разработки конечных бизнес-систем, и сделать так, чтобы это было лучше (стало хорошо), единственное, что мы можем делать — это начинать делать НЕ дешево. А денег, как вы понимаете, нет, точнее их никто выделять пока не будет на повышение качества «некой» платформы, которая как-бы подразумевает, что в ней и так «всё качественно» (согласно маркетинговым материалам). Поэтому единственное, где мы можем увеличить затраты — это либо в зоне разработки инструментария для 1С платформы, либо в зоне развития навыков специалистов 1С. Собственно, как только мы начинаем задумываться о качестве решений, мы начинаем, как и все ИТ специалисты, пытаться ускорить/упростить наш процесс разработки, не теряя при этом эффективности для бизнеса. Как вы понимаете, такого функционала в платформе для бизнеса не будет — она же платформа для бизнеса, а не для разработчика.
К вопросу о том, что функционала не будет
И опять же я хитрю. На самом деле можно сказать, что «пока нет». А движение в этом направлении есть. Обычно всем интересующимся я советую на досуге почитывать Заметки из куллуаров (читать в порядке «от последней к первой» записи


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

Коллекция помощников в работе с исходными кодами


v83unpack (v8unpack-console) — выгрузка в удобном формате текущей разрабатываемой конфигурации

Когда у вас более одного разработчика 1С и более одного хранилища исходных кодов конфигурации для бизнеса, первые 2 проблемы качества, которые вы захотите решить:

  • привязка изменения кода к задачам, для последующего разбора проблемных ситуаций;
  • возможность быстрого code review, для выявления узких мест, до этапа развертывания у клиента/заказчика/etc.

про системы управления задачами
Глупо считать, что в среде 1С специалистов нет систем управления задачами. На текущий момент мне известно, что есть прецеденты промышленного использования:
1. Jira (Stash, Confluence), TFS2013
2. OpenProject, Redmine
3. Bitbucket, Github, Taiga.io
даже DevProm, и многое другое.


Как это работает?

C:\Program Files\1cv82\8.2.15.319\bin\1cv8.exe ENTERPRISE /F"C:\Users\admin\.jenkins\workspace\runTest1C\build\ibService" /Nadmin /P1 /DisableStartupMessages /Execute"C:\Users\admin\temp\ВыгрузкаКонфигураций.epf" /C"decompile;pathToCF;C:\1cv8.cf;pathOut;C:\repo\git\src;auto;out;C:\Users\admin\.jenkins\workspace\runTest1C\outExport.txt;"


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

Теперь «старшие товарищи» всегда видят некачественный код или не учитывающий подходов к правильной разработке



почему кстати Git
во-первых — только Git выдерживает объем исходных кодов ERP 2.0
а во-вторых — только у Git есть удобная концепция коллективной работы над множеством «контекстов» задач GitFlow, что для 1С специалиста является критичным, так как это позволяет управлять «хаосом требований от пользователя», не внося хаос в код.


precommit1c — фиксация внешних инструментов в git репозитории в виде исходников

Неправильно считать, что работа обычного разработчика идет только с хранилищем 1С, проблема качества в том числе возникает оттого, что большинство разработчиков пишет очень большое количество маленьких утилит в виде внешних файлов, предназначенных для запуска в среде платформы. Когда у вас один разработчик, тогда для версионирования Вас спасает Dropbox/YandexDisk/GoogleDrive/etc, но когда вы работаете в команде — тут опять нас спасает git и внутрикорпоративный или внешний git репозиторий.

Работа идет через клиентские «хуки» git и «внезапно» требует Python (хотя можно и на bash):

git clone ssh://git@dev.example.org/operational-managment/goods-trade ./my-goods-trade
git submodule add https://github.com/xDrivenDevelopment/precommit1c ./my-goods-trade/vendors/precommit1c
cd ./my-goods-trade/vendors/precommit1c
exec copy-to-hook.cmd
cd ../../
mkdir utils && cp /cygdrive/d/epfs/ТолькоЧтоСозданнаяОбработка.epf ./utils
git commit ТолькоЧтоСозданнаяОбработка.epf -m ‘это очень важная обработка’
git push --all

что тут происходит
По умолчанию я считаю, что хабрасообщество умеет читать командную строку, для остальных поясню:
0. Мы получаем текущие исходники конфигурации «для автоматизации торговли товарами» с нашего сервера исходных кодов git (полученный с помощью v83unpack);
1. Мы берем инструмент с проекта на github где ведётся его разработка и подключаем его в качестве дополнительного модуля git;
2. Копируем необходимые утилиты в сервисный каталог .git/hooks;
3. Копируем разработанную в 1С: Конфигураторе обработку в каталог с утилитами;
4. Помещаем в репозиторий и отправляем на сервер;
5. В репозиторий также автоматически помещается и исходный код утилиты.


Именно с помощью данного инструмента из обычной утилиты для 1С, это может стать целым проектом на github

Tool1CD — утилита для работы с хранилищами платформы без самой платформы

Одна из самых востребованных утилит в 1С мире, наряду с v8unpack-console, позволяет работать с хранилищами данных, как с базой данных, без платформы, в том числе и в консольном режиме. На ХабреДля1Сниковэта разработка входит в Top-20

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


Вот это да - у них базы разрушаются
разрушение и проблемные ситуации чаще всего связаны не с проблемами платформы, а с попыткой не вкладывать денег в аппаратные ресурсы. То есть — когда вместо того, чтобы настроить инфраструктуру под решение на 1С, база данных продолжает находится на компьютере формата “под столом” разработчика. Обычно я для аналогии пытаюсь привести пример из мира sqlite — представьте себе, с каким количеством проблем вы столкнетесь, если начнете использовать sqlite в качества средства хранения данных в системе с количеством одновременно работающих пользователей скажем 10 и размером базы от 1 Gb. Для желающих изучить это полезный, но болезненный опыт, начинать следует с того, что конкурентный доступ в таком случае крайне желателен в формате «много читающих — один пишущий».


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

Итак, теперь у нас есть полная история работы всех 1C разработчиков в git репозитории, причем, заметьте, без отрицательного влияния на сам процесс обычного «кодинга» на платформе.

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


Дальнейшее необходимо только в следующих случаях:

  • Конфигурация 1С решения будет существовать в вашей зоне ответственности длительное время — от месяца и более;
  • Вы пытаетесь внедрить у себя автоматизированное тестирование перед сдачей работ/системы внутреннему или внешнему заказчику;
  • Вы просто ИТ перфекционист.


Инженеры DevOps очень любят Chef, puppet, но совершенно не любят 1С, поэтому мы начинаем сами автоматизацию собственной деятельности.

1Script — уже известный проект на Хабре. Чтобы не повторять статью EvilBeaver, скажу лишь, что текущий результат в виде DSL языка для автоматизации работы «обычных» 1С специалистов выглядит таким образом:



xUnitFor1C — разработка через тестирование на 1С. Наиболее интересный с точки зрения повышения качества проект — так как дает максимальный эффект. Фактически является реализации спецификации xUnit с учетом специфики 1С, и требует отдельной публикации (которая будет следующей после нынешней). Ключевое, что здесь можно отметить — внедрение разработки через тестирование (TDD на 1С) требует наиболее высоких затрат не первом этапе: эффект наблюдается не ранее чем через 1.5 месяца.

Snegopat — свой ReShaper и не только.
тонкости проекта
Тут я вынужден сказать, что на данный момент «временно» развитие проекта остановилось. Так сказать «замерло» в ожидании — в том числе и по причине архитектурных проблем первой версии.


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

v8Readerпомощник объединения при разрешении конфликтов в коллективной разработке
v8Viewerпомощник, встраиваемый в том числе в TortoiseGIT, для сравнения версий 1С конфигурации находящейся в git репозитории

Такой он, «мир eDSL», где главное автоматизация бизнес-процессов, а всё остальное микросервисы и микроутилиты, выпускаемый под лицензией Apache Licence 2.0

Чтобы жизнь «малиной не казалась»


Давайте еще расширим свой кругозор в части гетерогенной разработки:

1С+OpenStack — отношение к 1С как к «пакету» для облачной платформы


1С+Docker — отношение к 1С как к «коллекции контейнеров».


Ну и конечно 1C+ logstash/kibana/elasticsearch — кроме просто журналирования, используется в том числе для BI.


где PHP ?
Обращаю Ваше внимание, что у меня предвзятое отношение к PHP, поэтому я Вам не могу дать ссылки на продукты, работающие с PHP в едином стиле учитывая возможности и 1С, и PHP, объединяя плюсы обоих платформ: моё личное мнение, что PHP — это Personal Home Page tools и не уверяйте меня в обратном.


В качестве заключения


В мире 1С разработчиков — я очень вас прошу обратить внимание именно на слово «разработка», как альтернативу словам «консультация и внедрение» — давно уже нет чистых специалистов 1С. Это, скажем так, миф из 2000-ых. Большинство программистов, кто профессионально создаёт решения на платформе 1С, «в базе своей» уже имеют один из старших языков: Java, C# или ruby, python — это требование бизнеса и никуда от него не деться, в том числе за счет огромного внутреннего рынка проектов стран СНГ. Ну и, конечно же, за счет очень динамичного развития самой платформы. С другой стороны, проблемы НЕ качественных разработчиков присутствует везде, в не зависимости от языка/платформы, и это уже уводит нас в область психологии и ответа на вопрос «почему люди не развиваются и почему люди в большинстве своём не понимают своего места в ИТ мире». Но это тема другой статьи и других методик/инструментов.

Вместе с этим, как обычно, учитывая открытость лицензий, сообщество github.com/xDrivenDevelopment открыто для новых идей и утилит в рамках концепции взвешенного подхода к eDSL платформам — как раз без тех самых революций, о которых сказано в заголовке.

FAQ


Q: Причем здесь Agile?
A: eDSL за счет концепции в принципе «сам по себе Agile» (RAD платформа), в его концепции не заложено ничего про QA (управление качеством продуктов) — поэтому при внедрении гибкости на 1С, следует ключевое внимание обращать не на «демонстрацию заказчику», а больше на внедрение инженерных практик.

Q: Как это всё начать использовать? А то «наши 1С» специалисты @cencored@
A: Скачать, установить сервер сборок (Jenkins|Teamcity), запустить по ночам компиляцию решения («синтаксический контроль кода») с помощью скриптов 1Script. Поделиться с командой наработками. Настроить репликацию исходных кодов 1С в git. Прийти на AgileDays2015 — посмотреть как использовать статические анализаторы кода.

Q: А сколько денег это стоит?
A: Лучше подумайте сколько это экономит на длинных проектах 1С.

Q: Но это не соответствует стандартам 1С?
A: Эти инструменты автоматизируют стандарты и расширяют их. В большинстве проектов на github вы найдете прямые ссылки на информационно-техническое сопровождение и базу знаний 1С.

Q: Зачем всё это нужно?
A: Быстро, дёшево и хорошо — выберите любые два и второй тезис Жизнь слишком коротка, чтобы делать что-то вручную.

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 44

    0
    Выглядит как-то противоестественно, копаться в кишках конфигураций строительным инструментом (пусть даже стерильным).

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

    Руководитель проекта только один, он может заменить любого, вносит все изменения в рабочую базу и несет ответственность за качество работы. Остальные ему помогают в зонах своей ответственности. Чтобы не было внутренних разборок и поисков виноватых. А для этого вполне хватает стандартных средств разработки.
      +1
      Да, такой подход имеет право на жизнь, особенно когда бизнес-конфигурация единая и большая, а команда цельный (построенный) организм.
      В таком случае действует Ваш подход — так называемая коллективная разработка на доверии, точнее на соглашениях: иногда эти соглашения в том числе фиксируются в бумажном виде с надписью «Утверждаю: Положение о разработке системы».

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

      В итоге всё обычно спокойно и замечательно но совершенно медленно

      Working Cycle надо подсчитать. То есть среднее от (DeployAndStartTime — RequestCreationTime) в таком случае чаще всего начинается от 100 дней (для конфигураций имеющих сильный процент доработки и для сложных типовых решений, в которых очень «страшно» вносить изменения). Такая цифра «нарисуется» конечно не сразу, а где-то скажем за год жизни системы.

      Инструментарий же разработан в качестве ответа на проблематику:

      1. когда мы начинаем работать короткими итерациями по блокам работ
      2. когда вероятность рефакторинга очень высока, или вероятность необходимости обновления на новый релиз от стороннего вендора средне высокая
      3. когда уровень развития алгоритмического мышления конкретных «кодеров» низок
      4. когда количество прецедентов нарушения соглашения о зонах ответственности превышает «один в неделю»
      5. когда тестированием занимаются обычные пользователи
      6. когда количество заявок на поддержку системы в среднем на одного пользователя составляет «1 заявка на пользователя в неделю»
      7. когда системы имеет интеграционные адаптеры
      и т.д.

      Это просто другой подход.
        0
        Ваш подход — так называемая коллективная разработка на доверии

        Никакого доверия, всегда есть один ответственный, не зависимо от партнерских договоров и поставленных задач. А то начинается: — Эту функцию писал Дима, но он сейчас в отпуске, а Таня сейчас помогает Саше, поэтому Илья ничем не может вам помочь.

        Я так понимаю, что ваш подход — опередить всех конкурентов не вникая в детали, подогнать результаты под тесты, и срубить бабло в кратчайшие сроки с минимальными затратами?
          +3
          Жёстко вы выводы делаете: «опередить конкурентов...» «бабло...» «результаты под тесты...».
          Хамство штука обоюдоострая, и одновременно похожа на бумеранг. Надеюсь Ваш комментарий это просто гипотеза, а я недостаточно подробно отразил описание инструментария и его цели.

          Попробую еще раз донести в порядке ответа на критику: давайте Вы еще раз попытаетесь понять, что я говорю об инструментах и утилитах помогающих команде разработчиков, а НЕ о процессах которые навязывает или не навязывает руководитель проекта

          1. результаты под тесты нельзя подогнать, тесты пишутся ДО возникновения результатов — такова парадигма проекта xUnitFor1C

          2. привязка кода к задачам через git — это практика возможна, когда кто-то эти задачи/блоки работ/подпроекты создал, а создаются они в процессе работы методологов, аналитиков и продажников по техническим заданием или коммерческим предложением: которые работают в 1С совершенно по другим принципам. Там оценка проекта, согласование, обследование и много интересных вещей (которые в статье принципиально не отражены). Но и здесь есть уже наработки по автоматизированному сбору требований и автоматизированному же тестированию (я про 1С говорю) — есть даже автоматический расчётчик требований для гос.тендеров: видел я и такой прототип инструмента.

          3. практика code review опять же внедряется когда проект уже продан и ведется его активная разработка: не будете же вы «нести» заказчику код, который потенциально может вызвать у него негатив.

          4. Ответственный за участок кода (объект метаданных) выявляется не на основании «бумажек-регламентов» или мнения «диктатора проекта», а на основе git stats который беспристрастен «до невозможности».

          5. автоматизированный сервер каждую ночь проверяет стабильность проекта — поэтому никакой Вася в отпуск не уйдет если развалил сборку. А если умудрился развалить сразу перед уходом в отпуск — то узнает об этом автоматически.

          6. никто из 1С ничего НЕ делает вручную — для рутины максимально применяется скритинг на 1Script

          P.S. К сожалению Вы скорее всего по ссылкам даже не пошли — самое главное, что ВЫ не поняли: основные участники проекта Github либо штатные разработчики в конечным компаниях (а не софтверных), либо занимаются разработкой тиражных продуктов на 1С — поэтому я и говорю, что им нельзя разрабатывать по-другому, в перспективе «они проиграют».

          Но опять же Ваш подход сейчас в 1С мире главенствующий… пока… я думаю до версии 8.3.7
      0
      «разрушение и проблемные ситуации чаще всего связаны не с проблемами платформы, а с попыткой не вкладывать денег в аппаратные ресурсы» — видимо вы издеваетесь, файловый режим 1С способен упасть на ровном месте, если нет, то из-за использования в сети, если нет из-за обмена данных, и т.д…

      Что касается денег, 1С Сервер должен входить в платформу, мне очень сложно объяснить иностранному клиенту, не знающему ни русский язык, ни Фирму «1С», почему он должен доплачивать 1000 Евро за то, чтобы база не упала или чтобы бух.отчеты выдавали правильную информацию, хотя у него не ERP, а всего лишь небольшой магазинчик на 2 клиента!

      1С должна продаваться с клиент-серверным вариантом по умолчанию по цене простой лицензии.
        +1
        я совершенно НЕ издеваюсь. Не было такой цели, и уж тем более такого желания.

        В вашем случае — причем здесь 1С, как компания или как инструмент — при высокой конкуренции за файл ЛЮБОЙ базы, sqlite вам в пример, когда клиенты работают с файлом базы по локальной сети, «записывающий» пакет по TCP может быть инициатором разрушения за счет самой сети — примеров с Sqlite масса, когда клиенту позволяют писать напрямую, без сервера. Если у Вас стояли SSD диски и база не резервировалась (пусть простым копированием файлика) и вы нарвались на «плохой блок» когда место на SSD закончилось — тоже получите разрушенную базу.

        Это опять НЕ относится к инструментам, это относится к production окружению или к инфраструктуре и ее настройке.

        Вот по Вашему примеру (по памяти)

        1. 1С сервер входит в платформу, не входит только лицензионный ключ
        а. linux сервер для старта поддерживает клиентских 12 соединений.
        б. Windows сервер 1C для своего запуска требует покупки лицензий в том числе на сам Windows Server (там еще AD настраивать и вообще еще много чего делать по инфраструктуре — обычно люди любят RDP сервер настраивать)
        в. существует лицензия на мини-сервер 1C и она уже стоит по моему 300 Евро.

        например пост на Хабре habrahabr.ru/post/224327/ достаточно быстро «гуглится» на эту тему
        Но это для тех, кому кровь из носу подавай клиент-сервера.

        Для тех кому желательно обеспечить стабильную работу двух пользователей действует следующая конфигурация «виртуальной машинки» для старта (напишу в *nix стиле)

        0. nginx на порту 80
        1. 3 службы * Apache на портах 8080, 8081, 8082
        2. /var/onec/data смонтированный с быстрого блочного устройства (пишу в Linux стиле — в Azure можно по другому)
        3. <бэкапирование файла базы данных>
        4. ssh-mount ./system-to-update ssh:/onec-virtual.example.com/var/onec для обновления конфигурации
        5. ну и конечно VirtualHost на всех трёх Apache серверах /two-users-system 1SHandler /var/onec/data

        такой вариант немного похож на хостинг небольших Rails приложений.

        все клиентские места работают через тонкого клиента, где сервер базы данных в файловом режиме имеет endpoint вида — onec-virtual.example.com/two-users-system. Такая конструкция еще с 2006 года показывает свою стабильность — здесь комплектом сервера приложений выступает связка nginx+Apache's.

        То есть проблема решается НЕ обвинением 1С или попыткой попросить заказчика потратить 200.000 рублей на покупку сервера 1С, а подходом к настройке Production окружения.

        И давайте не будем забывать, что можно купить в режиме сервиса 1С в облаке и вообще «не парится», пока доработки не нужны, а когда нужны — заказать хостинг 1С решений. А про «на ровном месте способен упасть» — я с Вами не соглашусь: это как-то голословно. Надо сходить на Bugtraker 1C и посмотреть текущие зарегистрированные ошибки — может там что еще появилось.

        то есть для 1С «для двух пользователей в небольшом магазинчике» — большой вопрос к тому кто им разворачивал 1С решение — именно поэтому я и написал в статье: базы рушатся не потому, что файловый режим плохой, а потому что и в файловом режиме нужно немного подумать о окружении в котором будут работать люди. И мне всё также непонятно — причем здесь файловый режим.
          –2
          Доброе утро,

          именно 1С тут притом, что за долгое время работы в Франчайзи я видел множество случаев падения файловых баз не только из-за сети, тогда как sqllite (неудачное сравнение вы выбрали) используется во всех браузерных движках, в продуктах Adobe и даже как журнал логов в 1С, видимо незря? Еще 1С притом что вы тут интересно рассказываете про утилиты к платформе 1С, которые могли отпасть, если бы Фирма 1С предоставила «здоровый» механизм api и открытый формат проекта (хорошо хоть доработали Хранилище).
          Ну и насчет SSD это вы вообще загнули, вот оно значит требование по вашему к нормальной работе платформы!

          «Это опять НЕ относится к инструментам, это относится к production» — мне вот интересно как вы будете продавать 1С где-то в сельском магазинчике, с недорогой железом, и кассовым аппаратом без сети и без интернета, как вы объясните хозяину что остатки показывает неправильно из-за плохого production, и ему лучше бы купить SSD + 1С Сервер (или мини сервер)?

          А насчет этих «сказок» о бесплатной 12-юзер лицензии на Линукс-поставку, думаю 1С уже давно развеяла этот миф четко дав понять что это «недокументированная возможность» и лицензирование такое же как на Windows (даже если нет проверки на лицензии до 12 пользователей), а вы опять даете «костыли» и вводите в заблуждение.

          «существует лицензия на мини-сервер 1C (который наконец-то появился а 2013 году) и она уже стоит по моему 300 Евро» — ну это же не бесплатно? 300 + 100 уже 400 евро на просто на минимальный вариант БД (файловый я не беру в расчет) + ХХ евро что останется несчастному франчу, тогда как 1С за несотоятельностью обеспечить нормальную работу файлового варианта должна давать сервер бесплатно, т.е. вкл. в поставку давая возможность выбрать пользователю что он хочет.

          «Для тех кому желательно обеспечить стабильную работу двух пользователей действует следующая конфигурация «виртуальной машинки» для старта (напишу в *nix стиле)» — хоть виртуальная машина это не «продукт с коробки», но все равно спасибо за идею.

          «И давайте не будем забывать, что можно купить в режиме сервиса 1С в облаке» — ну я это и указал выше.

          «я с Вами не соглашусь: это как-то голословно. Надо сходить на Bugtraker 1C и посмотреть текущие зарегистрированные ошибки — может там что еще появилось.» — этот вопрос я бы оставил нашим менеджерам по продажам и тех.поддержке (кто в армии служил тот в цирке не смеется), но фирмы уже нет.

          P.S.
          За много лет внедрения 1С зарубежом СНГ, создалось чувство, что Фирма 1С сильно не старалась сделать платформу «надежным» продуктом (либо не вкладывала ресурсы в программистов), так как в СНГ в своей нише она лидирует с большим отрывом, и второй фактор советского человека, который любит все что-то изобретать, чтобы выйти из ситуации (всякие утилиты и лазейки тому доказательство), а так же ценовая политика за клиент-сервер. Хотя в последнее время ситуация заметно улучшилась, все же эти факторы к сожалению долгое время говорили не в пользу 1С. Европейцы не любят и не хотят костыли, они любят надежность, и им все равно, это 1С Предприятие или Microsoft Acces. На рынке множество своих решений построенных на Visual Studio + MSSQL по ценам 20-300 евро более надежных чем файловый вариант 1С.
            0
            1С уже давно развеяла этот миф четко дав понять что это «недокументированная возможность»


            Это где такое 1С сказала? Вполне себе нормальная документированная маркетинговая попытка распространить связку 1С+Postgre и собрать фидбек.

            Сервер 1С под линукс бесплатен на 10 соединений (или 12, если верить автору статьи, я точно не помню).

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

            Опять же, в статье для магазинчика приведен пример с nginx вместо сервера. Он бесплатен
              0
              1.UPD. from Thug21
              клиентские программные и аппаратные лицензии расходуются по разному в клиент-серверном режиме.
              -Программные расходуются на каждое подключение
              -Аппаратные на компьютер.
              UPD от sales@1c.ru
              техническая возможность работать без ключа не ознячает юридического разрешения это делать. Закон о правовой защите информации для ЭВМ запрещает использовать любые программные продуктыв, правообладатель которых не декларирует их бесплатность (а мы нигде не объявляли этот сервер бесплатным).
              С уважением, менеджер отдела продаж Виктор Быков
              Убедительная просьба сохранять историю переписки при дальнейших обращениях.

              2. 12 соединений, в версии 8.2.

              3.nginx ставить в магазинчик? а тех поддержку кто будет делать, Фирма 1С с Москвы или франчайзи нанимать *nix специалиста? И как объяснить директору магазинчика что ему нужно платить за установку линукса / nginx? Неужели в РФ все так работают, насколько я знаю большинство Франчайзи из РФ вообще не пытаются менять типовые продукты 1С и просто их обновляют. Давайте еще придумывайте оправдания и решения инвалидному формату файлов в 1С.
                +1
                Техподдержку nginx? Вы серьёзно? У вас на каждую программку будет своя техподдержка?
                Директор заказывает решение — за Nginx он не платит. И вообще причем здесь 1С. Это вообще другой уровень услуг — ИТ информационные услуги: в пакет может быть включен 1С, а может быть и не включен.

                Типовой франчайзинг потихоньку в РФ умирает — никому больше не нужны обновляторы 1С.
                  0
                  Да, нужна тех поддержка любого продукта установленного руками франчайзи, т.к. потом будет заключен контракт. Руководитель фирмы не будет разбираться что это, Linux / Postgre / 1С.

                  «И вообще причем здесь 1С.» — если вы берете на себя Nginx или любой другой продукт вам все равно придется обеспечить работоспособность все связки файл-серве (клиент-сервер) + 1С решение + клиенты. Либо искать на стороне 3d party.

                  Обновляторы 1С никогда не умрут, потому что законы часто меняются и базы иногда бывают нетиповые, но тенденция с вводом «расширений» идет к тому.
                  0
                  Никто и не придумывает оправдания. Вместо оправданий обычно эффективнее искать (и даже предлагать) решения. Формат инвалидный? Не пользуйтесь им. Настройте nginx или купите минисервер. Сама схема файл-сервера, когда приложения по сети пишут в один файл, содержит массу потенциальных проблем по надежности. Какие-то базы надежнее, какие-то нет, но риск есть в любом случае.

                  Фирма-вендор ориентирована на бизнес, а не на разработчиков. Поэтому инструменты разработки сильно отстали. Можно не ждать милостей от судьбы, а создавать (и предлагать) инструментарий, которого нет в оригинальной платформе. Тут дело в подходе. Можно ныть «все плохо», а можно решать бизнес-задачи и извлекать выгоду даже из того, что есть. Причем без ущерба для процессов именно разработки (git, code-review, unit-testing и т.п.)
                    0
                    «Можно ныть «все плохо», а можно решать бизнес-задачи и извлекать выгоду даже из того, что есть. Причем без ущерба для процессов именно разработки» — у меня конкретная претензия в надежности к платформе, и том что вы вводите в заблуждение непосвященных. Не думаю что тут собираются «ноющие» людю.
                      0
                      Раскройте мысль, пожалуйста, где именно вы видите ввод в заблуждение?
                        0
                        1.«Вот это да — у них базы разрушаются»,
                        2.комментарий насчет «linux сервер для старта поддерживает клиентских 12 соединений»
                        В остальном благодарю автора, я еще пол года назад по его рекомендации начал использовать bitbucket+1C, и к вам претензий не имею, если вас все устраивает, наслаждайтесь.
              0
              Только что вычитал с сайта 1С о «Мини сервере»:

              «Данный продукт можно рекомендовать, например, для автоматизации кассового терминала, где необходимо обеспечить повышенный уровень отказоустойчивости, а также небольшого офиса или торговой точки с количеством рабочих мест не более пяти.», фактически они сами признают что уровень надежности повышается с использованием сервера, а для остальных кому не нужно 5 пользователей или нет бюджета на них, нужно брать SSD + виртуальную машину на линуксе и читать мантру.
                +3
                Как иногда тяжело говорить на разных языках но я попробую. Для вас 1С — это фирма. Для меня некая платформа условно-открытая. Состоящая из «программок», «библиотечек» и «службочек», работающих в конечном количество «окружений».

                Ваши тезисы в целом относятся к вопросу администрирования и поддержки — «службочек и программок». И еще к архитектуре компонентов. Для меня нет разницы между сервером Tomcat, сервером Thin и сервером — в принципе они одинаковы, просто у каждого есть тонкости. Для меня нет разницы между sqlite и файловым контейнером 1С. Для меня нет разницы между описание метаданных в проекте Apache Cayenne (будь он неладен) и в Конфигураторе 1С. Эргономика и быстрота это дело 10-ое, главное концептуально-базисное отношение.

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

                Что касается типового 1С франчайзинга — развести ИТС и установить 1С. То тут у меня большие вопросы не к 1С, а к владельцам таких «франчайзи».
                1. берете людей на поддержку, ставьте мониторинг (автоматизированный).
                2. разворачиваете базу данных — будьте любезны обеспечить FULL RECOVERY модель восстановления, и нечего на вендора пенять. Хоть dropbox поставьте у клиента для файла 1Cv8.1cd — но полную модель восстановления обеспечьте.
                3. выбираете архрешение о кассовом ПО — будьте любезны нести ответственность за то, что не предусмотрели тот факт что пользователи 1С «тяжелые» и фактически генерируют на базу OLTP и OLAP нагрузку одновременно. Поэтому 5 пользователей 1С иногда соизмеримы со 1000 пользователей Web.

                Что касается сельских магазинов — как будто никто этого не делал. Там где в сельских последних наше доблестное государство дотянуло ADSL: там один способ автоматизации, там где нет — другой. Кстати безкомпьютерную автоматизацию еще никто не отменял — иногда она дает лучший эффект.

                А статья вообще о «разработке» и отношении к конфигурации 1С как «к исходному коду», который надо будет рефакторить и делать ему «build, test and deploy».

                Чтобы ВЫ понимали масштаб трагедии — с тем же хранилищем 1С, я в коллективной разработке не пользуюсь. Нам уже наплевать — мы с git работаем. А функционал в утилиту v83unpack был добавлен для команд переходящих на git чтобы сделать переход безболезненным.
                  0
                  Фирма 1С для меня как поставщик платформы, поэтому и возникает вопрос к качеству и цене.

                  А что касается мои тезисов, они касаются комментариев, которые вы вставили в статье вводящих в заблуждение, не более того. Ценность самой статьи очень высока я ее добавил в избранное, спасибо.
                    0
                    Чтобы ВЫ понимали масштаб трагедии — с тем же хранилищем 1С, я в коллективной разработке не пользуюсь. Нам уже наплевать — мы с git работаем.

                    Алексей, вы упоминали в статье ERP 2.0. В связи с этим у меня вопрос — вы как-то боретесь с большим временем загрузки/выгрузки конфигурации (а я так понимаю — это единственный способ работать напрямую с git, не используя хранилище от 1С) или же просто смирились? На сегодня эта проблема — единственное, что меня заставляет пользоваться хранилищем.
                      0
                      C ERP 2.0 спасает git-flow

                      0. как только я начинаю работу я делаю git-flow new-feature
                      1. как только я закончил разработку на своей ветке в конфигураторе
                      2. я запускаю на локальной машине сборку и проверку моей версии — он делает:
                      а. запуск тестов с тестовыми данными
                      б. синтаксический контроль и проверку предупреждений кода
                      в. если все корректно, то запускается разбор на исходники
                      г. исходники через git pull request помещаются центральный репозиторий для согласования

                      * длина работы над одной «фичей» обычно от часу до двух", значит минуту на сборку и 3 минуты на разборку я могу и потерпеть.
                      * каждая новая «фича» — это ветка исходников

                      git-flow new feature — берет текущий develop, собирает из него CF файл, инициализирует чистую базу для разработки

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

                      здесь очень быстро себя ведет github.com/xDrivenDevelopment/v8unpack-console
                      с GCC и Boost

                        0
                        Спасибо! Попробуем применить в наших реалиях.
                  0
                  Посмотрел ваше интервью в инфостарте, было очень интересно, понравилось ваш девиз насчет решения любыъ проблем.
                  0
                  Вклинюсь в обсуждение как практик внедряющих маленькие и большие магазины.
                  Я так понимаю вы собираетесь кассу пускать в базу через сеть? Или несколько касс будут периодически что-то спрашивать у базы лежащей в шаре. Я вам категорически не советую вообще завязывать кассы на сеть.
                  Одно если у вас в кассе порядка 100 000 товаров, тогда 3-4 кассы одновременно «заглянувшие» в базу за поиском цены или записью чека положат друг друга блокировками, другое что кассир наступив случайно на сетевой провод или сгоревший роутер выведут из строя весь ваш магазинчик.
                  Решение: кассе дают свою базу и она с ней возится сколько хочет. Делаем периодические обмены раз в час — раз в день и профит.
                    0
                    Для 3-4 касс и 100К товаров я и не начну работать с клиентом, если он не согласен купить 1С сервер хотя обмен данными тоже приемлемый вариант.
                      0
                      Простите а можете аргументировать необходимость сервера в примере с 3-4 кассами?
                      Во фронт офисе стоят кассы, в бэке все работают в терминале.
                      1 человек делает приходы
                      1 человек переоценку и заказы поставщикам
                      плюс еще 1-2 человека бухи, управленцы.
                      Если уж база совсем пухлая положите ее на SSD и все норм.
                      Когда же с базой работают > 10 касс и приходы / заказы вбивают > 10 человек тогда стоит обращаться к серверному варианту (конечно все зависит от количества строк в документах и интенсивности их ввода)
                        0
                        «в бэке все работают в терминале» — это уже значит затраты на настройку и лицензии для Windows Server + клиентские.
                        Так как вы указали что товаров будет 100 000, я сделал предположил, что объем данных тоже будет не маленький. Нетрудно сделать вывод о конфликтах которые могут возникнуть при работе все клиентов одновременно с одним файлом, может быть они проработают год без проблем, может 2, пока не начнут возникать битые ссылки, либо неправильные итоги по регистру бухгалтерии, либо торможения. Это не надежное решение.
                          0
                          Раз мы говорим о торговле, то думаю стоит уточнить следующее:
                          1. Мы работаем на типовом решении 1С УТ
                          2. Фронт для простоты решения тоже делаем из УТ (хотя можно взять и «Розницу»)
                          3. Да в Бэк офисе при работе нескольких человек придется ставить терминальный сервер, это условие быстрой и безопасной работы. 1С УТ при работе через расшаренный каталог уже при 3 пользователях начинает безбожно тормозить.
                          Но вот для чего к этому еще докупать SQL и 1C сервер я не понимаю.
                          При корректном ведении базы битые ссылки не появятся, а регистры бухгалтерии нас не тревожат т.к. это УТ. При некорректном использовании битые ссылки будут и в серверном варианте, который не спасет и от кривых итогов. Может я ошибаюсь но формат хранения данных не влияет на корректность (по крайней мере в данном случае), а лишь расширяет возможности по совместному использованию данных.
                            0
                            Значит, по вашему если я хочу работать со «стандартным» пакетом 1С, я должен:
                            1.Не использовать бухгалтерию
                            2.Фронт должен быть попроще
                            3.Нужен докупить Windows Server + лицензии и настроить терминал, возможно еще и с AD.
                            И после этого всего при «корректном ведении базы» проблем возможно не будет, но тормозить безбожно будет. Вы сами ответили на свой вопрос.

                            P.S.Формат хранения влияет на множество функций 1С, запросы, работа с файлами, управление соединениями.
                              0
                              Не совсем так
                              1. Используем, но обычно в нее выгружают отдельно за прошедший месяц/неделю/день и за нее отвечает 1 бух (у нас же маленький магазин/сеть)
                              2. Да фронт должен быть по функционалу минимально достаточным
                              3. При условии работы одновременно нескольких сотрудников в бэк-фоисе

                              Тормозить не будет, и не надо докупать лицензии на 1С сервер и SQL

                              Для пользователя формат хранения не важен, как выполняется запрос — ему абсолютно безразлично, важен результат. А результат будет одинаковым. Время получения результата при работе до 10 пользователей не изменится. Профит!)
                      0
                      Я полностью с Вами согласен — кассовое ПО, должно иметь свой «горячий» кэш данных, совершенно не зависящий от центральной системы. Причем для меня кассовое ПО — это вообще преднастроенный образ операционной системы с необходимыми пакетами (msi, deb, rpm) и всеми возможными политиками. Такой подход еще называется EmbededPOS.

                      С другой стороны — в своей практике мы всегда отказывались от bulk (больших) обменов «раз в час» и руководствовались практикой «любое событие на кассе или для кассы» кладется в очередь доставки и отправления. Такой подход мы еще называли «позиция чека в центре через секунду». Разрабатывать такое чуть дольше чем обмен через ПланыОбмена, зато работало стабильней.

                      Что касается цен — то тут тоже весело: кассе нужна только та цена, которая висит на ценнике, а ценники вешают люди — поэтому пакет данных с новыми ценами «ехал» на кассу, когда сотрудник давал отмашку «применить цены на кассах», что означало что он зуб дает, что «повесил ценники».

                      Но это всё применимо когда функционал кассы «конечен» — в продуктовом магазине например. А вот когда кассовое место становится местом работы менеджера с клиентами, то тут количество доработок функционала было настолько большим (чаще всего новые требования генерируют маркетологи, или тот кто себя таким считает"), так вот — доработки настолько часто требовались, что работал другой подход, не EmbededPOS, а ThinClient. То есть на рабочем месте все также был преднастроенный образ «операционки», но там стоял только тонкий клиент, и уже брался мини-сервер. Чтобы cf файл для обновлений был один и чтобы можно было выполнять нормально фоновые и регламентные задания, коих обычно множество — электронные очереди, заказы с сайта и т.д. В этом случае инфраструктурно брались бездисковые рабочие станции и какой-нибудь HP MicroServer или Barebone Shutle (хотя иногда покупались даже No-name micro сервера из Китая, когда хотелось ну очень дешево)
                        0
                        Интересное решение по поводу очереди доставки.
                        Но я приверженец независимого фронта. В свое время я автоматизировал рестораны. В фронт офисе был ПОС с DOS и клиентом tillypad. Фронт получал данные напрямую из бэк офиса. Но проблемы с сетью укладывали сразу все ПОСы и чеки в ручную.
                        Проблема с заменой ценников тоже присутствует, но сейчас появились электронные ценники которые помогают решить эту проблему.
                    0
                    Пренебрежительно относиться к PHP — это такой тренд. Не отрицаю.
                    Но пренебрежительное отношение к 1С еще более острая проблема. Не важно обоснованно это или нет, насамом деле необоснованно, так как у системы 1С фактически нет аналогов, в ее ценовом диапазоне и по функционалу. У вас отличная статья, в 1С многое изменилось с тех пор как я получил свои сертификаты (Проф, Спец и даже Эксперт) рад что платформа развивается. Только мне не понятно одно, зачем же уподобляться хейтерам и так же как и они, пренебрежительно относиться к PHP?

                    Personal Home Page

                    Because fuck you that's why. ©

                    Вот информация о названии этого языва программирования:
                    Этот совершенно новый язык был выпущен под новым именем, без упоминания о персональном использовании, как в PHP/FI 2.0. Он был назван просто «PHP» — аббревиатура, означающая рекурсивный акроним — PHP: Hypertext Preprocessor.
                    via http://php.net/manual/ru/history.php.php
                      +1
                      Да нет, это мой личный опыт. Никого не хотел огорчить — написал же: не переубеждайте.

                      Ну не получилось у меня «жить в дружбе с PHP» — с остальными языками я понимаю применимость, а с PHP у меня в опыте всегда какой-то «негатив». Поэтому моё отношение и не меняется — история мне прекрасно известна. Будет удачный опыт — я первый скажу, что был не прав: я имею ввиду удачный опыт синергии 1С+PHP для конечных пользователей, а не для души.

                      Мне не удалось найти удачных примеров синергии 1С+PHP за исключением 1С+OpenCart проекта github.com/zenwalker/opencart-exchange1c
                      но даже он вызывал увеличение общей стоимости владения комплектом решений на порядок.

                      Хотя мои знакомые Web разработчики мне всегда говорят, что на самом деле всё тоньше и PHP тоже надо уметь использовать — у меня не получилось. В чём я официально признаюсь.
                      0
                      А нельзя ли поподробнее об интеграции журнала 1С и Logstash?
                        +2
                        ну тут поподробней достаточно сложно, пока еще.

                        но попробую

                        1. начиналось всё вообще с HiVE ODBC и автоматизации в части аудита систем youtu.be/gx2xZbIQQ-A?t=23m59s
                        2. HiVE как и Hadoop оказался очень тяжелым к установке и запуску для небольших 1С команд.

                        в итоге Евгений Сосна немного адаптировал эту связку под быстрый запуск (по скорости внедрения на текущих системах)

                        Поэтому сделано было немного по другому:

                        1. был сделан плагин для Logstash — gist.github.com/pumbaEO/092511e0fbf55a6905fe для использования журналов в sqlite в качестве input
                        2. настройки input в прототипе были

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

                        1. во-первых чтобы вся связка logstash+elasticsearch+kibana работала через docker williamdurand.fr/2014/12/17/elasticsearch-logstash-kibana-with-docker/
                        2. во вторых, чтобы журналы «забирались» автоматически через стандартный LamberJack github.com/elasticsearch/logstash-forwarder
                          0
                          здорово, спасибо что поделились, попробую у себя
                        0
                        Классная статья!
                        Работаем в двоем с человеком над небольшим 1С-проектом и ужасно хочется попробовать использовать ваш инструментарий и вообще разобраться с GitHub'ом.

                        А можно надеяться на статьи от вас о 1С+Docker и 1С+OpenStack?
                          0
                          Можно.

                          Но первая будет точно про Docker — с ним уже всё понятно: как только мы туда одну маленькую «killer feature» добавим в части балансировки и масштабирования и будут готовы Dockerfile'ы c ней и с fig настройками: тогда и опубликуемся.

                          Про OpenStack будет позже — там есть тонкости с Murano пакетом, да и не только. Принципиально удалось запуститься только 31 декабря совместно с Ильёй Алексеевым, там еще много чего нужно исследовать.
                            0
                            Учитывая внутреннее голосование решили пока ограничится малым — опубликовать видео-курс про разработку и про xUnit infostart.ru/public/328695/
                              0
                              Да, уже видел, буду смотреть курс, пробовать.
                              Спасибо!
                            0
                            Спасибо за статью! Надеюсь, с выходом 1С Development Tools в сфере 1С разработка качественно изменится, все это перестанет быть сложным и заоблачным.

                            Увидев анонс на Зазеркалье о возможности выгрузки всей конфигурации в файлы мы тоже захотели начать использовать Git в разработке 1С — это решит кучу существующих проблем.
                            Но, к сожалению, в алгоритмах выгрузки/загрузки все еще есть ошибки, которые не позволяют нам пока использовать эту возможность по полной. Даже недавно вышедшая 8.3.7 их не исправила. Вы используете сейчас механизм выгрузки конфигурации в файлы или все еще пользуетесь v8unpack?

                            Вы много написали про выгрузку конфигурации с помощью v8unpack, но ничего не написали про загрузку. Один из мощнейших возможностей Git является удобство merge. Вы не используете сборку конфигурации из репозитория, только выгружаете в репозиторий для просмотра/тестов/ревью?
                              0
                              Сразу отвечу по пунктно, причем с начала:

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

                              2. что касается выгрузки в исходники — это наша вина, сообщество слегка запутало людей в наименованиях
                              * v8unpack (unpackv8) — консольная утилита на С++ предназначеннная для прямого чтения потоков из CF файлов — исользовалась для чтения конфигураций версий 8.2
                              * v83unpack — консольная утилита запуска выгрузки в исходники средствами 8.3 и v8unpack с корректировкой формата хранения и хотфиксами ошибок при выгрузки ( в основном связанных с перегенерацией служебных GUID)

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

                              Причем в командах разработки — именно code review даёт максимальный эффект. Что такое тесты мне неизвестно, потому что тестов нет ;-)

                              А вот сборка — это «высший пилотаж», по нескольким причинам. Хотя мы и используем git именно для merge и сборки получившихся артефактов, другим мы пока это не рекомендуем — это окупается только тогда, когда вы разрабатываете продукты, а не когда занимаетесь внедрением.
                                0
                                Забыл сказать.

                                Сейчас существуют 2 продукта с одной кодовой базой

                                * github.com/EvilBeaver/oscript-library/tree/develop/src/gitsync — делается в виде библиотеки, в рамках популяризации 1Script EvilBeaver
                                * github.com/silverbulleters/vanessa-unpack — преследует цели внедрения практики code review как таковой в среде 1С разработчиков

                                Как только будет готова библиотека gitsync vanessa-unpack на неё плавно смигрирует github.com/silverbulleters/vanessa-unpack/issues/6

                                Поэтому — мы сейчас советуем переходить именно на вышеуказанные продукты, учитывая что они базируются на штатном функционале платформы, только «на стероидах»
                                  0
                                  Алексей, спасибо, изучаем присланное вами
                                  Мы специализируемся именно на разработке, поэтому вещи, этому помогающие, нам интересны в первую очередь: DevTool, branches, builds, etc

                            Only users with full accounts can post comments. Log in, please.