В современном 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 баз, к примеру так: //infostart.ru/public/661836/
• Автоматизируйте тестирование релизов, к примеру так: //infostart.ru/public/723210
• Автоматизируйте развертывание тестового окружения, к примеру вот так: //infostart.ru/public/542836/
• Автоматизируйте проверку кода, к примеру вот так: http://v8.1c.ru/acc/
• Запускайте автоматизированные тесты на отдельной машине
• Проверяйте код на копипасту, к примеру вот так: //infostart.ru/public/294285/
• Проверяйте код на излишнюю сложность, к примеру так: //infostart.ru/public/166182/
Список открыт. В целом, большинство подходов к разработке ПО применимы и в «мире 1С» конечно, но есть определенные нюансы. Не надо их бояться и избегать, просто перед тем как что-то позаимствовать «у старших братьев» — проанализируйте внимательно, что вам это даст и какие трудозатраты повлечёт.
Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2024 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
(0)
6) В основу взят Eclipse, в то время как наши соотечественники из JetBrains разработали куда лучшую IDE даже для того же Java (IntelliJ IDEA). В настоящий момент времени Eclipse уже безнадежно проигрывает по всем параметрам ведущим современным IDE, так что даже после завершения разработки EDT, уровень наш инструментов будет далёк от того, которым пользуются наши коллеги из других языков разработки.
Верно сказано. EDT это мертворожденный ребенок, хоть и более желанный чем старенький конфигуратор.
Кроме того EDT не работает с платформами ниже 8.3.8.
Идеальность недостижима, но Frontedn исправить нужно)
Невозможность распараллеливания работы над одним объектом привело к тому, что 1Сник — «и на дуде дудец, и на гитаре трындец», в то время как веб-разработчики более подвержены профдеформации, и через 2-3 года работы с одним фреймверком на одном направлении атрофируют другие навыки разработки. Да, мы не станем «специалистом по правой ноздре», так чтобы знать все, но с другой стороны мы можем (что чаще всего и происходит) самостоятельно разрабатывать, внедрять поддерживать всю учетную систему, а специализация конкретного навыка (например знание принципов работы с внешними источниками данных) в принципе может и не всегда нужна, или быть достигнута при помощи коллег/формумов/рабочего выходного.
За статью спасибо.
Ссылки не совсем корректные — добавлен лишний символ, который переводит на страницу 404.
За скриншот моей обработки — отдельное спасибо! 🙂
Даа… просто «клюква» про Eclipse, Java, скорость java, интерфейс десктопных java приложений.
…
Так то IntelliJ IDEA тоже написана на Java.
Какой то вброс негативной информации, без пруфов…
Возможно java проигрывает с++ в качестве числодробилки в один поток, но хадуп, спарк, кассандра, кафка, зукипер, дженкинс что вы о них скажете?
Что я только что прочитал?
(7) полагаю, Олег имел в виду именно GUI-приложения Java. Я видел только одно нормальное — IDEA от Jenbrains. Но там кастомный, вылизанный GUI. Все «типовые» библиотеки для интерфейсов под Java — адское говнище (в данном случае — медицински точный, выверенный термин, а не захлестнувшие эмоции)
Едва ли можно отыскать команды, для которых параллельность разработки в 1С настолько важна, что затраты на такие манипуляции будут окупаемы.
Туфта. Это пишет человек, не пробовавший разветвленную технологию в работе.
Никаких затрат, и никакой сложности. А уж мёрж, благодаря технологии файлов поставок, прост как две копейки.
(9)
GUI IDEA от Jenbrains построен на типовой библиотеке swing которая в свою очередь построена на типовой библиотеке AWT. По сути из стандартных только JavaFX осталась, но там не говнище.
В итоге — «вылизаная ГУИ» оказывается всего лишь причесанной темой для стандартных библиотек, причем опенсорс (, причем любое гуевое приложение(на swing) можно запустить с этой темой добавив
к строке запуска и jar-ник с темой.
Просто на java никто не любит писать гуешные приложения, дa и SWT( гуи эклипса) — совсем не стандартная.
з.ы. Не стоит судить по всей java и java-gui по заложенным 10 лет назад стереотипам.
Frontedn
(11)
Почему-то других почти не попадается. Допускаю, что я плохо искал.
(10) Вы про СППР-workflow с ветками-хранилищами?
(0) Ссылки в разделе «Так что же теперь, забить на весь этот DevOps?» поправьте — не открываются, лишние символы.
(11) ух ты. И учитывать в коде новую тему даже не нужно? И контролы сами заменятся? Или просто цвета поменяются? Это вопрос. Не использовал в java.
Тогда в c# если добавить MaterialDesing это будет причесанная WindowsForm?
(7)
Про всё не скажу, но для cassandra JVM — главная проблема
Для kaffka впрочем тоже, но пруфа под рукой нет.
JVM это в принципе проблема :)))
(9) Ну не только GUI. В высоконагруженных системах JVM тоже лишняя роскошь… Но интерфейс это именно то как ты сказал 🙂
(11)
Ну просто это не цель для Java разработчиков.. Java это таки энтерпрайз, и основа для web приложений. Для других целей есть другие нгормальные инструменты.
(10) Если бы не пробовавший… Не было бы этой статьи….
» А уж мёрж, благодаря технологии файлов поставок, прост как две копейки.»
А это пишет человек который не видел что такое простой мёрж
(16)учитывать тему не нужно, контролы одинаковые. Есть примеры кода, можно потыкать и посмотреть как это работает.
про с# ничего не скажу — меня ничем не привлекает
(20) Ой да ладно.
Поставка — Обновить — Только дважды измененные — Выполнить.
Куда проще?
(22) эээ а ссылку выше читали? «порядок создания хранилища», «порядок обновления хранилища», или вообще не представляете о чём речь?
(14)
зачОт. :). Теперь я знаю как это называется 🙂
(15) спасибо. поправил
(23) Я эту методологию не просто читал, я ее использую на практике.
Поэтому сразу видно кто «просто читал», а кто использовал.
(0) Отличная статья, спасибо
(14) ага
первое: из статьи непонятно — миф всё таки или реальность.
второе: как проблемы ветвления и разрешения конфликтов связаны с CI/CD.
третье: хранилище поддерживает ветвление — для этого надо уметь делать много хранилищ, потому что хранилище = ветка
четвертое: v8unpack давно legasy — используется либо gitsync, либо gitConverter
пятое: докер для 1С развертывания используется уже как 3 года (или 4), кстати у Веб разработчиков давно НЕ докер, а docker-compose в режиме docker-swarm
(0) Олег — чего это ты в очередной раз на вентилятор то набрасываешь ? купи книгу — почитай как настраивать 😉
(26) Скорее всего Олега попросили внедрить инженерные практики — но это вызвало у него боль отраженную в статье. Он просто не дошел до применения инструментов — поэтому и ошибся упоминая v8unpack 😉 который уже давно не нужен.
(23) СППР это делает в одну кнопку
(1)
Если 1С рожает мертворожденных то может и для самого 1С лучшие времена уже позади ?
(30)
не… я 2 раза пытался. Сам. В «не 1С» — зашло на ура. в 1С.. ну просто несопоставимые трудозатраты
(26)
Сочуствую…
(31)
Ну видимо надо было ещё раскрыть детальнее эту «одну кнопку» в СППР… не обманывайте людей
(34)
Взаимно)
(29)
Это каждый сам решает :). Ну мой вывод очевиден… пока…
(29)
Лёша, это миф…
(29)
ну тут согласен..
(29)
Потому что некоторые товарищи хм… «зародили сомнение» что в 1С можно git-flow… и потому что рядом то php-шники то C#-исты у которых это работает…
А как 1С-нику тоже хочется «этот коммит берём, а этот не берём» и нельзя этого… ну нельзя просто поверить, понять и простить 🙂
Когда будет EDT хоть как то работать (если будет) то станет можно, сейчас просто надо забыть и не тратить время.
(35) В карточке техпроекта одна кнопка чтобы создать хранилище техпроекта на основании транка и вторая чтобы хранилище техпроекта слить в транк.
(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).
Вот в карточке технического проекта и есть функции создания хранилища для этого техпроекта — т.е. ответвления от мастера или другой стабильной ветки. И слияния в нее обратно.
(38)
Баян.
А теперь трудозатраты на «добавить реквизит» по СППР-Workflow :). А самое интересное — трудозатраты на «слить ветку»… Ну не говоря ещё про «протестировать изменения», сделать ветку от ветки…
(39) Да я видел как это работает. В production хотел бы конечно посмотреть… я развернул ветку для ERP, проверил слияние… проверил создание тех ветки, накатывание изменений на тестовую базу… Посчитал затраченное время… Ну это очень убого и долго, чесслово.
(40) «добавить реквизит» — это изменение, требующее согласование, т.к. вызывает реструкрутризацию. В рамках исправления ошибок выполнять изменения, которые вызывают реструктуризацию можно только в случае, когда по другому исправить ошибку невозможно.
Кроме «добавить реквизит» надо еще обосновать как этот реквизит будет использоваться, какие сопутствующие модули надо изменить, доступен ли этот реквизит как программный инетрфейс всем или только внутри подсистемы, как он будет отображен на форме с примером внешнего вида пользователю. А еще не забыть про проектную документацию. Документацию для пользователей и администраторов. А еще сценарные тесты надо доработать и юнит-тесты дописать.
Для компаний которые не выполняют проектирование и хреначат все сразу в прод — наверное чтобы «добавить реквизит» это все не нужно. Для остальных — надо делать техпроекты.
Трудозатраты на атомарные операции — выше безусловно. Экономия времени за счет продумывания и предварительного проектирования покрывает этот расход. Надо к СППР-Workflow относится не как к процессу «что-то изменить к конфигурации», а как к процессу «что-то изменить в продукте».
Чтобы «протестировать изменения» достаточно запустить CI на ветке техпроекта) Обычно настройка этого не занимает времени вообще.
(42)
Ну к примеру техпроект — «увеличить шрифт в печатной форме»?…
а вот это из другой оперы… из той где есть бэклог, нету техпроектов… есть таски и они выполняются, выполняютя быстро.
При определенныхусловиях это может быть обоснованно, но в случае СППР-Workflow «ТехПроект» это именно то что называют «ТехПроектами» 1С-франчайзи… Про CI и какой-либо Workflow 1С в этом случае не думали…
Про него, слава богу, подумали хотя бы при разработке EDT
(41) купи книгу 😉 и все у тебя будет хорошо и быстро.
(37) То есть как я и предполагал — то есть у тебя не получилось и теперь ты статьёй доказываешь что «всё миф».
Как был git’-ненавистником, таким и остался 😉
Короче ждем октября и доклада Валерия
посмотрим как там с мифами.
P.S. ожидаю долгую дискуссию про мифы в кулллллуарах.
(45) Это какую такую мега-книгу надо купить, чтобы все было «хорошо и быстро»?
(46)
Методическое пособие релиз-инженера 1С и не только
Книга посвящена вопросу создания автоматизированного процесса управления релизным циклом решений на базе платформы 1С:Предприятие 8.
В книгу включены материалы, описывающие современные практики управления релизным циклом, инструментарий автоматизации выпуска релизов, проверки качества кода. Также подробно рассматриваются вопросы виртуализации и контейнеризации инструментов релиз-инженеров.
Прочитав книгу, вы узнаете:
Как сократить время выпуска версии продукта
Как использовать виртуальные и контейнерные окружения, организовывать стенды и «песочницы»
Как управлять версиями кода
Как автоматизировать тестирование
Как автоматизировать создание документации по продукту
И многое другое.
Книга рассчитана на разработчиков 1С, занимающихся выпуском и развертыванием решений в рабочих контурах, а также технических руководителей команд, ответственных за улучшение качества кода, решений, создаваемых на платформе «1С:Предприятие 8».
Рассматриваемые в книге инструменты преимущественно следуют философии открытого программного обеспечения (Open Source).
(44)
Ну это не правда… Git хорошо решает определенные задачи.
А вот CI/CD — ну не покатит это пока не будет боле развитых возможностей платформы… да и тогда вопрос… у SAP не пошло же
(47) Ого, даже книгу выпустили — зачОт!
(48) Да почему не покатит-то CI/CD?… CD, по-крайней мере, вполне себе спокойно реализуется и работает. Вот с CI есть определенные проблемы. Но они скорее связаны с тем, что мало кому понятна ценность этого компонента. Поэтому топлива для CI (тесты, фичи) — увы, мало. И тут дело не в возможностях платформы, а в менталитете.
(48) Понимаешь Олег в чем дело — посмотри на сетку докладов на ближайший эвент и просто сделай отбор по ключевому слову GIT. Также я тебе напомню что существуют 4 различных решения для CICD от разных авторов (в том числе от вендора). Поэтому мне странно слышать тезисы — GIT, CICD в 1С — «миф». Еще четыре года назад — возможно я бы понял почему так происходит: формально только «гики» могли себе такое позволить, но сейчас в 2018 году — это уже не так. Запуск базовых сборочных линий может себе позволить небольшая микрокоманда из 3-5 человек.
(50)
. Согласен, речь про CI.
При всём осознании ценности, реализация хм… :))) Ну смеются над нами web-еры 🙂
(51)
Git просто стал хайпом… все уже давно используют, зачем об этом говорить не ясно…
вопрос не в техническом оснащении… он давно ясен и прозрачен… вопрос к самому процессу.
Ну как тебе объяснить… монолит можно разделить на микросервисы, но от этого он меньше монолитом не станет…
при VCS с одной веткой можно организовать ветвления, но от этого оно не станет VCS c ветвлениями….
Код от данных можно отделить… но он не станет от этого отдельным… Дальше продолжать или понятно?
Лет 5 назад я очень плотно этим занимался… когда у меня было 24×7 и ну просто никак по-другому…
Потом много читал, потом опять занимался. Потом сходил на курсы по DevOps-у… потом сходил на конференцию к SAP-ёрам.
Собственно SAP-ёры убедили что CI не для их решений… там целые отделы занимались этими вопросами. Итог один «вроде можно… но зачем»?
Если «взлетит» EDT то к теме CI конечно вернёмся… Пока мониторю каждый релиз, и с каждым релизом расстраиваюсь всё больше
(47)
(45)
можно как-то купить на infostart?
Хорошая статья, спасибо. Мне еще понравилась статья Что такое CI & CD и как она работает? Ссылка . Очень доступно описан процесс CI & CD. Может кому-то пригодится 🙂