Предисловие
?Все началось более 2-х лет тому назад, и я перешел на 4-й курс специальности "Бизнес-информатика" Томского Государственного Университета Систем Управления и Радиоэлектроники (ТУСУР). До окончания ВУЗА оставалась не много времени, и перспектива написания диплома уже маячила перед глазами. Мысль о покупке готовой работы не рассматривалась. Хотелось реально что-то сделать самому. Вариантов тем дипломных проектов рассматривалось много: и проекты конфигураций для автоматизации производственных нужд компании и проект внедрения Документооборота своими силами на 3 территориальные единицы и более 500 активных пользователей и внедрение ЭДО. Короче много всего что было в голове, но ничего из этого не вдохновляло. А это было главное.
В это время я работал в одной уважаемой компании и по делам службы познакомился с одним классным программистом и вообще хорошим человеком Андреем Щегловым (Привет Андрей!) и как =-то за разговором он у меня спросил, слышал ли я что-нибудь об OneScript и языке сценариев Gherkin. На что и получил ответ что нет, не слышал. Естественно, вечернее гугление/яндексение и бессонная ночь привела на мысль что вот он — мир неизведанного. Но идея о том, что это может стать темой дипломной работы пока не зарождалась. Рутинный круг обязанностей составлял обычную работу в Конфигураторе 1С по-задачно, как вы понимаете с ручным тестированием и не позволял полностью погрузиться в новый подход в мире 1С.
Незнакомые понятия
? Первая трудность с чем я столкнулся, это неимоверное количество различных терминологий и инструментов, о которых вообще не слышал — так как я в тот момент был «типичным одинэсником» (в этот момент начинается холивар…) Особо не владея никакими другими языками программирования, и к тому же методологии большого IT для меня были абсолютно не знакомыми, мне приходилось прыгать с темы на тему, чтобы хоть как-то наполнить свой глоссарий.
? Практически в этот же момент я (мы – и мои коллеги) столкнулись с довольно специфичной проблемой. Приняли программный модуль от подрядчика, проверили на копии. Вроде все работает. Но так как работы было очень много, то подписали акт выполненных работ и закинули в продуктив. Все было хорошо в течении полугода, пока данных в этой подсистеме не превысило допустимого. И начали происходить очень странные вещи. Проведение документа из модуля стало происходить по 5-10 минут, появились куча ошибок ну и.т.п. Просмотр программного кода привел в ужас (не спрашивайте почему это не сделали раньше при приемке…). Количество вложенных циклов было просто за гранью разумного. Единственный запрос в четвертом цикле и обращение через 4 точки были мелочами, перебор всех предыдущих документов для заполнения текущего документа, 10-ти кратный копипаст одного и того же блока и много еще чего.
Пример вложенности:
Дублирование полей в макете:
Причем для заполнения этих полей, 14-ти кратный кописпаст.
Начало цикла:
И пока переменная ФФ не достигнет 15:
Ну и еще куча других не менее уникальных произведений искусства.
? Вдруг я вспомнил, что для OneScript есть простенькая библиотека для расчета "цикломатичности" модуля(1) (сложности модуля или метода). Нашел, рассчитал. Получил значение 163 единицы, при допустимом значении не более 10. И пришел к выводу, что приемочное тестирование программного кода должно быть обязательно и оно должно быть автоматическим и непрерывным. Тогда я узнал о Continuous Inspection — причем как оказалось еще в 2006 году компания IBM сделала(2) публикацию на эту тему.
Правило избегать чрезмерной сложности у miscrosoft имеет даже специальный код CA1502 https://msdn.microsoft.com/ru-ru/library/ms182212.aspx
Презентация концепции и инструмента для анализа java проектов на базе ant — https://www.ibm.com/developerworks/library/j-ap08016/j-ap08016-pdf.pdf
? Дальше больше. Наверное, многие работающие в крупных компаниях встречались с проблемой разворачивания копии рабочей базы на локальной машине разработчика. Когда эта база весит 5-10 гбт – это не проблема, а когда она только в бэкапе весит почти терабайт то это уже серьезно. В итоге для того, чтобы развернуть у себя свежую копию тратилось по 5-6 часов рабочего времени. Когда мне это надоело я начал пользоваться очень хорошим инструментом 1C-Deploy-and-CopyDB (Антон спасибо!) Тогда я понял, что автоматизация – это классно.
? Дальше были другие задачи, например, регулярное обновление основной и распределенной базы из хранилища ночью, тестирование форм, сценарные тесты и.т.д. Что-то было из этого реализовано, а что-то нет.
? Но все это нужно было только мне. При поиске единомышленников в своем городе практически потерпел фиаско. Их нет. Хотя жутко странно, так как проблемы типичные. В этот момент я уже знал, что хочу написать свою дипломную работу именно по этой теме. Но что писать – не знал. Поэтому пришлось подключиться к сообществу в качестве уже не просто читающего, а как минимум пишущего и задающего вопросы. Основными местами, где можно задавать вопросы оказались
Github проекты:
• https://github.com/silverbulleters/add
• https://github.com/oscript-library/opm
• https://github.com/EvilBeaver/OneScript
• https://github.com/silverbulleters/vanessa-runner/
Форум XDD:
• раздел по автоматизации процесса
Ну и как средство быстрой связи — профильные группы в Gitter
? Начался сбор материала. Волею судеб мне удалось мне связаться на форуме XDD с Алексеем Лустиным alexey-lustin (Привет Алексей!) и рассказать про мою идею диплома. На что, с удивлением услышал, одобрительный отзыв и даже приглашение пройти в компании «Серебряная Пуля» преддипломную практику. Это была уже победа. В течении нескольких часов мы придумывали тему и содержание диплома. Ставили задачи на практические работы. Получил руководителя дипломного проекта от компании — Артур Аюханов (Артур привет!) Как юный падаван получил доступ к видеокурсу релиз-инженера и возможности неограниченно доставать Никиту Грызлова (Привет Никита!) своими вопросами, за что ему очень признателен.
В итоге:
Тема диплома — «Автоматизированное управление жизненным циклом информационных систем — системная и программная инженерия решений на платформе 1С: Предприятие в условиях непрерывного улучшения качества процесса производства».
Цель выпускной квалификационной работы (ВКР) — выявление взаимосвязи программных инструментов и описание бизнес-процесса работы контура DevOps в области 1С.
Теоретическим обоснованием проекта был стандарт непрерывного улучшения качества сервиса из ITIL 3.0, а в качестве практического объекта было выбрано построение контура непрерывной интеграции для нового прикладного решения, которое мы разработали – личный кабинет покупателя. Для этого был развернут сервер исходных кодов GitLab и сборочный контур Jenkins. Прогон тестов осуществлялся на выделенном сервере (Windows Slave). Выгрузка конфигурации из хранилища 1С осуществлялась посредством библиотеки Gitsync, редакция 3.0
(в настоящий момент размещен в ветке develop) уже с наработками Алексея Хорева (Леха привет!) с периодичностью 30 минут в ветку develop. Причиной выбора именно этой версии была возможность подключения к хранилищу через протокол tcp, который, к сожалению, не поддерживал на тот момент типовой GitSync 2.x. Если в GitLab фиксировались изменения, то автоматически запускался прогон контура непрерывной интеграции.Так как бюджет всего мероприятия был нулевым, и возможности построить полноценную проверку качества программного кода без покупки модуля для SonarQube было невозможно, то в качестве упрощенного решения использовалась типовая проверка синтаксиса 1С. Хотя разовые выгрузки все-таки были сделаны, а результаты были получены и проанализированы. Также были использованы дополнительные проверки на цикломатичность и на наличие повторно используемого кода.
? На этапе тестирования функционала были задействованы 2 фреймворка Vanessa-Behavior и XUnitFor1C в их объединенном варианте под названием Vanessa Automation Driven Development (Vanessa ADD). Первый использовался для запуска тестировании ожидаемого поведения, вторым осуществлялась проверка открытия форм (дымовое тестирование). Результатом прохождения контура непрерывной интеграции были автоматически сгенерированные отчеты.
По результатам тестирования, релиз – инженер принимал решение о слиянии ветки develop и master, и запускал (уже вручную) третью задачу – публикацию изменений в продуктивную базу. Продуктивная база не подключена к хранилищу и полностью закрыта от ручных изменений. Обновление осуществляется только через поставку, причем в автоматическом режиме.
? Для описания бизнес-процесса работы контура была сформирована диаграмма IDEF0 состоящая из 4 последовательных блоков, формирующих прохождение контура. Ошибка возникающая при прохождении любого из этапов прерывает сборочный процесс с оповещением релиз-инженера и передает управление на 5 блок сборочного процесса, где и формируются отчеты в в формате ALLURE, JUNIT и конечно cucumber.json.
Описание модели IDEF0
Процесс «Выгрузка исходников в GIT»
Входные данные(Input): – Хранилище конфигурации
Выходные данные (Output): – Исходный код
Управление (Control): Инструкции по работе с ПО, сборочный скрипт
Механизм (Mechanism): 1С: Предприятие, Gitsync.
Обязательным условием существования контура является наличие файлов исходного текста. С версии платформы 8.3.6 компания 1С предоставила возможность выгрузки исходных кодов конфигурации в файлы. Следует учесть, что данный процесс может иметь несколько вариантов исполнения, зависящих от специфики разработки в IT отделе. В текущем варианте для упрощения процесса перехода сотрудников к новой методике была выполнена интеграция с текущим процессом разработки через хранилище конфигурации и используя конфигуратор 1С.
На этапе выполнения процесса «Выгрузка исходников в GIT» будет произведено создание файловой, служебной информационной базы 1С; осуществлено ее подключение к хранилищу конфигурации под служебной учетной записью; получены все изменения на текущий момент времени (или последнему коммиту в хранилище); произведена выгрузка исходников в сборочную директорию; сделан коммит в систему хранения версий GIT; изменения отправляются на сервер исходных кодов GitLab
Процесс «Тестирование качества исходного кода»
Входные данные(Input): – Исходный код
Выходные данные (Output): – Исходный код
Управление (Control): Инструкции по работе с ПО, сборочный скрипт
Механизм (Mechanism): 1С: Предприятие, Deployka, SonarQube, Cyclo.os — (к сожалению ссылки нет)
На момент старта данного процесса, исходный код хранится в репозитарии GitLab. С помощью управляющего (сборочного) скрипта производится получение его в сборочную директорию. Средствами платформы 1С: Предприятие, на основании этих исходных кодов разворачивается служебная информационная база. Производится анализ ошибок средствами платформы. В случае, если при выполнении анализа будут обнаружены ошибки программного кода, не позволяющие собрать конфигурацию, то процесс прервется. Цель данного шага – исключение потерь времени на анализ программного кода неработоспособной конфигурации.
После проверки на ошибки запускается подсчет цикломатической сложности программного кода. Увеличение этого коэффициента существенно отражается на отладке и анализе программного кода. Максимально допустимое значение 10. При превышении вызывается исключение, и код возвращается на доработку.
Заключительным шагом анализа качества программного кода является проверка на соответствие стандартов разработки. Для этих целей в предложенной схеме используется сервис SonarQube и разработанным для него модулем поддержки синтаксиса 1С от компании «Серебряная пуля». По результатам анализа система рассчитывает значение технического долга для каждого сотрудника, разместившего программный код.
Процесс «Тестирование функционала»
Входные данные(Input): – Исходный код
Выходные данные (Output): – Исходный код
Управление (Control): Инструкции по работе с ПО, сборочный скрипт
Механизм (Mechanism): 1С: Предприятие, Vanessa-Behavior, XunitFor1C.
В процессе разработки могут происходить ситуации, что новый функционал может нарушить работу уже существующих подсистем. Это может проявляться как формировании исключений, так и выводе не ожидаемого результата. Для этих целей производится тестирование ожидаемого поведения системы.
Для данного контура применимо несколько методов разработки и тестирования: TDD (Test Driven Development) и BDD (Behaviour Driven Development)
На момент написания ВКР, для выполнения тестов по Методике BDD использовался фреймворк Vanessa-bahavior, для TDD – XunitFor1C. В настоящий момент они объединены под одним продуктом Vanessa-ADD. Поддержка старых продуктов разработчиком прекращена. Результаты тестирования выводятся в файлы отчетов Yandex Allure и Xunit.
Процесс «Сборка поставки»
Входные данные(Input): – Исходный код
Выходные данные (Output): – Поставка конфигурации
Управление (Control): Инструкции по работе с ПО, сборочный скрипт
Механизм (Mechanism): 1С: Предприятие, packman.
В данном процессе происходит окончательная сборка поставки конфигурации для развертывания в целевой системе. Проверенный исходный код находится в ветке develop репозитария исходных кодов GitLab. Для формирования поставки необходимо, что бы изменения из ветки develop появились в ветке master. Это действие может происходить как вручную, так и автоматически и регламентируются требованиями IT подразделения использующего контур CI/CD. После слияния веток запускается процесс сборки готовой поставки. Для этого опять в сборочной директории, на основании существующих исходников, создается служебная информационная база, и затем, средствами платформы 1С: Предприятие формируется поставка конфигурации и архивируется. Поставка конфигурации является финальным продуктом сборочного процесса и поставляется заказчику по установленным каналам связи или же устанавливается непосредственно в продуктивную информационную систему.
Процесс «Публикация результатов»
Входные данные(Input): – Результат выгрузки, файлы отчетов
Выходные данные (Output): – Отчет
Управление (Control): Инструкции по работе с ПО, сборочный скрипт
Механизм (Mechanism): Yandex Allure, Xunit.
При выполнении этапов процесса, инструменты тестирования создают как побочный продукт файлы отчета в определенных форматах. Задача данного процесса произвести группировку, преобразование и публикацию для удобства анализа данных. В случае формирования исключения на каком-то этапе сборки и при наличии нужной настройки система должна автоматически уведомить администратора контура о наличии проблем. Этот этап выполняется в постобработке сборочного процесса и должен выполниться вне зависимости от результатов предыдущих процессов.
Для осуществления обратной связи, помимо почтовой рассылки, использовалась интеграция с корпоративным менеджером Slack, куда посылались все информационные сообщения по поводу статусов сборки, появлении новых коммитов, формировании бэкапов, а также контроль функционирования служб, как связанных с контуром DevOps, так и с 1С в целом.
Результатами моего проекта стала защита ВКР в конце мая этого года с результатом «отлично». Дополнительно, была актуализирована методическая информация по формированию контура.
Общие выводы:
- Экономический эффект возможен только в долгосрочной перспективе. По опыту замечено, что при запуске проекта имплементации инженерных практик фиксируется снижение производительности разработки на 20-30% от текущего уровня. Этот период временный, и как правило производительность возвращается к первоначальным значениям через три – четыре месяца эксплуатации. Снижение производительности связанно прежде всего, с тем, что разработчику приходится привыкать к новым требованиям разработки: написанию сценариев, тестов, формированию технической документации.
- Существенно повысилось стабильность продуктивной информационной системы, за счет тестирования программного кода. Гарантированная работа критически важных подсистем обеспечена покрытием сценарными тестами. За счет этого снизились риски компании на критически важном направлении — оперативное взаимодействие с клиентами.
- Исключение динамических исправлений на продуктивной информационной базе позволило более конструктивно планировать разработку и исключить попадание программного кода в обход контура тестирования.
- Снижение трудозатрат на сервисное обслуживание информационной базы, за счет автоматизации сборочного контура.
- Использование обратной связи через Slack позволило в оперативном режиме контролировать и исправлять проблемы жизненного цикла системы. По отзывам команды, использование месенджера, удобнее почтовой рассылки (хотя она тоже присутствует).
- Использование автоматизированной проверки программного кода (Continuous Inspection) на соответствие стандартам разработки (SonarQube) вынуждает разработчиков самостоятельно повышать компетенцию, а исправление выявленного технического долга непосредственно при разработке программного модуля происходит гораздо быстрее, так как не надо тратить время на восстановление контекста задачи.
- Включение функционала авто-документации и генерации видео-инструкций позволяют снизить количество обращений пользователей.
- В ходе выполнения проекта был сформирован бизнес-процесс, описывающий жизненный цикл разработки и тестирования прикладных решений 1С, который в свою очередь повлиял на формирование проекта имплементации инженерных практик. Сформирован набор инструментов и документации, позволяющий быстро развернуть окружение на любых проектах 1С.
Если говорить о сложностях с которыми я столкнулся во время реализации проекта, то они абсолютно такие же как в статье Сопротивления автоматизации тестирования. В 90% случаев связанны либо со внутренним сопротивлением компании на изменение существующей модели разработки либо отсутствием на тот момент достаточных знаний.
Что же касается личных результатов, то они такие:
- На сколько я знаю, на текущий момент это первый диплом по теме "Имплементации инженерных практик в 1С. Де-юре можно сказать, что инженерные практики пусть и в начальном варианте, но приняты научным сообществом (пусть их и было 5 человек).
- Подобный академический подход позволил ускорить выход “Методического пособия релиз инженера 1С”. Часть контента из дипломной работы плавно перекочевала в контент книги. (Ссылка к сожалению, запрещена модератором вне рубрики "Я пиарюсь". Кому потребуется смогут легко найти в поиске).
- Проработка модели процесса и проверка инструментария для CICD в 1С позволило исправить мелкие недочеты при первом старте и подключении к процессу, кстати уже и мои доработки приняты в основной ствол и войдут в релиз 5.5.0.
В заключении, хочу сказать, что 1С хоть и медленно, но двигается к полноценному DevOps. В настоящее время достаточно инструментов для построения контуров, но несколько тормозит процесс развития — это недостаточное количество специалистов DevOps в среде 1С и незнание руководителей о существовании таких возможностей.
Буду очень признателен, если Вы приведете свое мнение о концепции DevOps в 1С. Чего по вашему мнению не хватает отрасли?
Комментарии (88)
REPISOT
19.08.2018 11:55Название работы должно содержать не более 11 слов. Иначе оно не воспринимается аудиторией.
Bedal
20.08.2018 10:12Смотря какой аудиторией. «Осесимметрическая задача о падении тупого твёрдого тела на поверхность несжимаемой жидкости при дозвуковой скорости движения границы области контакта» — в своё время никого не смутила. Подскажете, может, какое слово тут можно выбросить?
REPISOT
22.08.2018 06:03А вы ко всем подходили и спрашивали: «а вас не смутило название?» Или все молча сидели с каменными лицами «нам все понятно, заканчивай быстрее»?
А название придумать так, чтобы уместить смысл в нужное число слов — это часть работы над дипломом.Bedal
22.08.2018 07:45Всегда говорил, что у айтишников жизнь лёгкая — и ведь Вы айтишник? :-)
Ту же самую работу можно было назвать «приводнение капсулы космического корабля»… если бы речь шла о посте на гиктаймсе. А «там» сидели как раз люди в теме, которым название должно было строго описывать содержание. Изменение одного слова может означать, что решается совсем другая задача. Так что с теми, к кому можно было подойти — всё было в порядке.ildarz
22.08.2018 11:28Ту же самую работу можно было назвать «приводнение капсулы космического корабля»… если бы речь шла о посте на гиктаймсе.
А вот, например, "К электродинамике движущихся тел" — это для Гиктаймса название или для "людей в теме"? :)
Bedal
22.08.2018 11:34Не начинайте передёргивать. Никто не говорит о невозможности коротких названий — чем более общим вопросам посвящена работа, тем короче возможное название.
apapacy
19.08.2018 12:08-1Явно зря минусуют.
fdroid
19.08.2018 21:51-1Потому что рефлекс на «1С». Не думаю, что всем подряд кровь свернули продукты этой компании, но «если 1С — сразу минус!» просто потому что как в анекдоте про обезьян, банан, и электрический ток — «тут так принято!»
Apatic
20.08.2018 15:34Ну вы что, это ж 1С!
Каждый эникейщик считает своим долгом отреагировать: «Гыгыгыгы вы видели, там буковки русские! Да и ПО русское, что за говно. Тоже мне программисты! Вот мы на первом курсе в Visual Basic формочки рисовали, вот это, да, вот это программирование было!».
Большинство таких людей никогда не видело других подобных систем (потому что в России их в мелком/среднем бизнесе и нет в общем-то) и просто не представляют всех реальных плюсов и минусов платформы 1С.
Впрочем, есть и объективные причины для прохладного отношения к 1С-никам, но это тема отдельной статьи и причины эти к данному случаю точно не относятся.Neikist
20.08.2018 15:40По моему за русскоязычный синтаксис уже давно не высмеивают. Высмеивают общий низкий уровень программистов, также высмеивают слишком простой язык с большим количеством ограничений по сравнению с другими современными языками. Еще иногда вендора высмеивают, но это уже знающие больше. Хотя есть конечно отдельные хейтеры простопотомушта, но таких мало.
Apatic
20.08.2018 15:44Тогда вам повезло. Мне в основном встречаются те, что «простопотомушта».
Вы перечислили объективные причины как раз, плюс еще пару я бы добавил.
Но обычно начинаешь спрашивать, чем конкретно не нравится 1С/1С-ники, ничего вразумительного ответить не могут. Может мне просто не везет так.Neikist
20.08.2018 15:51Да в общем за те же причины (убогость языка в каких то аспектах и низкий средний уровень) и js с php любят высмеивать. Хотя их поменьше хейтят. Про бейсик и вспоминать не буду.
apapacy
20.08.2018 15:51У меня один хороший знакомый «громит» 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с а просто отсутсвие таого алгоритма. Если кто-то его напишет в конфигурации или в виле нативного модуля то это будет работать.Neikist
20.08.2018 15:57Ну, не совсем апач, можно и IIS. Плюс можно кроме rest (платформенного: oData) и soap — свой api поверх http написать.
Плюс есть «Мобильный клиент», довольно интересная вещь по идее, работает тоже по http, но тут от прикладного программиста этот уровень скрыт, используется стандартное клиент-серверное взаимодействие 1сное, для программиста довольно простое. Насчет производительности — мне кажется не совсем плохо будет. И кстати, можно например на разных серверах публикации сделать, такая себе «ручная балансировка», если считаете именно взаимодействие http->1с слабым местомapapacy
20.08.2018 16:04Если у Вас есть инфа расскажите пожалуйста. Ведь свой API это как я понимаю через теже модули Apache/IIS проходит? И мобильный клинет тоже — обращается ли он напрямую к серверу (как например десктопный клиент) или же там все опять реально идет все через тот же модуль Apache/IIS?
Neikist
20.08.2018 16:11Нет, там все будет идти через тот же модуль, но честно говоря мне трудно себе представить чтобы он узким местом был. Во первых, выше уже писал, можно на нескольких серверах публикацию сделать. Во вторых — был вот такой вот доклад.
apapacy
20.08.2018 20:48Признаюсь что доклад не сильно впечатлил. В заголовке доклада 3000 одновременно пользователей. Но потом оказывается что они раз в 30 минут создают один документ. Круто. Говоря по другому можно сказать что 30000 пользователей создают документы раз в 5 часов. Но я бы скорее сказал что это эквивалентно что 100 пользователей создают документ раз в минуту.
В принципе я работаю со всем этим со стороны бэкэнд мобильного приложения и в реальности знаю о проблемах. Я не буду говорить какая часть проблем это проблема 1с какая часть это проблема разработчиков конфигурации а какая часть это настройка сервера ну и собственно производительность железа.
Нагрузка у меня довольно высокая. Это 1000 клиентов которые могут все в часы пик начать работать с приложением производя до 10 запросов в минуту. И пришлось довольно долго требовать от стороны 1С чтобы они проработали оптимизацию всей системы. Явных отказов я сейчас уже не наблюдаю. Но время ответа может весьма варьироваться. Такое впечатление что модуль апача не обрабатывает запросы параллельно, хотя все параметры которые в документации с этим связаны были заданы.
Пока что распараллеливания запросы на несколько апачей не делали пока система справляется. Но я не уверен что распараллеливания обязательно даст положительный результат. если узкое место вдруг окажется не на стыке моего бэкэнд с апачем а на стыке апача с 1с то ускорения не получится.
Конечно кто то сказал да там или сисадмина не те или разработчики. Предположим что это так. Но где взять других. В следующий раз когда нужно будет аналогичную связку делать могут быть специалисты получше а могу и похуже. Так что интеграция с мобильными девайсами все же воспринимается как ограничивающий у масштабированию приложения фактор.Neikist
20.08.2018 21:12У нас мобильных пользователей около 1.5к реальных, правда мобилка на 1с, и у нас все основные данные на мобилку загружаются, а потом пользователь периодически на сервер пакеты данных отправляет или забирает, иногда выполняет полную загрузку всех данных с нуля, пока что упирались больше в то что сервер тормозит из за перегруженных бизнес требований, из за которых в свое время запросов накостылили тяжелых. Хотя запросов у нас к серверу немного, раз в 10-20 минут проверка на наличие обновлений, или отправка собранной истории местоположения, сообщений, документов, логов. Некоторые тяжелые запросы (подготовка слепка полных данных пользователя для закачки в мобилку например) перевели на асинхронный режим, чтобы зазря не ждать и не забивать соединение. И это при том, признаюсь честно, что архитектура кривая. По моим прикидкам 1сную часть еще довольно заметно ускорить можно было бы, будь у нас на это ресурсы. И у нас тоже все пока работает на одном веб-сервере где 1с подвесили. Если добавить второй — ускорения не добьемся из за той самой кривой архитектуры.
Но я не уверен что распараллеливания обязательно даст положительный результат. если узкое место вдруг окажется не на стыке моего бэкэнд с апачем а на стыке апача с 1с то ускорения не получится.
Ускорения не выйдет только в одном случае — перегруз сервера 1с. По сути если у вас два апача на двух машинах в связке с 1с — они будут работать как два клиента к 1с, вместо одного. Соответственно если сервер 1с свободен — не вижу никаких препятствий чтобы ускорение получить.
Правда скажу честно — замеры не делал, и рассуждаю обо всем этом больше теоретически.apapacy
20.08.2018 22:33Если будете когда-нибудь оптимизировать сервисы мтогу поделиться одной «находкой». После всякого прода оптимизаций (я их не котролировал т.к. это актически другие разработчики и админы) все равно не было сильно большого эффекта. Пока не увеличили количествопользователей 1с (те который указываются в авторизации для SOAP) спасибо подсказал один консултант по этому вопросу.
Где-то на формумах я тоже подобную рекоменацию читал. Вцелом выход на хайлоад такому решению не грозит. А жаль для 1с это был бы огромный плюс если модно было бы связать например миллион орткрытых девайсов с серверомBerkof
21.08.2018 15:05«Огромный» ли плюс? 1С ведь не позиционируется как замена доске объявлений типа Avito или социальной сети, а компаний в миллионом сотрудников у нас не найти (если только всех военных не объединить), даже в сбере только около полумиллиона сотрудников.
Другое дело, что скорости много не бывает и можно было бы найти новые применения для такой 1С, только это фантастика — под дикие скорости писать всегда неудобно, а фишка 1С — удобная разработка.apapacy
21.08.2018 15:09Да. Это большой плюс. Даже для маленькой кампании с 100-200 человек сотрудников если например в них 10000 клиентов которые пользуются активно услугами.
zirf
19.08.2018 12:42+1Если относится как к диплому, тот да, свежо, если серьёзно, то как минимум надо бы знать что такое DevOps или там ITIL, а этим и не пахнет, но ведь диплом всего лишь учебная работа
alexey-lustin
20.08.2018 08:36про DevOps скорее соглашусь, в статье нет части Ops, хотя в дипломе была эта часть процесса. Поэтому «пахнет», но очень не сильно. Инструментарий для управления зоной Ops как часть конвейера также находится в зоне oscript.io
А вот про ITIL v3 — тут не соглашусь категорично.
Формальная сторона процессов описана как раз в нескольких разделах, например в разделе Continuous Integration: Improving Software Quality and Reducing Risk — при чем так или иначе его используют все, в не зависимости от языка. В первой части диплома приходится ссылаться именно на эти разделы.
Но это действительно лирика, у меня больше вызывает удивление тезис
всего лишь учебная работа
Насколько мне известен учебный процесс, дипломная работа не является учебной, учебными являются курсовые проекты, на базе которых студент и учится (должен учится) выполнять научные работы.
Первой, пусть и базовой научной работой, является диплом студента — он даже называется по другому «квалификационная работа».
Обычно в качестве такой квалификационной работы выбирается научное исследование, внедряющее в практику результаты конкретных фундаментальных и прикладных исследований.
Если бы вы написали «На кандидатскую не тянет» это бы было понятно, но тезис всего лишь «учебная работа» наводит на мысль, что вы либо пытаетесь принизить значимость произведенных трудов, либо не понимаете откуда берутся «доктора наук».
zirf
20.08.2018 13:04Алексей,
Вы мои опасения подтверждаете. "Поэтому «пахнет», но очень не сильно. Инструментарий для управления зоной Ops как часть конвейера также находится в зоне oscript.io" А ничего что "Operations" это "Эксплуатация"? Там круг задач несколько ширше.
Далее "Continuous Integration: Improving Software Quality and Reducing Risk" это книжка так называется она в ITIL не входит. Автор ссылается на на ITIL "Теоретическим обоснованием проекта был стандарт непрерывного улучшения качества сервиса из ITIL 3.0" Идея хорошая и даже удачная только CSI тут немного не уместен. Он совсем не этим занимается. И самое главное пятая книжка не толстая, страниц этак 240 или около того, но очень заковыристая.
А про "учебность" тут по духу, у 99,99% дипломов практическая значимость — получение диплома выпускником :) и это нормально. Да я не говорю про сам диплом, я же его даже не видел. Просто в "Приключениях Тома Соера" есть 21-я глава про красноречие, там гвоздь программы во время экзаменов чтение старшеклассницами своих сочинений. Прочитать главу надо, понятнее будет.
alexey-lustin
20.08.2018 19:24Мои опасения также подтверждаются — я так понимаю по ссылкам вы не перешли, а в статье они напрямую отсутствуют.
я отрефлексировал на слова «пахнет» и «просто учебная работа» — на мой взгляд это несколько неверные слова, если мы говорим о стандартах.
С другой стороны в чем вы точно правы — когда дипломная работа готовилась, то внезапно выяснилось, что если зона 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.
kbtsiberkin
19.08.2018 14:11-2Мысль о покупке готовой работы не рассматривалась. Хотелось реально что-то сделать самому.
Вариантов тем дипломных проектов рассматривалось много… Короче много всего что было в голове, но ничего из этого не вдохновляло.
Сдаётся мне, эти две фразы исчерпывающе описывают состояние обучения как минимум на данной специальности в как минимум данном вузе. Отсутствие мотивации как у студентов, так и у преподавателей?apapacy
19.08.2018 14:36+1Как минимум указывает что студентов учат думать, а преподавателей поддерживать инициативу студентов.
nlruslan Автор
19.08.2018 15:36+4На выбор было достаточно много тем, любую из них можно было выбрать и развить. Но лично мне было не интересно писать 100500 работу как я внедрил документооборот.
GnuriaN
19.08.2018 15:11+8Господа, вот вы тут требуете от студента знание методологии DevOps, ITIL, а ничего, что человек на 4 курсе института? Вспомните себя? Или вы уже на третьем все поголовно были Standart, а то уже и Senior! Если, видите, что человек "смотрит" не туда, так покажите ему, куда смотреть и вам зачтется в карму.
Хотя, это наверное все из за того, что "1С" ее почему, то очень многие сильно не любят и любого, кто ей занимается готовы уничтожить.
nlruslan спасибо за статью. Скинул ее знакомым 1С'никам, они довольны.
zirf
19.08.2018 19:01Поправлю малость, я не говорил о знании методологий типа DevOps или прочтения всех книжек в ITIL. Я просто заметил, что на данном уровне надо знать, что это такое. Сразу после ВУЗа сертификацию EXIN DevOps Master не одолеть и не потому, что это квалификация менеджера, банально нужен опыт. ITIL Foundation, можно, но лучше не забивать голову. Именно эту сертификацию в RealITSM IT-sceptic, Роб Ингланд то бишь, называет "толкователь".
Для диплома вполне прилично.
Автору
"Экономический эффект возможен только в долгосрочной перспективе. По опыту замечено, что при запуске проекта имплементации инженерных практик фиксируется снижение производительности разработки на 20-30% от текущего уровня."
Честно, но лучше такие выводы ставить в конец. И вместо процентов употреблять слова "несколько", "незначительно" и.т.д в общем понятно.
Дело в том, что применение DevOps практик должно обеспечить как раз противоположный эффект и лучше вчера. Но опять же диплом "по исследованиям", тут это не важно. Следование академическим канонам важнее.
Но "Физики шутят" почитайте
nlruslan Автор
19.08.2018 19:34-1Честно, но лучше такие выводы ставить в конец. И вместо процентов употреблять слова «несколько», «незначительно» и.т.д в общем понятно.
Спасибо, учту.
Дело в том, что применение DevOps практик должно обеспечить как раз противоположный эффект
В 1С с этим сложнее. Как я уже говорил, сложность заключается в том, что сами программисты 1С слишком сложно воспринимает технологии из других областей. Например, программист пишущий на C++ привычный к чтению англоязычной документации, а вот у 1С-ников это зачастую вызывает ступор. Но опять же, это мое наблюдение. И я буду рад, если это окажется не так.zirf
20.08.2018 07:07+11C ники просто крайний случай (один из), не они как люди, а как специалисты по платформе из ж во многих отношения. "Сопротивление изменениям" существует всегда, это уже из области психологии. Задача при применении "хороших практик" преодолеть его используя кнут и пряник. На практике это тяжелая задача, так как нужно сначала уговорить ЛПР, дабы иметь одобрение руководства и административный ресурс, а потом уже браться за реализацию технического проекта. Ошибки не простительны. Это на будущее.
erthad
20.08.2018 13:31Дело в том, что применение DevOps практик должно обеспечить как раз противоположный эффект и лучше вчера.
Это если у программистов уже имеется необходимый скиллсет — например, навык писать тестируемый код. Иначе пока они научатся и будет та самая просадка 20-30% производительности.
BalinTomsk
20.08.2018 08:17---а ничего, что человек на 4 курсе института? Вспомните себя?
В томском политехе на втором курсе занимался расчетами ядерного взрыва под Токио.
На третьем — индувидиальное обучение и уже фактически только работа на кафедре — госразработка робота для Чернобыля в должности ведущего разработчика.
Но автор молодец — статья и работа грамотно написана.
kalapanga
19.08.2018 15:17+3Извиняюсь за оффтопик, но
Мысль о покупке готовой работы не рассматривалась.
Неужели для современных вузов самостоятельное написание диплома такое неординарное событие, что это стоит отдельно подчёркивать?
ProSerg
19.08.2018 15:18+2Странно что GitLab до сих пор рассматривается только как сервер исходных кодов. Хотя у него довольно мощная CI/CD часть. Тоже есть runner, отлично работает как под Windows, так и под Linux.
nlruslan Автор
19.08.2018 15:24Ну тут возражений нет. Просто как то привычнее Jenkins с его безумным количеством плагинов на каждый случай жизни.
rakhinskiy
20.08.2018 14:10У GitLab есть один маленький недостаток, он в бесплатной версии не может быть использован только как CI/CD для сборки внешних репозиториев. Repository mirroring есть только в EE редакции. А в Jenkins можно сделать сборку того же nginx из официального репозитория опираясь на их теги.
SalidanM
19.08.2018 15:18-5Минус поставил бы, просто потому — что это будут читать бизнеса.И это чтиво им противопоказано.Принятие де-юре научным сообществом? Слишком громкие слова, потому что по части "выводов" знающие поставили бы двойку. По поводу свежести — да свежо.Но для написания кейса реализации просто на хабре, а не вырезками из диплома, объявлением признания научным сообществом де-юре.И включением это в пособие для всех остальных. Даешь шутки "1С ники настолько крутые, что пособия для них пишут студенты их Томского".Без обид, но просто статья — да, полезно.Вытаскивать это как диплом — не стоило
nlruslan Автор
19.08.2018 15:21+5Ок. Вы знающий. А по сути? Что именно в выводах Вас смутило? Почему описание бизнес-процесса не может быть темой дипломной работы, и почему 5 членов комиссии с интересом слушали и задавали вопросы?
apapacy
19.08.2018 17:06-1Документооборот это кстати очень интересная тема. Просто ит-сппциалисты не всегда ее представляют во всем объеме, в связи с реальными процессами. При этом не только студенты или разработчики с галер но и те кто работает внутри предприятия и как им кажется знают суть этого вопроса. В этом смысле правильно что Вы ее не взяли.
apapacy
19.08.2018 16:56+2Какие бизнеса читают это ресурс? Почему противопоказано? Что знают знающие про девопс в 1с? При чем тут Томск?
AntonSazonov
19.08.2018 21:15Поставил бы минус просто потому, что вы после точки пробел не ставите.
EvilBeaver
20.08.2018 10:49На Хабре принято такие вещи писать автору в личку, а не молча минусить.
AntonSazonov
21.08.2018 12:11А с чего вы взяли что я кого-то минусил? У меня даже кармы на это нет.
Этим сообщением я просто выразил своё несогласие и аргументировал это подобным образом.
Да и вообще-то, моё сообщение предназначалось не автору статьи, если вы вдруг так подумали.
RomanArzumanyan
20.08.2018 10:53+1Если без лирики, то это квалификационная работа по специальности «бизнес-информатика». Бизнес есть, информатика есть. Кому-то эта работа нужна и приносит материальную выгоду. Перечисленные факты вкупе показывают, что автор подтвердил квалификацию бакалавра.
PastorGL
19.08.2018 22:02+2Термин DevOps звучит красиво, но в данном случае немножко некорректно его применять.
В статье покрыта только та половина ЖЦ, которая относится к «dev». Этим, кстати, в очень большой конторе может заниматься отдельный человек в должности билд-инженера, — когда действительно много проектов, которые все нужно правильно собирать, тестировать, и запаковывать, — на билд-ферме из десятков машин. Но обычно за эту часть процесса (до того, как собранные артефакты попадают в репозиторий) отвечают сами разработчики.
А вот «ops» после публикации артефакта только начинается. Во-первых, среда для тестового/staging деплоя должна автоматизированно разворачиваться в каком-нибудь приватном облаке. В следующих правилам конторах, если operations engineer в своём уме, он никогда не опубликует релизный артефакт сразу в продакшен, даже если все тесты на CI были зелёные. Его нужно прогнать через staging с полной репликой боевого окружения — чтобы убедиться, что он не упадёт копии настоящей базы и приближенной к боевой инфраструктуре. Также, артефакт должен быть автоматически сконфигурирован под тестовое окружение — чтобы не пытаться лазить в боевые инстансы внешних сервисов во время тестирования.
Во-вторых, после успешной проверки staging (тоже автоматизированной — со своим набором интеграционных и нагрузочных тестов) деплой идёт на бэкап продакшена. И только если и этот этап пройден успешно, можно выкатывать релиз в прод. Даже если он сломается при выкате — уже есть функционирующий, держащий нагрузку, бэкап на новой версии, на который можно переключиться (снова автоматически) на время расследования инцидента.
Естественно, инфраструктура и бэкапа, и прода в хороших руках управляется из-под системы оркестрирования ресурсов, предполагающей обязательный сбор телеметрии, которая агрегируется в свой собственный набор отчётов — примерно такой же значимости, что и отчёты по тестам. По которым можно ставить задачи по оптимизации перфоманса и ликвидации узких мест… в идеале — аналогично, автоматизированно, прямо в трекер.
Так что operations тема отдельная, и во многом интереснее, чем сборка с автотестами.
Впрочем, даже внедрение первой половины методологии в применении к 1С — это уже неплохо (культуру-то надо повышать). Можно только пожелать автору дойти до конца, и показать когда-нибудь полное внедрение со всеми полагающимися шагами.nlruslan Автор
19.08.2018 22:17-1Спасибо за замечание. Записал себе в заметки и обязательно подумаю над этим.
alexey-lustin
20.08.2018 08:15половина ЖЦ, которая относится к «dev»
nlruslan — хм, а ведь коллега прав. В статье отсутствует процесс «deploy» который был и есть и делается с помощью deployka github.com/oscript-library/deployka
Видимо надо будет сделать отдельную публикацию по vagrant, docker. ansimble для настройки контуров dev-stage-uat-prod и использующихся инструментах для этого.
Можно только пожелать автору дойти до конца, и показать когда-нибудь полное внедрение со всеми полагающимися шагами.
PastorGL — если можете поверить мне на слово, то автор уже 3 раза прошел полное внедрение со всеми полагающимися шагами. Кроме docker-compose ;-)nlruslan Автор
20.08.2018 08:58PastorGL Обдумал Ваши слова. Как и сказал alexey-lustin, в статью мало попало данных по «ops», хотя в дипломе они были. Сейчас уже начинаю понимать, что возможно не достаточно и тему желательно развить. Думаю в 2-х направлениях:
1. настройка контуров dev-stage-uat-prod
2. Логирование и анализ данных.
ZEEGIN
19.08.2018 22:46+2Как по тексту так и по комментариям, замечание всем:
Методология — это наука о методиках.
говорите правильно: Методика
IharLimitless
19.08.2018 23:41+2Учусь в ТУСУРе заочно на последнем курсе. Диплом собираюсь писать сам :) Может кто и покупает, флаг им в руки. А парень молодец, сделал сам свою тему. Да, это не вечный двигатель, но он молодец, можно только похвалить.
ZEEGIN
20.08.2018 00:32+2nlruslan alexey-lustin
На конкурс пойдет?
http://konkurs.1c.ru/diplom/alexey-lustin
20.08.2018 08:04Зарубят я думаю. Позиция материнской компании пока лежит в плоскости КИП (корпоративного инструментального пакета). В дипломной работе для построение конвейера сборки использовались фактически только открытые (открытые по лицензиям) инструменты: 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=23700nlruslan Автор
20.08.2018 08:35Если не пытаться, то точно ничего не получится.
alexey-lustin
20.08.2018 08:39Ну давай поиграем в эту игру ;-). Давай подадим. НО чур не расстраиваться, «если чё».
EvilBeaver
20.08.2018 10:51СППР умеет хранить исходники??
alexey-lustin
20.08.2018 10:53Метаданных как минимум ;-). Чтобы модель строить. Ох про АПК то я забыл сказать — вот он точно умеет их хранить.
ZEEGIN
20.08.2018 11:45Все можно заменить :)
СППР — Jira — Redmine — GitLab Issue
GitConverter можно вообще не использовать если разрабатываешь в формате EDT
Сценарное тестирование — Ванесса — xUnit
Тест-центр — Zabbix
Центр администрирования — Gitlab CI — Jenkins — Ansible — Kubernetes (все завсит от того любишь ты больше оркестрацию или развертку)
SonatQube — АПК
Так же в списке нет — отдельно юнит-тесты пишут с расширениями в роли моков.
А еще есть механики, которые проверить можно только SikuliX, например нажатие на кнопочку загрузки файла в веб-клиенте.
Плюс под все окружение нужны обертки снимающие журнал регистрации, технологический журнал и дампы в случае падения или зависания.
alexey-lustin
20.08.2018 12:13Дык мы то знаем, но я к тому что могут зарубить с формулировкой «У нас применяются другие инструменты.
MadridianFox
20.08.2018 07:16Очень похожая история. Я учился по направлению «Системы корпоративного управления», параллельно работал в вузе в отделе поддержки и разработки внутренних информационных систем. Работали с 1С…
шучу, не с ним, а с 1С Битрикс.
Т.к. в штате были одни студенты пришлось добавлять в процесс разработки процедуры контроля качества кода, начиная от банального написания подробной инструкции как у нас принято писать код и заканчивая развёртыванием собственного CI сервера. не долго думая я взял все свои наработки и оформил в качестве диплома.
reallord
20.08.2018 08:44Отлично! Только за труд по систематизации инструментов по 1С 8.х надо диплом дать!
Большую часть того что тут написано, многие «синьеры» от 1С не понимают не хотят знать.
А уж статическое или функциональное тестирование код 1С, это вообще для большинства программистов просто фантастика.
Сейчас это только в больших коллективах, где хоть кто-то из руководства понимает необходимость этого.
pfihr
20.08.2018 09:11-1Devops в 1с не оправдан, эффективность затраты/результат низкая. Платформа такие практики не поддерживает, пока не перейдет на модель работы с текстовыми файлами, как у других языков. Пытаться прикрутить их через сторонние решения лишь удлинняет время разработки и удорожает стоимость (г...)кода студентов-"программистов" 1с.
nlruslan Автор
20.08.2018 09:23Позвольте не согласиться с вами:
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
EvilBeaver
20.08.2018 10:55Вот уж нет. Мои 4 года в стиле автоматизации dev и ops для 1С говорят ровно об обратном. После получения кнопки «развернуть в продуктив» на веб-морде сервера интеграции, отдел эксплуатации (то бишь, ops) уже ни в какую не хотят жить без нее. А после получения приемочно-дымовых тестов, позволяющих тыкнуть мордой разработчиков (dev), приславших кривой релиз — они вообще стали счастливы.
Далее следует переход на парадигму «dev+ops живут в одной лодке», но у нас в конторе до этого пока не доросли ментально обе стороны. Тем не менее, польза налицо.
SUA
20.08.2018 11:02Devops в 1с не оправдан, эффективность затраты/результат низкая.
Весьма сомнительное утверждение — конечно, одно дело когда надо «а потомучто главбух хочет» немного какой-то отчет поправить в конторе на 1.5 человека, там не нужны ни DevOps, ни (периодически) даже программист (ключевое преимущество 1С для российского рынка — при необходимости, видел сам примеры, бухгалтера сами могли что-то «дорисовать» потому что по-русски и часто понятно), с другой — заваленный релиз даже среднего размера конторе (500+ человек) с самописным решением грозит минимум дневным простоем, что сразу окупает даже двукратный рост сроков разработки
exit999
20.08.2018 11:38А можно ссылку на библиотеку для расчета цикломатичности кода для onescript? Что-то нигде найти не могу. Или она сейчас входит в состав Vanessa-ADD?
alexey-lustin
20.08.2018 12:17Суть в том что формально это перенос кода из infostart.ru/public/166182
Обработка предназначена для автоматизированного расчета цикломатической сложности кода
Цитата из кода
* Вы можете использовать обработку по своему усмотрению в рамках действующего законодательства.
* Единственная просьба: если у вас есть замечания или предложения по улучшению обработки, а также в случае нахождения багов — пишите мне об этом на infostart.ru/profile/101097
Выложил на gist gist.github.com/allustin/2cec4a7c19b74b2d592c978e34bf2f1c
Мне до конца неясно можно ли публично распространять, потому как автор с 2015 года не появлялся на ИнфостартеOksikOneC
21.08.2018 23:07А можете что-нибудь порекомендовать по такой теме анализа дерева вызова процедур или функций? Есть некоторые публикации на эту тему, но они не очень свежие:
Трассировка кода: infostart.ru/public/164960
Граф вызовов для модулей 1С + GML на ОФ: infostart.ru/public/190199
Аналог предыдущего на УФ: github.com/SergeFocus/1C-Functin-to-yEd
Хотелось бы узнать, вы чем-то подобным пользуетесь, и как вообще сейчас можно быстро построить такое дерево? Какие-то может еще инструменты для этого есть?
morv
20.08.2018 12:47Выводы интересные в статье про экономический эффект, повышение стабильности и снижение трудозатрат.
Здесь хочу вспомнить цитату компьютерного учёного Дэвида Уилера: «Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности».
Наверное, DevOps — это новый уровень косвенности, который при росте сложности информационной системы становится просто необходим, чтобы сохранять контроль над ней.
И нужно понимать, что сама сложность с внедрением DevOps никуда не девается, а ещё даже и приумножается. Т.е. вам всё равно нужны будут дополнительные ресурсы, чтобы помимо разработки непосредственно программы, выделять их ещё и средствам автоматизации разработки.
Грубо говоря, раньше вы чинили программу. Сейчас вам нужно чинить ещё и DevOps, когда он ломается.
Что DevOps действительно даёт вам, так это резерв времени: вы узнаёте о том, что что-то сломалось раньше и успеваете починить программу до того, как дефект доходит до конечного пользователя.EvilBeaver
20.08.2018 21:00Нуу, как-то так, да. Компьютеры помогают решить проблемы, которые не существовали до их изобретения :)
Berkof
21.08.2018 14:56Хороший диплом, показывающий, что человек не поленился и скомпоновал актуальные инструменты в полезную систему, решающую его прикладные задачи. Насчёт научной ценности — очень сомневаюсь, а вот как повод принять автора на работу — отлично.
SDKiller
Имхо, зря минусуют статью. Попытка применения интрументов анализа кода и практик devops в 1с — это как минимум свежо.
nlruslan Автор
Спасибо. Мое мнение, что использование devops сможет все таки приподнять уровень качества программного кода на прикладных решениях. К тому же сама концепция уже хорошо известна, и успешно работает в других IT областях, а вот в 1С это жутко не хватает. И как капитан-очевидность, скажу что низкое качество кода — это первая причина тормозов в 1С. С этим нужно бороться. И не жутким наращиванием железа, а для начала повышением собственной компетенции.
abbaboka
Если это студенческая работа, то автор очень далеко пойдет как профессионал.
tenhi_shadow
свежо, но есть хабровская и общая аллергия на 2 буквы «1с».
Хотя devops это методология, которая применима почти где угодно.
Wernisag
Аллергия скорее на словосочетание «Программист 1С», которые строят из себя абсолютно не заменимых людей, не желающие как либо развиваться и считающие, что одного языка 1С достаточно для всех решения всех проблем в бизнесе
EvilBeaver
Таких в любых языках/коллективах хватает, не стоит обобщать.