Как стать автором
Обновить

Комментарии 94

Имхо, зря минусуют статью. Попытка применения интрументов анализа кода и практик devops в 1с — это как минимум свежо.

Спасибо. Мое мнение, что использование devops сможет все таки приподнять уровень качества программного кода на прикладных решениях. К тому же сама концепция уже хорошо известна, и успешно работает в других IT областях, а вот в 1С это жутко не хватает. И как капитан-очевидность, скажу что низкое качество кода — это первая причина тормозов в 1С. С этим нужно бороться. И не жутким наращиванием железа, а для начала повышением собственной компетенции.
Если это студенческая работа, то автор очень далеко пойдет как профессионал.
свежо, но есть хабровская и общая аллергия на 2 буквы «1с».
Хотя devops это методология, которая применима почти где угодно.
Аллергия скорее на словосочетание «Программист 1С», которые строят из себя абсолютно не заменимых людей, не желающие как либо развиваться и считающие, что одного языка 1С достаточно для всех решения всех проблем в бизнесе
Таких в любых языках/коллективах хватает, не стоит обобщать.
Название работы должно содержать не более 11 слов. Иначе оно не воспринимается аудиторией.
Смотря какой аудиторией. «Осесимметрическая задача о падении тупого твёрдого тела на поверхность несжимаемой жидкости при дозвуковой скорости движения границы области контакта» — в своё время никого не смутила. Подскажете, может, какое слово тут можно выбросить?
А вы ко всем подходили и спрашивали: «а вас не смутило название?» Или все молча сидели с каменными лицами «нам все понятно, заканчивай быстрее»?
А название придумать так, чтобы уместить смысл в нужное число слов — это часть работы над дипломом.
Всегда говорил, что у айтишников жизнь лёгкая — и ведь Вы айтишник? :-)
Ту же самую работу можно было назвать «приводнение капсулы космического корабля»… если бы речь шла о посте на гиктаймсе. А «там» сидели как раз люди в теме, которым название должно было строго описывать содержание. Изменение одного слова может означать, что решается совсем другая задача. Так что с теми, к кому можно было подойти — всё было в порядке.
Ту же самую работу можно было назвать «приводнение капсулы космического корабля»… если бы речь шла о посте на гиктаймсе.

А вот, например, "К электродинамике движущихся тел" — это для Гиктаймса название или для "людей в теме"? :)

Не начинайте передёргивать. Никто не говорит о невозможности коротких названий — чем более общим вопросам посвящена работа, тем короче возможное название.
Явно зря минусуют.
НЛО прилетело и опубликовало эту надпись здесь
Ну вы что, это ж 1С!
Каждый эникейщик считает своим долгом отреагировать: «Гыгыгыгы вы видели, там буковки русские! Да и ПО русское, что за говно. Тоже мне программисты! Вот мы на первом курсе в Visual Basic формочки рисовали, вот это, да, вот это программирование было!».

Большинство таких людей никогда не видело других подобных систем (потому что в России их в мелком/среднем бизнесе и нет в общем-то) и просто не представляют всех реальных плюсов и минусов платформы 1С.

Впрочем, есть и объективные причины для прохладного отношения к 1С-никам, но это тема отдельной статьи и причины эти к данному случаю точно не относятся.
По моему за русскоязычный синтаксис уже давно не высмеивают. Высмеивают общий низкий уровень программистов, также высмеивают слишком простой язык с большим количеством ограничений по сравнению с другими современными языками. Еще иногда вендора высмеивают, но это уже знающие больше. Хотя есть конечно отдельные хейтеры простопотомушта, но таких мало.
Тогда вам повезло. Мне в основном встречаются те, что «простопотомушта».

Вы перечислили объективные причины как раз, плюс еще пару я бы добавил.
Но обычно начинаешь спрашивать, чем конкретно не нравится 1С/1С-ники, ничего вразумительного ответить не могут. Может мне просто не везет так.
Да в общем за те же причины (убогость языка в каких то аспектах и низкий средний уровень) и js с php любят высмеивать. Хотя их поменьше хейтят. Про бейсик и вспоминать не буду.
А сравнивать по хорошему надо 1С с другими DSL типа ABAP и как подсказывает гугл X++
А смысл? Мы же обсуждаем почему не любят 1с и 1сников, а не чем 1с хуже/лучше аналогичных продуктов (по моему все такие продукты довольно скучные).
Просто на абаперов вроде не так сильно возбуждаются. Или они себя программистами не называют?
Хз, если бы хоть одного в жизни видел — может быть ответил бы.
Потому что 1С стоит везде — от пивного ларька, до крупной конторы. А SAP себе могут позволить единицы, поэтому их гораздо реже встречают другие IT-шники.
Ну и устоявшийся термин, насколько я знаю, все же SAP-консультант. Видимо, не называют себя программистами, да.

Кстати, на Хабре была шикарнейшая статья про SAP, которую потом выпилили. Можете найти в поисковике по запросу «пушномолочная свинья несушка sap».
«Консультант» не равно «программист» в SAP. Это две большие разницы. В 1С сейчас тоже постепенно к этому идет, так как растет сложность прикладных решений.
Уже много раз указывал — SAP и 1С это всего-лишь 2 компании. Надо четко понимать что эти 2 компании создали 2 экосистемы вокруг линейки своих продуктов и услуг.

Поэтому сравнивать можно два юридических лица. А вот сравнивать языки, системы или сравнивать специалистов из разных двух экосистем вообще неясно как. Но я попробую.

Например

— базисник в SAP, в 1С — эксперт по производительности
— консультат SAP:<имя модуля>, в 1C — специалист:<Имя типовой конфигурации>
— программист X++(ABAP) в SAP, в 1С — специалист по платформе 1С (а не программист обратите внимание)

Если копнуть чуть глубже — то например SAP Hybris с его spring.io вообще не вписывается в эту конструкцию — потому как там чистая Java.

Как пример из 1С — это 1C:Fresh и Центр администрирования: там как бы 1С, но внезапно нарисовывается скрипты на python.

Так что — я повторюсь: сравнивать можно только 2 компании, остальное вообще не сравнимо, потому как технологически разное ;-)
У меня один хороший знакомый «громит» 1с на основании знакомства с версией 5,0 под DOS. Другой руководитель ИТ любит поговорить о «недостатках архитектуры» и я предполагаю что последняя версия с которой он был знаком это 7.7/dbf. (В качестве «альтернативы» он пишет «свою ERP» на Delfi 5.0 +… BDE)
С моей точки зрения у 1с есть два существеных недостатка которые не дают занять ему нишу в системах класса управления предприятием — этл 1) отсутсвие эффективного планирующего модуля (того который решает неполиномиальные задачи построения графиков за полиномиальое время) и 2) Интеграция с Android и iOS может быть проведена только через слабо масштабируемый модуль сервера Apache (чрез rest/SOAP)
Но если что сейчас на какие-то мобильные устройства устанавливается Windows 10 то наверное 2-й пункт решается сам собой и на него можно устанвливать уже просто десктопного клиента 1с. Ну а 1-й пункт это не недостаток системы 1с а просто отсутсвие таого алгоритма. Если кто-то его напишет в конфигурации или в виле нативного модуля то это будет работать.
Ну, не совсем апач, можно и IIS. Плюс можно кроме rest (платформенного: oData) и soap — свой api поверх http написать.
Плюс есть «Мобильный клиент», довольно интересная вещь по идее, работает тоже по http, но тут от прикладного программиста этот уровень скрыт, используется стандартное клиент-серверное взаимодействие 1сное, для программиста довольно простое. Насчет производительности — мне кажется не совсем плохо будет. И кстати, можно например на разных серверах публикации сделать, такая себе «ручная балансировка», если считаете именно взаимодействие http->1с слабым местом
Если у Вас есть инфа расскажите пожалуйста. Ведь свой API это как я понимаю через теже модули Apache/IIS проходит? И мобильный клинет тоже — обращается ли он напрямую к серверу (как например десктопный клиент) или же там все опять реально идет все через тот же модуль Apache/IIS?
Нет, там все будет идти через тот же модуль, но честно говоря мне трудно себе представить чтобы он узким местом был. Во первых, выше уже писал, можно на нескольких серверах публикацию сделать. Во вторых — был вот такой вот доклад.
Признаюсь что доклад не сильно впечатлил. В заголовке доклада 3000 одновременно пользователей. Но потом оказывается что они раз в 30 минут создают один документ. Круто. Говоря по другому можно сказать что 30000 пользователей создают документы раз в 5 часов. Но я бы скорее сказал что это эквивалентно что 100 пользователей создают документ раз в минуту.
В принципе я работаю со всем этим со стороны бэкэнд мобильного приложения и в реальности знаю о проблемах. Я не буду говорить какая часть проблем это проблема 1с какая часть это проблема разработчиков конфигурации а какая часть это настройка сервера ну и собственно производительность железа.
Нагрузка у меня довольно высокая. Это 1000 клиентов которые могут все в часы пик начать работать с приложением производя до 10 запросов в минуту. И пришлось довольно долго требовать от стороны 1С чтобы они проработали оптимизацию всей системы. Явных отказов я сейчас уже не наблюдаю. Но время ответа может весьма варьироваться. Такое впечатление что модуль апача не обрабатывает запросы параллельно, хотя все параметры которые в документации с этим связаны были заданы.
Пока что распараллеливания запросы на несколько апачей не делали пока система справляется. Но я не уверен что распараллеливания обязательно даст положительный результат. если узкое место вдруг окажется не на стыке моего бэкэнд с апачем а на стыке апача с 1с то ускорения не получится.
Конечно кто то сказал да там или сисадмина не те или разработчики. Предположим что это так. Но где взять других. В следующий раз когда нужно будет аналогичную связку делать могут быть специалисты получше а могу и похуже. Так что интеграция с мобильными девайсами все же воспринимается как ограничивающий у масштабированию приложения фактор.
У нас мобильных пользователей около 1.5к реальных, правда мобилка на 1с, и у нас все основные данные на мобилку загружаются, а потом пользователь периодически на сервер пакеты данных отправляет или забирает, иногда выполняет полную загрузку всех данных с нуля, пока что упирались больше в то что сервер тормозит из за перегруженных бизнес требований, из за которых в свое время запросов накостылили тяжелых. Хотя запросов у нас к серверу немного, раз в 10-20 минут проверка на наличие обновлений, или отправка собранной истории местоположения, сообщений, документов, логов. Некоторые тяжелые запросы (подготовка слепка полных данных пользователя для закачки в мобилку например) перевели на асинхронный режим, чтобы зазря не ждать и не забивать соединение. И это при том, признаюсь честно, что архитектура кривая. По моим прикидкам 1сную часть еще довольно заметно ускорить можно было бы, будь у нас на это ресурсы. И у нас тоже все пока работает на одном веб-сервере где 1с подвесили. Если добавить второй — ускорения не добьемся из за той самой кривой архитектуры.

Но я не уверен что распараллеливания обязательно даст положительный результат. если узкое место вдруг окажется не на стыке моего бэкэнд с апачем а на стыке апача с 1с то ускорения не получится.

Ускорения не выйдет только в одном случае — перегруз сервера 1с. По сути если у вас два апача на двух машинах в связке с 1с — они будут работать как два клиента к 1с, вместо одного. Соответственно если сервер 1с свободен — не вижу никаких препятствий чтобы ускорение получить.

Правда скажу честно — замеры не делал, и рассуждаю обо всем этом больше теоретически.
Если будете когда-нибудь оптимизировать сервисы мтогу поделиться одной «находкой». После всякого прода оптимизаций (я их не котролировал т.к. это актически другие разработчики и админы) все равно не было сильно большого эффекта. Пока не увеличили количествопользователей 1с (те который указываются в авторизации для SOAP) спасибо подсказал один консултант по этому вопросу.
Где-то на формумах я тоже подобную рекоменацию читал. Вцелом выход на хайлоад такому решению не грозит. А жаль для 1с это был бы огромный плюс если модно было бы связать например миллион орткрытых девайсов с сервером
«Огромный» ли плюс? 1С ведь не позиционируется как замена доске объявлений типа Avito или социальной сети, а компаний в миллионом сотрудников у нас не найти (если только всех военных не объединить), даже в сбере только около полумиллиона сотрудников.
Другое дело, что скорости много не бывает и можно было бы найти новые применения для такой 1С, только это фантастика — под дикие скорости писать всегда неудобно, а фишка 1С — удобная разработка.
Да. Это большой плюс. Даже для маленькой кампании с 100-200 человек сотрудников если например в них 10000 клиентов которые пользуются активно услугами.

Если относится как к диплому, тот да, свежо, если серьёзно, то как минимум надо бы знать что такое DevOps или там ITIL, а этим и не пахнет, но ведь диплом всего лишь учебная работа

про DevOps скорее соглашусь, в статье нет части Ops, хотя в дипломе была эта часть процесса. Поэтому «пахнет», но очень не сильно. Инструментарий для управления зоной Ops как часть конвейера также находится в зоне oscript.io

А вот про ITIL v3 — тут не соглашусь категорично.

Формальная сторона процессов описана как раз в нескольких разделах, например в разделе Continuous Integration: Improving Software Quality and Reducing Risk — при чем так или иначе его используют все, в не зависимости от языка. В первой части диплома приходится ссылаться именно на эти разделы.

Но это действительно лирика, у меня больше вызывает удивление тезис

всего лишь учебная работа


Насколько мне известен учебный процесс, дипломная работа не является учебной, учебными являются курсовые проекты, на базе которых студент и учится (должен учится) выполнять научные работы.

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

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

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

Алексей,


Вы мои опасения подтверждаете. "Поэтому «пахнет», но очень не сильно. Инструментарий для управления зоной Ops как часть конвейера также находится в зоне oscript.io" А ничего что "Operations" это "Эксплуатация"? Там круг задач несколько ширше.
Далее "Continuous Integration: Improving Software Quality and Reducing Risk" это книжка так называется она в ITIL не входит. Автор ссылается на на ITIL "Теоретическим обоснованием проекта был стандарт непрерывного улучшения качества сервиса из ITIL 3.0" Идея хорошая и даже удачная только CSI тут немного не уместен. Он совсем не этим занимается. И самое главное пятая книжка не толстая, страниц этак 240 или около того, но очень заковыристая.


А про "учебность" тут по духу, у 99,99% дипломов практическая значимость — получение диплома выпускником :) и это нормально. Да я не говорю про сам диплом, я же его даже не видел. Просто в "Приключениях Тома Соера" есть 21-я глава про красноречие, там гвоздь программы во время экзаменов чтение старшеклассницами своих сочинений. Прочитать главу надо, понятнее будет.

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

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

С другой стороны в чем вы точно правы — когда дипломная работа готовилась, то внезапно выяснилось, что если зона Dev готова к формализации, то зона Ops выглядит как огромное количество неструктирированных наработок.

Например если перейти по ссылкам и немного покопаться внутри выяснится, что:

* обратную связь от Ops контура для планирования работ по оптимизации мы уже давно реализовали, но формализовать не формализовали — обсуждается в секции форума xdd.silverbulleters.org/t/vopros-professionalnoj-raboty-s-1s-logami-zhurnalami-ms-sql-i-analizom-sobrannoj-informaczii/2090/2

— автоматическое развертывание и provision контуров test-stage-uat предлагается вести через ansible github.com/silverbulleters/add/tree/develop/tools/ansible

То есть — если говорит про запахи — то пахнет достаточно нормально. ;-)

Я сознательно процитировал именно книжку, а не параметры стандарта в зоне service improvement — потому как зимой, когда началась работа над пособием по релиз-инженерии выяснилось, что официально DevOps практики будут включены в ITIL v4, который по моей информации будет опубликован только в первом квартале 2019 года.

И тут налицо коллизия — формально CICD и DevOps могут считаться практиками в зоне «непрерывного улучшения сервиса», но если ссылаться на стандарт ITIL v3 прямых ссылок мы не найдем, приходится ссылаться на разделы с обоснованием в формате «соответствует духу ITIL v3»

И вот что точно необходимо сделать за полгода — это расширить IDEF0 диаграмму до полностью замкнутого контура в части ops и навести порядок в скриптах ansible, terraform и zabbix(elk)

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

Про стандарт ITILv4 у меня информации из подписки на Axelos
What we know so far:

The next iteration of ITIL will be called ITIL 4
The first release of ITIL 4 will be Q1 2019
The core elements of ITIL will remain and will continue to derive from the experiences of thousands of specialists and experts. Research has confirmed that ITIL remains best practice for the ITSM industry.
The update will include practical guidance on how ITIL is adopted in conjunction with practices such as DevOps, Agile and Lean.
Individuals who have already certified will have their current certifications recognised in the new scheme.

Я по ссылкам не ходил, моя основная зона ITSM(по аватарке понятно). Просто в ITIL V2 есть отдельная книга Application management, а в одной из двух основных книг Service Support есть глава 9 Release Management. Только релиз там и к ПО и к инфраструктуре относится. В ITIL v 3 много мути, в теории все правильно, но изящества 2-й нет. И сертификация превратилась в качание бабла.
Чтобы разобраться с ITIL (Cobit,MOF,CMMI etc) нужен некоторый бэкграунд. Я лет 10 назад пояснял страдальцам от .NET что в том же TFS реализован цикл Деминга. Только seniors ни про Деминга ни про PDCA не слыхали, объяснил за 5 мин, благо все на здравом смысле основано.

Мысль о покупке готовой работы не рассматривалась. Хотелось реально что-то сделать самому.

Вариантов тем дипломных проектов рассматривалось много… Короче много всего что было в голове, но ничего из этого не вдохновляло.

Сдаётся мне, эти две фразы исчерпывающе описывают состояние обучения как минимум на данной специальности в как минимум данном вузе. Отсутствие мотивации как у студентов, так и у преподавателей?
Как минимум указывает что студентов учат думать, а преподавателей поддерживать инициативу студентов.
На выбор было достаточно много тем, любую из них можно было выбрать и развить. Но лично мне было не интересно писать 100500 работу как я внедрил документооборот.

Господа, вот вы тут требуете от студента знание методологии DevOps, ITIL, а ничего, что человек на 4 курсе института? Вспомните себя? Или вы уже на третьем все поголовно были Standart, а то уже и Senior! Если, видите, что человек "смотрит" не туда, так покажите ему, куда смотреть и вам зачтется в карму.
Хотя, это наверное все из за того, что "1С" ее почему, то очень многие сильно не любят и любого, кто ей занимается готовы уничтожить.


nlruslan спасибо за статью. Скинул ее знакомым 1С'никам, они довольны.

Спасибо!

Поправлю малость, я не говорил о знании методологий типа DevOps или прочтения всех книжек в ITIL. Я просто заметил, что на данном уровне надо знать, что это такое. Сразу после ВУЗа сертификацию EXIN DevOps Master не одолеть и не потому, что это квалификация менеджера, банально нужен опыт. ITIL Foundation, можно, но лучше не забивать голову. Именно эту сертификацию в RealITSM IT-sceptic, Роб Ингланд то бишь, называет "толкователь".


Для диплома вполне прилично.
Автору
"Экономический эффект возможен только в долгосрочной перспективе. По опыту замечено, что при запуске проекта имплементации инженерных практик фиксируется снижение производительности разработки на 20-30% от текущего уровня."
Честно, но лучше такие выводы ставить в конец. И вместо процентов употреблять слова "несколько", "незначительно" и.т.д в общем понятно.


Дело в том, что применение DevOps практик должно обеспечить как раз противоположный эффект и лучше вчера. Но опять же диплом "по исследованиям", тут это не важно. Следование академическим канонам важнее.


Но "Физики шутят" почитайте

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


Спасибо, учту.
Дело в том, что применение DevOps практик должно обеспечить как раз противоположный эффект


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

1C ники просто крайний случай (один из), не они как люди, а как специалисты по платформе из ж во многих отношения. "Сопротивление изменениям" существует всегда, это уже из области психологии. Задача при применении "хороших практик" преодолеть его используя кнут и пряник. На практике это тяжелая задача, так как нужно сначала уговорить ЛПР, дабы иметь одобрение руководства и административный ресурс, а потом уже браться за реализацию технического проекта. Ошибки не простительны. Это на будущее.

Дело в том, что применение DevOps практик должно обеспечить как раз противоположный эффект и лучше вчера.

Это если у программистов уже имеется необходимый скиллсет — например, навык писать тестируемый код. Иначе пока они научатся и будет та самая просадка 20-30% производительности.
---а ничего, что человек на 4 курсе института? Вспомните себя?

В томском политехе на втором курсе занимался расчетами ядерного взрыва под Токио.
На третьем — индувидиальное обучение и уже фактически только работа на кафедре — госразработка робота для Чернобыля в должности ведущего разработчика.

Но автор молодец — статья и работа грамотно написана.

А можно я не поверю?

Можно конечно. Во что именно?
Невозможность работы на кафедре со 2-го курса?
Невозможность индувидиального обучения в Томском Политехе?
Невозможность моделировать ядерный взрыв в геофизической лаборатории?
Извиняюсь за оффтопик, но
Мысль о покупке готовой работы не рассматривалась.
Неужели для современных вузов самостоятельное написание диплома такое неординарное событие, что это стоит отдельно подчёркивать?
На заочном, практически поголовно.
Вы имеете ввиду Ваш вуз?
Нет. В общей массе знакомых и даже и не в IT сфере.
Странно что GitLab до сих пор рассматривается только как сервер исходных кодов. Хотя у него довольно мощная CI/CD часть. Тоже есть runner, отлично работает как под Windows, так и под Linux.
Ну тут возражений нет. Просто как то привычнее Jenkins с его безумным количеством плагинов на каждый случай жизни.
У GitLab есть один маленький недостаток, он в бесплатной версии не может быть использован только как CI/CD для сборки внешних репозиториев. Repository mirroring есть только в EE редакции. А в Jenkins можно сделать сборку того же nginx из официального репозитория опираясь на их теги.

Минус поставил бы, просто потому — что это будут читать бизнеса.И это чтиво им противопоказано.Принятие де-юре научным сообществом? Слишком громкие слова, потому что по части "выводов" знающие поставили бы двойку. По поводу свежести — да свежо.Но для написания кейса реализации просто на хабре, а не вырезками из диплома, объявлением признания научным сообществом де-юре.И включением это в пособие для всех остальных. Даешь шутки "1С ники настолько крутые, что пособия для них пишут студенты их Томского".Без обид, но просто статья — да, полезно.Вытаскивать это как диплом — не стоило

Ок. Вы знающий. А по сути? Что именно в выводах Вас смутило? Почему описание бизнес-процесса не может быть темой дипломной работы, и почему 5 членов комиссии с интересом слушали и задавали вопросы?
Документооборот это кстати очень интересная тема. Просто ит-сппциалисты не всегда ее представляют во всем объеме, в связи с реальными процессами. При этом не только студенты или разработчики с галер но и те кто работает внутри предприятия и как им кажется знают суть этого вопроса. В этом смысле правильно что Вы ее не взяли.
Какие бизнеса читают это ресурс? Почему противопоказано? Что знают знающие про девопс в 1с? При чем тут Томск?

Поставил бы минус просто потому, что вы после точки пробел не ставите.

На Хабре принято такие вещи писать автору в личку, а не молча минусить.
А с чего вы взяли что я кого-то минусил? У меня даже кармы на это нет.
Этим сообщением я просто выразил своё несогласие и аргументировал это подобным образом.
Да и вообще-то, моё сообщение предназначалось не автору статьи, если вы вдруг так подумали.
Если без лирики, то это квалификационная работа по специальности «бизнес-информатика». Бизнес есть, информатика есть. Кому-то эта работа нужна и приносит материальную выгоду. Перечисленные факты вкупе показывают, что автор подтвердил квалификацию бакалавра.
Термин DevOps звучит красиво, но в данном случае немножко некорректно его применять.

В статье покрыта только та половина ЖЦ, которая относится к «dev». Этим, кстати, в очень большой конторе может заниматься отдельный человек в должности билд-инженера, — когда действительно много проектов, которые все нужно правильно собирать, тестировать, и запаковывать, — на билд-ферме из десятков машин. Но обычно за эту часть процесса (до того, как собранные артефакты попадают в репозиторий) отвечают сами разработчики.

А вот «ops» после публикации артефакта только начинается. Во-первых, среда для тестового/staging деплоя должна автоматизированно разворачиваться в каком-нибудь приватном облаке. В следующих правилам конторах, если operations engineer в своём уме, он никогда не опубликует релизный артефакт сразу в продакшен, даже если все тесты на CI были зелёные. Его нужно прогнать через staging с полной репликой боевого окружения — чтобы убедиться, что он не упадёт копии настоящей базы и приближенной к боевой инфраструктуре. Также, артефакт должен быть автоматически сконфигурирован под тестовое окружение — чтобы не пытаться лазить в боевые инстансы внешних сервисов во время тестирования.

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

Естественно, инфраструктура и бэкапа, и прода в хороших руках управляется из-под системы оркестрирования ресурсов, предполагающей обязательный сбор телеметрии, которая агрегируется в свой собственный набор отчётов — примерно такой же значимости, что и отчёты по тестам. По которым можно ставить задачи по оптимизации перфоманса и ликвидации узких мест… в идеале — аналогично, автоматизированно, прямо в трекер.

Так что operations тема отдельная, и во многом интереснее, чем сборка с автотестами.

Впрочем, даже внедрение первой половины методологии в применении к 1С — это уже неплохо (культуру-то надо повышать). Можно только пожелать автору дойти до конца, и показать когда-нибудь полное внедрение со всеми полагающимися шагами.
Спасибо за замечание. Записал себе в заметки и обязательно подумаю над этим.
половина ЖЦ, которая относится к «dev»


nlruslan — хм, а ведь коллега прав. В статье отсутствует процесс «deploy» который был и есть и делается с помощью deployka github.com/oscript-library/deployka

Видимо надо будет сделать отдельную публикацию по vagrant, docker. ansimble для настройки контуров dev-stage-uat-prod и использующихся инструментах для этого.

Можно только пожелать автору дойти до конца, и показать когда-нибудь полное внедрение со всеми полагающимися шагами.


PastorGL — если можете поверить мне на слово, то автор уже 3 раза прошел полное внедрение со всеми полагающимися шагами. Кроме docker-compose ;-)
PastorGL Обдумал Ваши слова. Как и сказал alexey-lustin, в статью мало попало данных по «ops», хотя в дипломе они были. Сейчас уже начинаю понимать, что возможно не достаточно и тему желательно развить. Думаю в 2-х направлениях:
1. настройка контуров dev-stage-uat-prod
2. Логирование и анализ данных.

Как по тексту так и по комментариям, замечание всем:
Методология — это наука о методиках.


говорите правильно: Методика

Учусь в ТУСУРе заочно на последнем курсе. Диплом собираюсь писать сам :) Может кто и покупает, флаг им в руки. А парень молодец, сделал сам свою тему. Да, это не вечный двигатель, но он молодец, можно только похвалить.
Возможно) Во всяком случае планировал.
Зарубят я думаю. Позиция материнской компании пока лежит в плоскости КИП (корпоративного инструментального пакета). В дипломной работе для построение конвейера сборки использовались фактически только открытые (открытые по лицензиям) инструменты: GitLab, Jenkins, OScript, Vanessa ADD

Фактически у вендора есть внутренние (но платные) альтернативы для всего стека, а именно:

* СППР — умеет хранить исходники и вести задачи (техпроекты)
* GITConverter — конвертирует из Хранилища в формат EDT github.com/1C-Company/GitConverter
* Сценарное тестирование — инструмент отдела тестирования для проверки поведения
* Тест-центр — для проверки производительности
* Центр администрирования — wonderland.v8.1c.ru/blog/1s-tsentr-administrirovaniya-administrirovanie-eto-prosto

По данным прошлого года единственное на что похожа данная дипломная работа — это на

Инструментальные средства CASE-моделирования информационных систем субъектов экономической деятельности на платформе «1С: Предприятие»


Отсюда 1c.ru/news/info.jsp?id=23700
Если не пытаться, то точно ничего не получится.
Ну давай поиграем в эту игру ;-). Давай подадим. НО чур не расстраиваться, «если чё».
СППР умеет хранить исходники??
Метаданных как минимум ;-). Чтобы модель строить. Ох про АПК то я забыл сказать — вот он точно умеет их хранить.

Все можно заменить :)
СППР — Jira — Redmine — GitLab Issue
GitConverter можно вообще не использовать если разрабатываешь в формате EDT
Сценарное тестирование — Ванесса — xUnit
Тест-центр — Zabbix
Центр администрирования — Gitlab CI — Jenkins — Ansible — Kubernetes (все завсит от того любишь ты больше оркестрацию или развертку)
SonatQube — АПК


Так же в списке нет — отдельно юнит-тесты пишут с расширениями в роли моков.
А еще есть механики, которые проверить можно только SikuliX, например нажатие на кнопочку загрузки файла в веб-клиенте.


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

Дык мы то знаем, но я к тому что могут зарубить с формулировкой «У нас применяются другие инструменты.
Очень похожая история. Я учился по направлению «Системы корпоративного управления», параллельно работал в вузе в отделе поддержки и разработки внутренних информационных систем. Работали с 1С…
шучу, не с ним, а с 1С Битрикс.
Т.к. в штате были одни студенты пришлось добавлять в процесс разработки процедуры контроля качества кода, начиная от банального написания подробной инструкции как у нас принято писать код и заканчивая развёртыванием собственного CI сервера. не долго думая я взял все свои наработки и оформил в качестве диплома.
Отлично! Только за труд по систематизации инструментов по 1С 8.х надо диплом дать!
Большую часть того что тут написано, многие «синьеры» от 1С не понимают не хотят знать.
А уж статическое или функциональное тестирование код 1С, это вообще для большинства программистов просто фантастика.
Сейчас это только в больших коллективах, где хоть кто-то из руководства понимает необходимость этого.

Devops в 1с не оправдан, эффективность затраты/результат низкая. Платформа такие практики не поддерживает, пока не перейдет на модель работы с текстовыми файлами, как у других языков. Пытаться прикрутить их через сторонние решения лишь удлинняет время разработки и удорожает стоимость (г...)кода студентов-"программистов" 1с.

Позвольте не согласиться с вами:
1. Выгрузка в файлы уже давно реализована v8.1c.ru/overview/Term_000000606.htm. Используемые инструменты, зачастую являются оболочками над пакетным запуском 1С.
2. 1C сама развивает свою конфигурацию для тестирования wonderland.v8.1c.ru/blog/1s-tsentr-administrirovaniya-administrirovanie-eto-prosto Насколько она хороша/плоха говорить не буду.
3. EDT, который позиционируется как будущая замена конфигуратора — использует GIT как основной инструмент хранения версий. Причем, хранилище (старую систему контроля версий) — разработчик сказал поддерживать не будет v8.1c.ru/overview/release_IDE_beta

Вот уж нет. Мои 4 года в стиле автоматизации dev и ops для 1С говорят ровно об обратном. После получения кнопки «развернуть в продуктив» на веб-морде сервера интеграции, отдел эксплуатации (то бишь, ops) уже ни в какую не хотят жить без нее. А после получения приемочно-дымовых тестов, позволяющих тыкнуть мордой разработчиков (dev), приславших кривой релиз — они вообще стали счастливы.

Далее следует переход на парадигму «dev+ops живут в одной лодке», но у нас в конторе до этого пока не доросли ментально обе стороны. Тем не менее, польза налицо.
Devops в 1с не оправдан, эффективность затраты/результат низкая.

Весьма сомнительное утверждение — конечно, одно дело когда надо «а потомучто главбух хочет» немного какой-то отчет поправить в конторе на 1.5 человека, там не нужны ни DevOps, ни (периодически) даже программист (ключевое преимущество 1С для российского рынка — при необходимости, видел сам примеры, бухгалтера сами могли что-то «дорисовать» потому что по-русски и часто понятно), с другой — заваленный релиз даже среднего размера конторе (500+ человек) с самописным решением грозит минимум дневным простоем, что сразу окупает даже двукратный рост сроков разработки
А можно ссылку на библиотеку для расчета цикломатичности кода для onescript? Что-то нигде найти не могу. Или она сейчас входит в состав Vanessa-ADD?
Суть в том что формально это перенос кода из infostart.ru/public/166182

Обработка предназначена для автоматизированного расчета цикломатической сложности кода


Цитата из кода

* Вы можете использовать обработку по своему усмотрению в рамках действующего законодательства.
* Единственная просьба: если у вас есть замечания или предложения по улучшению обработки, а также в случае нахождения багов — пишите мне об этом на infostart.ru/profile/101097

Выложил на gist gist.github.com/allustin/2cec4a7c19b74b2d592c978e34bf2f1c
Мне до конца неясно можно ли публично распространять, потому как автор с 2015 года не появлялся на Инфостарте
А можете что-нибудь порекомендовать по такой теме анализа дерева вызова процедур или функций? Есть некоторые публикации на эту тему, но они не очень свежие:
Трассировка кода: infostart.ru/public/164960
Граф вызовов для модулей 1С + GML на ОФ: infostart.ru/public/190199
Аналог предыдущего на УФ: github.com/SergeFocus/1C-Functin-to-yEd

Хотелось бы узнать, вы чем-то подобным пользуетесь, и как вообще сейчас можно быстро построить такое дерево? Какие-то может еще инструменты для этого есть?
Выводы интересные в статье про экономический эффект, повышение стабильности и снижение трудозатрат.

Здесь хочу вспомнить цитату компьютерного учёного Дэвида Уилера: «Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности».

Наверное, DevOps — это новый уровень косвенности, который при росте сложности информационной системы становится просто необходим, чтобы сохранять контроль над ней.

И нужно понимать, что сама сложность с внедрением DevOps никуда не девается, а ещё даже и приумножается. Т.е. вам всё равно нужны будут дополнительные ресурсы, чтобы помимо разработки непосредственно программы, выделять их ещё и средствам автоматизации разработки.

Грубо говоря, раньше вы чинили программу. Сейчас вам нужно чинить ещё и DevOps, когда он ломается.

Что DevOps действительно даёт вам, так это резерв времени: вы узнаёте о том, что что-то сломалось раньше и успеваете починить программу до того, как дефект доходит до конечного пользователя.
Нуу, как-то так, да. Компьютеры помогают решить проблемы, которые не существовали до их изобретения :)
Хороший диплом, показывающий, что человек не поленился и скомпоновал актуальные инструменты в полезную систему, решающую его прикладные задачи. Насчёт научной ценности — очень сомневаюсь, а вот как повод принять автора на работу — отлично.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.