CI/CD для 1С - миф или реальность?

Управление - Управление проектом

CI/CD DevOps EDT GitFlow Хранилище Git

66
Разберём плюсы и минусы применения практик CI/CD с учетом ограничения технологической платформы 1С:Предприятие.

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

Отдельные практики DevOps дошли сейчас даже для 1С. В частности – много внимания мы уделяем сейчас CI/CD. Но давайте разберёмся – что реально может дать CI/CD команде разработки 1С. С точки зрения «Best Practice», конечно, этим заниматься надо, но откуда берётся эффективность? 

Откуда взялось CI/CD? Какие задачи при помощи них решали?

Для начала несколько лирическое отступление на тему «откуда пошло CI/CD». Очевидно, что CI/CD пришли к нам из других направлений разработки, в частности из Web команд, как и множество других инноваций. Как работают Web команды? Примерно вот так:

Суть в том, что одну фичу может делать 2-3 человека. Как минимум принято разделять Frontedn и Backend разработчиков. В нормальной команде существует ещё DBA или разработчик БД, отдельный дизайнер и отдельный верстальщик, не говоря уже о наличии QA как такового. И где тут проблемы? 

Дело в том, что при подобной разработке часто одну и ту же фичу разрабатывают разные люди. Представьте себе, что один разработчик делает форму документа, а второй пишет проведение, третий ещё отдельно создаёт регистры для проведения документа и определяет состав и порядок его реквизитов. Весело? Теперь вы понимаете все проблемы Web разработчиков. Но это ещё не всё. Когда вы ведёте коллективную разработку в 1С, вы уже привыкли, что работаете с объектами по принципу «Это моё»: захватили и «пусть весь мир подождёт». Web разработчики не привыкли в чём то себя ограничивать – представьте, что вы редактируете конфигурацию как набор XML файлов и модулей где нибудь в блокноте. Можете править любой файл, никто вам не запретит. А как же система хранения версий? Да нормально – вы работаете в своей ветке, пишите спокойно «git commit» потом «git push»… Самое интересное начинается после – начинается что-то похожее на это:

    Это называется «Merge» и чем то напоминает процесс «Сравнения и объединения конфигурации». Ну не оно ли:

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

 


Как и у нас они на эту тему тома пишут https://habr.com/post/195674/  

К слову, стоит сказать, что большинство из этих merge-ей проходят автоматически, но, я думаю, уже очевиден масштаб проблемы и к чему это всё может привести? Правильно – к тому, что большую часть своего времени команда разработки будет мёрджить код, а оставшуюся половину будут исправлять ошибки возникшие в ходе неверного мёрджа, эта команда со временем начинает выглядеть вот так:

Сколько при таком подходе будет выпускаться готовый продукт? Да сколько угодно! Притом, без преувеличений, даже просто получить рабочую версию системы в большинстве случаев бывает проблемой. А если система состоит из микросервисов, то вообще вскоре «заблудитесь» что где работает а что нет? В случае микросервисной архитектуры традиционные и привычные подходы вообще скорее всего являются невозможными? В этом случае концепция CI/CD кажется просто спасением – после каждого коммита нужно собирать систему целиком, и проводить полное или хотя бы базовое тестирование всего функционала. Таким образом, практически исключаются большие «мерджи», которые ломают всю систему, и она всегда находится в некотором стабильном состоянии. Соответственно – главным назначением практики CI/CD – является решение проблемы больших мёрджей и их последствий, а также упрощение выпуска релиза системы.

А что в 1С? 


А в 1С всё просто: в базовом варианте в команде разработки 1С нет возможности изменять один и тот же кусок кода. «Захватить в хранилище» и до свидания. Хранилище 1С не поддерживает ветвлений, это делает процесс разработки предельно линейным, что в целом эффективно для небольших команд. Но при этом мы теряем все преимущества процесса параллельной разработки. Соответственно в большой команде разработки 1С иногда можно наблюдать примерно такой процесс:

Процесс работы с разными объектами конфигурации строго последователен, зато нет никаких коллизий, мерджей, веток, их слияния… Для небольших команд это, пожалуй, наиболее правильный вариант, для больших жутко неэффективно. По аналогии можно сравнить как табличные и построчные блокировки. Если в базе работает 2-3 человека – нет смысл поддерживать всю инфраструктуру для построчных блокировок – табличные будут эффективнее, но если в базе человек 50 и более, то с табличными блокировками вы просто всё время будете «в режиме ожидания». 

Конечно, «опытные 1С-ники» меня сейчас поправят. Как так, а у нас – параллельная разработка на 1С реализована:

https://its.1c.ru/db/v8std/content/-2145782938/hdoc 

Конечно, такой вариант возможен, как и альтернативные с использованием выгрузки конфигурации в XML или файлы, v8Unpack и прочих извращений. Но в данном случае в разы увеличиваются трудозатраты на поддержание инфраструктуры. Едва ли можно отыскать команды, для которых параллельность разработки в 1С настолько важна, что затраты на такие манипуляции будут окупаемы. Тем не менее, такие команды встречаются. Чаще всего такая потребность в параллельности возникает в случае, когда на платформе 1С решают «не 1С-ные задачи». Что я понимаю под «Не 1С-ными задачами»? Ну это когда у вас 99% функционала системы сосредоточено в 2-3 документах, у каждого из которых по 50 реквизитов, при этом команда разработки насчитывает более 10 человек. Почему «не 1С-ная задача?». Платформа даёт нам кучу преимуществ для решения учетных задач, а также схожих. Если требуется много объектов, много разнообразной функциональности, она приближена к учетным задачам, то использование платформы 1С даёт кучу преимуществ как при использовании так и при разработке. Но в случае, когда вам нужно 2-3 формы, в которых будут работать конечные пользователи, на них выстроены определенные процессы, то мы сразу сталкиваемся с ограничениями, как пользовательскими (а мы тут хотим произвольный интерфейс), так и техническими (разрабатывать одну форму может без проблем только один программист).
Что же получается, тупик? Автоматизация учетных задач – это предел, что нас ожидает с текущей платформой? Параллельная разработка и gitflow для нас – непозволительная роскошь? К счастью, есть определенные предпосылки, позволяющие сказать, что всё не совсем так. 
    
Что нам приносит EDT?
 


Enterprise Development Tools – пожалуй, самое обсуждаемое среди разработчиков нововведение в платформе 1С. Одним из основных назначений его появления должна быть нормальная параллельная работа. В случае с EDT система контроля версий – это GIT. С конфигурацией вы работаете как с набором файлов, ничего нигде не лочите. Можете создать себе ветку, можете провести слияние веток. При этом слияние учитывает, естественно, специфику 1С. У вас появляется возможность сделать нормальный precommit, написать своё расширение и многое другое. Но на данный момент его использование в реальной разработке весьма сомнительно. EDT несёт в себе очень много недостатков:

1)    Очень прожорливо, ну просто очень. Вот такие показатели у меня отображаются в диспетчере задач при нормальной работе:


       Даже при современном уровне мощностей далеко не каждый может себе позволить такую расточительность
2)    Не поддерживает и никогда не будет поддерживать обычные формы. А сейчас это очень большой пласт прикладных решений, особенно тех в которых ещё ведётся разработка
3)    Нет нормальной автоподстановки. В Eclipse её и для Java то нормальной нет, а для 1С не понятно появится ли. До возможностей конфигуратора со встроенным Снегопат-ом,                 соответственно, ещё очень далеко
4)    Написано это всё на Java, соответственно будет медленно, прожорливо и иметь убогий внешний вид. Java – не тот язык разработки, на котором следует разрабатывать нативные           приложения с пользовательским интерфейсом. Сам отклик интерфейса будет дольше, не говоря уже о прожорливости JVM. 
5)    Всё очень долго – импорт проекта, запуск проекта, открытие формы и т.п. теряется драгоценное время. А именно оно ценно для среды разработки. Eclipse традиционно был                   самой тугой средой разработки, а с появлением в ней кучей «плюшек» для разработки 1С стал просто невыносим. 
6)    В основу взят Eclipse, в то время как наши соотечественники из JetBrains разработали куда лучшую IDE даже для того же Java (IntelliJ IDEA). В настоящий момент времени Eclipse уже безнадежно проигрывает по всем параметрам ведущим современным IDE, так что даже после завершения                       разработки EDT, уровень наш инструментов будет далёк от того, которым пользуются наши коллеги из других языков разработки.
 

 

 
Таким образом, если говорить о процессе CI – когда постоянно происходит сборка кода, его проверка, автоматическое слияние - для 1С в настоящее время едва ли актуален. 
Хотелось бы сказать что-нибудь хорошее про процесс CD – на Production надо выкатывать как можно быстрее, но тут тоже есть ограничения платформы. За многие годы развития мы так и не ушли до конца от монопольного режима при обновлении. Какое уж тут CD. Опытные 1С-ники, конечно, скажут, что всё решаемо. Делается РИБ и переключение, или обновляется вручную структура СУБД и текущая конфигурация… Но это очень далеко от принципов CD, а наоборот, требует тщательного планирования и ручного контроля.
Кроме того, базовые практики CI подразумевают покрытие тестами всего кода. Но на проектах 1С большинство кода никак не относится к вашей команде разработки. А автоматизированное развертывание и покрытие его тестами займёт чаще всего больше времени, чем сам проект.

Теперь давайте посмотрим, как построен стандартный процесс CI где-нибудь в Web разработке:


Происходит примерно следующее:
1)    Вы делаете commit
2)    По Webhook запускается CI процесс 
3)    Разворачивается docker контейнер тестовой среды (она же небольшая – некий объём кода и начальная БД)
4)    Выполняются unit тесты (помним что весь код в вашем приложении написала ваша команда и она же покрыла его тестами)
5)    Выполняется проверка кода
6)    Вы получаете красный или зелёный свет.
     

Где будут проблемы у 1С? Правильно – везде. Если (1) и (2) как то удастся преодолеть, то на этапе (3) у вас явно возникнут проблемы, но с ними ещё можно справиться, а вот покрыть юнит тестами весь код УПП… 

В общем, поразмыслив над всем этим, я по традиции обратился «к старшим братьям», или к SAP. Потому что что-то подсказывает, что у них точно такие же проблемы.

И как же дела c CI/CD у SAP?

И первое, на что наткнулся на просторах интернета:

 

Потом на статью, в которой человек жалуется, как в SAP всё плохо с DevOps https://blogs.sap.com/2015/11/09/continuous-integration-for-sap/ и в конце концов на статью другого человека, который придумал несколько «кустарных методов»: https://blogs.sap.com/2017/11/11/continuous-integration-in-abap-using-jenkins/ 
К слову, с DevOps у SAP плохо только на ABAP – там где пишутся внутренние транзакции. У SAP есть куча Web и Java разработки, тот же UI5, где CI/CD успешно применяются.

Так и в 1С – в отдельных проектах (к примеру, разрабатываете вы сложный «внешний модуль») применение практик CI/CD вполне оправдано.

Но в общем и целом, при разработке ERP систем CI/CD практики конечно должны как минимум проходить переосмысление. Контекст несколько другой, относительно типовых сценариев.

Так что же теперь, забить на весь этот DevOps?

Нет, конечно же нет. DevOps – это правильный и трендовый подход. Неприменимость отдельных элементов не означает что он сам по себе не нужен. Когда пишете код, нужно задумываться, как он встанет на сервер, какие внешние ресурсы потребуются, как нужно обновить рабочую базу, что делать, если будут проблемы после обновления. Нужно по максимуму автоматизироваться:
•    Автоматизируйте обновление Production баз, к примеру так: //catalog.1cnik.by/public/661836/ 
•    Автоматизируйте тестирование релизов, к примеру так: //catalog.1cnik.by/public/723210
•    Автоматизируйте развертывание тестового окружения, к примеру вот так: //catalog.1cnik.by/public/542836/ 
•     Автоматизируйте  проверку кода, к примеру вот так: http://v8.1c.ru/acc/
•    Запускайте автоматизированные тесты на отдельной машине
•    Проверяйте код на копипасту, к примеру вот так: //catalog.1cnik.by/public/294285/ 
•    Проверяйте код на излишнюю сложность, к примеру так: //catalog.1cnik.by/public/166182/  
Список открыт. В целом, большинство подходов к разработке ПО применимы и в «мире 1С» конечно, но есть определенные нюансы. Не надо их бояться и избегать, просто перед тем как что-то позаимствовать «у старших братьев» - проанализируйте внимательно, что вам это даст и какие трудозатраты повлечёт.

66

См. также

Комментарии
Избранное Подписка Сортировка: Древо
1. PerlAmutor 32 02.07.18 11:31 Сейчас в теме
(0)
5) Всё очень долго – импорт проекта, запуск проекта, открытие формы и т.п. теряется драгоценное время. А именно оно ценно для среды разработки. Eclipse традиционно был самой тугой средой разработки, а с появлением в ней кучей «плюшек» для разработки 1С стал просто невыносим.
6) В основу взят Eclipse, в то время как наши соотечественники из JetBrains разработали куда лучшую IDE даже для того же Java (IntelliJ IDEA). В настоящий момент времени Eclipse уже безнадежно проигрывает по всем параметрам ведущим современным IDE, так что даже после завершения разработки EDT, уровень наш инструментов будет далёк от того, которым пользуются наши коллеги из других языков разработки.


Верно сказано. EDT это мертворожденный ребенок, хоть и более желанный чем старенький конфигуратор.
Кроме того EDT не работает с платформами ниже 8.3.8.
igo1; Soloist; AlexGroovy; +3 Ответить
32. MotorBox 04.07.18 12:32 Сейчас в теме
(1)
Верно сказано. EDT это мертворожденный ребенок

Если 1С рожает мертворожденных то может и для самого 1С лучшие времена уже позади ?
2. FesenkoA 29 02.07.18 11:32 Сейчас в теме
Идеальность недостижима, но Frontedn исправить нужно)

Невозможность распараллеливания работы над одним объектом привело к тому, что 1Сник - "и на дуде дудец, и на гитаре трындец", в то время как веб-разработчики более подвержены профдеформации, и через 2-3 года работы с одним фреймверком на одном направлении атрофируют другие навыки разработки. Да, мы не станем "специалистом по правой ноздре", так чтобы знать все, но с другой стороны мы можем (что чаще всего и происходит) самостоятельно разрабатывать, внедрять поддерживать всю учетную систему, а специализация конкретного навыка (например знание принципов работы с внешними источниками данных) в принципе может и не всегда нужна, или быть достигнута при помощи коллег/формумов/рабочего выходного.
bulpi; comol; +2 Ответить
3. ladon 02.07.18 12:30 Сейчас в теме
За статью спасибо.

Ссылки не совсем корректные - добавлен лишний символ, который переводит на страницу 404.
4. Evil Beaver 5330 02.07.18 13:08 Сейчас в теме
За скриншот моей обработки https://infostart.ru/public/153672 - отдельное спасибо! :)
5. OLEG4120 133 02.07.18 13:22 Сейчас в теме
Даа... просто "клюква" про Eclipse, Java, скорость java, интерфейс десктопных java приложений.
Dementor; +1 Ответить
6. ltfriend 283 02.07.18 14:13 Сейчас в теме
Написано это всё на Java, соответственно будет медленно, прожорливо и иметь убогий внешний вид. Java – не тот язык разработки, на котором следует разрабатывать нативные приложения с пользовательским интерфейсом

...
разработали куда лучшую IDE даже для того же Java (IntelliJ IDEA)

Так то IntelliJ IDEA тоже написана на Java.
manuel; Dementor; zeegin; comol; VladimirL; +5 Ответить
7. minimajack 50 02.07.18 15:00 Сейчас в теме
4) Написано это всё на Java, соответственно будет медленно, прожорливо и иметь убогий внешний вид. Java – не тот язык разработки, на котором следует разрабатывать нативные приложения с пользовательским интерфейсом. Сам отклик интерфейса будет дольше, не говоря уже о прожорливости JVM.

Какой то вброс негативной информации, без пруфов...
Возможно java проигрывает с++ в качестве числодробилки в один поток, но хадуп, спарк, кассандра, кафка, зукипер, дженкинс что вы о них скажете?
9. Evil Beaver 5330 02.07.18 15:04 Сейчас в теме
(7) полагаю, Олег имел в виду именно GUI-приложения Java. Я видел только одно нормальное - IDEA от Jenbrains. Но там кастомный, вылизанный GUI. Все "типовые" библиотеки для интерфейсов под Java - адское говнище (в данном случае - медицински точный, выверенный термин, а не захлестнувшие эмоции)
cefew; PLAstic; herfis; +3 Ответить
11. minimajack 50 02.07.18 16:27 Сейчас в теме
(9)
Все "типовые" библиотеки для интерфейсов под Java - адское говнище

GUI IDEA от Jenbrains построен на типовой библиотеке swing которая в свою очередь построена на типовой библиотеке AWT. По сути из стандартных только JavaFX осталась, но там не говнище.
В итоге - "вылизаная ГУИ" оказывается всего лишь причесанной темой для стандартных библиотек, причем опенсорс (https://github.com/bulenkov/Darcula), причем любое гуевое приложение(на swing) можно запустить с этой темой добавив
-Dswing.defaultlaf=com.bulenkov.darcula.DarculaLaf
к строке запуска и jar-ник с темой.
Просто на java никто не любит писать гуешные приложения, дa и SWT( гуи эклипса) - совсем не стандартная.
з.ы. Не стоит судить по всей java и java-gui по заложенным 10 лет назад стереотипам.
Dementor; VladimirL; Evil Beaver; +3 Ответить
13. Evil Beaver 5330 02.07.18 17:51 Сейчас в теме
(11)
Не стоит судить по всей java и java-gui по заложенным 10 лет назад стереотипам.

Почему-то других почти не попадается. Допускаю, что я плохо искал.
16. spacecraft 02.07.18 21:06 Сейчас в теме
(11) ух ты. И учитывать в коде новую тему даже не нужно? И контролы сами заменятся? Или просто цвета поменяются? Это вопрос. Не использовал в java.
Тогда в c# если добавить MaterialDesing это будет причесанная WindowsForm?
21. minimajack 50 03.07.18 07:58 Сейчас в теме
(16)учитывать тему не нужно, контролы одинаковые. Есть примеры кода, можно потыкать и посмотреть как это работает.
про с# ничего не скажу - меня ничем не привлекает
19. comol 3689 02.07.18 23:50 Сейчас в теме
(11)
Не стоит судить по всей java и java-gui по заложенным 10 лет назад стереотипам

Ну просто это не цель для Java разработчиков.. Java это таки энтерпрайз, и основа для web приложений. Для других целей есть другие нгормальные инструменты.
18. comol 3689 02.07.18 23:48 Сейчас в теме
(9) Ну не только GUI. В высоконагруженных системах JVM тоже лишняя роскошь... Но интерфейс это именно то как ты сказал :)
17. comol 3689 02.07.18 23:46 Сейчас в теме
(7)
кассандра
Про всё не скажу, но для cassandra JVM - главная проблема http://www.highload.ru/2017/abstracts/2917.html
Для kaffka впрочем тоже, но пруфа под рукой нет.
JVM это в принципе проблема :)))
Evil Beaver; +1 Ответить
8. yarunya 64 02.07.18 15:03 Сейчас в теме
Что я только что прочитал?
10. Gureev 02.07.18 15:12 Сейчас в теме
https://its.1c.ru/db/v8std/content/-2145782938/hdoc
Едва ли можно отыскать команды, для которых параллельность разработки в 1С настолько важна, что затраты на такие манипуляции будут окупаемы.


Туфта. Это пишет человек, не пробовавший разветвленную технологию в работе.
Никаких затрат, и никакой сложности. А уж мёрж, благодаря технологии файлов поставок, прост как две копейки.
14. Evil Beaver 5330 02.07.18 17:54 Сейчас в теме
(10) Вы про СППР-workflow с ветками-хранилищами?
25. comol 3689 03.07.18 11:00 Сейчас в теме
(14)
СППР-workflow
зачОт. :). Теперь я знаю как это называется :)
28. Gureev 03.07.18 11:31 Сейчас в теме
20. comol 3689 02.07.18 23:52 Сейчас в теме
(10) Если бы не пробовавший... Не было бы этой статьи....

" А уж мёрж, благодаря технологии файлов поставок, прост как две копейки."

А это пишет человек который не видел что такое простой мёрж
22. Gureev 03.07.18 08:27 Сейчас в теме
(20) Ой да ладно.
Поставка - Обновить - Только дважды измененные - Выполнить.

Куда проще?
23. comol 3689 03.07.18 10:59 Сейчас в теме
(22) эээ а ссылку выше читали? "порядок создания хранилища", "порядок обновления хранилища", или вообще не представляете о чём речь?
26. Gureev 03.07.18 11:27 Сейчас в теме
(23) Я эту методологию не просто читал, я ее использую на практике.
Поэтому сразу видно кто "просто читал", а кто использовал.
30. lustin 992 03.07.18 18:00 Сейчас в теме
(26) Скорее всего Олега попросили внедрить инженерные практики - но это вызвало у него боль отраженную в статье. Он просто не дошел до применения инструментов - поэтому и ошибся упоминая v8unpack ;-) который уже давно не нужен.
33. comol 3689 04.07.18 13:14 Сейчас в теме
(30)
Олега попросили внедрить инженерные практики
не... я 2 раза пытался. Сам. В "не 1С" - зашло на ура. в 1С.. ну просто несопоставимые трудозатраты
34. comol 3689 04.07.18 13:14 Сейчас в теме
(26)
я ее использую на практике.

Сочуствую...
36. Gureev 04.07.18 13:16 Сейчас в теме
31. zeegin 30 03.07.18 23:57 Сейчас в теме
(23) СППР это делает в одну кнопку
35. comol 3689 04.07.18 13:15 Сейчас в теме
(31)
СППР это делает в одну кнопку

Ну видимо надо было ещё раскрыть детальнее эту "одну кнопку" в СППР... не обманывайте людей
38. zeegin 30 04.07.18 17:50 Сейчас в теме
(35) В карточке техпроекта одна кнопка чтобы создать хранилище техпроекта на основании транка и вторая чтобы хранилище техпроекта слить в транк.
Прикрепленные файлы:
40. comol 3689 05.07.18 16:58 Сейчас в теме
(38)
(35) В карточке техпроекта одна кнопка чтобы создать хранилище техпроекта на основании транка и вторая чтобы хранилище техпроекта слить в транк.

Баян.
А теперь трудозатраты на "добавить реквизит" по СППР-Workflow :). А самое интересное - трудозатраты на "слить ветку"... Ну не говоря ещё про "протестировать изменения", сделать ветку от ветки...
42. zeegin 30 05.07.18 19:02 Сейчас в теме
(40) "добавить реквизит" - это изменение, требующее согласование, т.к. вызывает реструкрутризацию. В рамках исправления ошибок выполнять изменения, которые вызывают реструктуризацию можно только в случае, когда по другому исправить ошибку невозможно.
Кроме "добавить реквизит" надо еще обосновать как этот реквизит будет использоваться, какие сопутствующие модули надо изменить, доступен ли этот реквизит как программный инетрфейс всем или только внутри подсистемы, как он будет отображен на форме с примером внешнего вида пользователю. А еще не забыть про проектную документацию. Документацию для пользователей и администраторов. А еще сценарные тесты надо доработать и юнит-тесты дописать.

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

Трудозатраты на атомарные операции - выше безусловно. Экономия времени за счет продумывания и предварительного проектирования покрывает этот расход. Надо к СППР-Workflow относится не как к процессу "что-то изменить к конфигурации", а как к процессу "что-то изменить в продукте".

Чтобы "протестировать изменения" достаточно запустить CI на ветке техпроекта) Обычно настройка этого не занимает времени вообще.
43. comol 3689 07.07.18 21:47 Сейчас в теме
(42)
надо делать техпроекты.
Ну к примеру техпроект - "увеличить шрифт в печатной форме"?...
"что-то изменить в продукте"
а вот это из другой оперы... из той где есть бэклог, нету техпроектов... есть таски и они выполняются, выполняютя быстро.
При определенныхусловиях это может быть обоснованно, но в случае СППР-Workflow "ТехПроект" это именно то что называют "ТехПроектами" 1С-франчайзи... Про CI и какой-либо Workflow 1С в этом случае не думали...
Про него, слава богу, подумали хотя бы при разработке EDT
39. zeegin 30 04.07.18 21:19 Сейчас в теме
(35) Вот если на пальцах объяснять, то это работает так:

Есть git - но это только хранилище. Когда давно в бородатых годах был придуман git-flow со всякими удобными ветвлюшками - как процесс разработки.
Сейчас чаще на практике используют gitlab-flow который лучше ложится на CI/CD.

В gitflow есть понятие - support branch (не все про него знают) - это стабильная ветка проекта, первая стабильная - называется master - остальные по примеру support-v1.2.3. Т.е. та в которой исправляются ошибки даже после выпуска новой мажорной версии. В gitlab-flow это называется stable branch. В СППР это называется - хранилище версии проекта.

Ответвления для разработки новой функциональности features-* в СППР являются техническими проектомами. Они позволяет полностью собирать ошибки и идеи (в gitlab issues) которые планируется реализовать, плюс процесс контроля согласования, исполнения, тестирования и конечно же ответвления и слияния с хранилищем основной версии проекта (master в мире git).

Вот в карточке технического проекта и есть функции создания хранилища для этого техпроекта - т.е. ответвления от мастера или другой стабильной ветки. И слияния в нее обратно.
41. comol 3689 05.07.18 17:06 Сейчас в теме
(39) Да я видел как это работает. В production хотел бы конечно посмотреть... я развернул ветку для ERP, проверил слияние... проверил создание тех ветки, накатывание изменений на тестовую базу... Посчитал затраченное время... Ну это очень убого и долго, чесслово.
45. lustin 992 08.07.18 21:08 Сейчас в теме
(41) купи книгу ;-) и все у тебя будет хорошо и быстро.
46. LapoTb 02.08.18 04:36 Сейчас в теме
(45) Это какую такую мега-книгу надо купить, чтобы все было "хорошо и быстро"?
47. artbear 1087 03.08.18 11:58 Сейчас в теме
(46) https://silverbulleters.org/books

Методическое пособие релиз-инженера 1С и не только

Книга посвящена вопросу создания автоматизированного процесса управления релизным циклом решений на базе платформы 1С:Предприятие 8.

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

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

Рассматриваемые в книге инструменты преимущественно следуют философии открытого программного обеспечения (Open Source).
N!ghtmare; comol; +2 Ответить
49. comol 3689 06.08.18 23:07 Сейчас в теме
(47) Ого, даже книгу выпустили - зачОт!
54. pallid 188 19.08.18 15:57 Сейчас в теме
(47)
(45)

можно как-то купить на infostart?
12. swimdog 571 02.07.18 16:40 Сейчас в теме
15. kraynev-navi 377 02.07.18 20:25 Сейчас в теме
(0) Ссылки в разделе "Так что же теперь, забить на весь этот DevOps?" поправьте - не открываются, лишние символы.
24. comol 3689 03.07.18 11:00 Сейчас в теме
27. serrembo 03.07.18 11:30 Сейчас в теме
(0) Отличная статья, спасибо
29. lustin 992 03.07.18 17:56 Сейчас в теме
первое: из статьи непонятно - миф всё таки или реальность.
второе: как проблемы ветвления и разрешения конфликтов связаны с CI/CD.
третье: хранилище поддерживает ветвление - для этого надо уметь делать много хранилищ, потому что хранилище = ветка
четвертое: v8unpack давно legasy - используется либо gitsync, либо gitConverter
пятое: докер для 1С развертывания используется уже как 3 года (или 4), кстати у Веб разработчиков давно НЕ докер, а docker-compose в режиме docker-swarm

(0) Олег - чего это ты в очередной раз на вентилятор то набрасываешь ? купи книгу - почитай как настраивать ;-)
Gureev; o4karek; kuntashov; Labotamy; +4 Ответить
37. comol 3689 04.07.18 13:20 Сейчас в теме
(29)
из статьи непонятно - миф всё таки или реальность.

Это каждый сам решает :). Ну мой вывод очевиден... пока...
(29)
хранилище поддерживает ветвлени
Лёша, это миф...
(29)
v8unpack давно legasy
ну тут согласен..
(29)
чего это ты в очередной раз на вентилятор то набрасываешь

Потому что некоторые товарищи хм... "зародили сомнение" что в 1С можно git-flow... и потому что рядом то php-шники то C#-исты у которых это работает...
А как 1С-нику тоже хочется "этот коммит берём, а этот не берём" и нельзя этого... ну нельзя просто поверить, понять и простить :)
Когда будет EDT хоть как то работать (если будет) то станет можно, сейчас просто надо забыть и не тратить время.
44. lustin 992 08.07.18 21:08 Сейчас в теме
(37) То есть как я и предполагал - то есть у тебя не получилось и теперь ты статьёй доказываешь что "всё миф".

Как был git'-ненавистником, таким и остался ;-)

Короче ждем октября и доклада Валерия http://event.infostart.ru/2018/agenda/#item844300
посмотрим как там с мифами.

P.S. ожидаю долгую дискуссию про мифы в кулллллуарах.
48. comol 3689 06.08.18 23:04 Сейчас в теме
(44)
Как был git'-ненавистником, таким и остался ;-)
Ну это не правда... Git хорошо решает определенные задачи.
А вот CI/CD - ну не покатит это пока не будет боле развитых возможностей платформы... да и тогда вопрос... у SAP не пошло же
50. ImHunter 21 07.08.18 06:25 Сейчас в теме
(48) Да почему не покатит-то CI/CD?... CD, по-крайней мере, вполне себе спокойно реализуется и работает. Вот с CI есть определенные проблемы. Но они скорее связаны с тем, что мало кому понятна ценность этого компонента. Поэтому топлива для CI (тесты, фичи) - увы, мало. И тут дело не в возможностях платформы, а в менталитете.
52. comol 3689 09.08.18 14:37 Сейчас в теме
(50)
CD, по-крайней мере, вполне себе спокойно реализуется
. Согласен, речь про CI.

При всём осознании ценности, реализация хм... :))) Ну смеются над нами web-еры :)
51. lustin 992 07.08.18 13:50 Сейчас в теме
(48) Понимаешь Олег в чем дело - посмотри на сетку докладов на ближайший эвент и просто сделай отбор по ключевому слову GIT. Также я тебе напомню что существуют 4 различных решения для CICD от разных авторов (в том числе от вендора). Поэтому мне странно слышать тезисы - GIT, CICD в 1С - "миф". Еще четыре года назад - возможно я бы понял почему так происходит: формально только "гики" могли себе такое позволить, но сейчас в 2018 году - это уже не так. Запуск базовых сборочных линий может себе позволить небольшая микрокоманда из 3-5 человек.
53. comol 3689 09.08.18 14:44 Сейчас в теме
(51)
GIT,
Git просто стал хайпом... все уже давно используют, зачем об этом говорить не ясно...

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

при VCS с одной веткой можно организовать ветвления, но от этого оно не станет VCS c ветвлениями....
Код от данных можно отделить... но он не станет от этого отдельным... Дальше продолжать или понятно?

Лет 5 назад я очень плотно этим занимался... когда у меня было 24x7 и ну просто никак по-другому...
Потом много читал, потом опять занимался. Потом сходил на курсы по DevOps-у... потом сходил на конференцию к SAP-ёрам.
Собственно SAP-ёры убедили что CI не для их решений... там целые отделы занимались этими вопросами. Итог один "вроде можно... но зачем"?

Если "взлетит" EDT то к теме CI конечно вернёмся... Пока мониторю каждый релиз, и с каждым релизом расстраиваюсь всё больше
Оставьте свое сообщение