INFOSTART EVENT 2018 EDUCATION

Второй тур голосования за доклады.
Окончание 5 сентября.

Соседова Снежана Дмитриевна | Разработчик мобильных приложений | 1С-Рарус

«Как улучшить продукт и увеличить выручку в несколько раз (Немного про UX/UI, воронку AARRR и реальном опыте применения статистики в мобильном приложении)»

Поговорим о тиражных приложениях, и не только мобильных, и не обязательно на 1С :) В своем докладе я поделюсь нашим опытом разработки мобильного приложения Boss - как мы принимали решения о развитии приложения, на какие грабли наступали и какие выводы сделали: - "Ошибка выжившего" или почему фидбек от пользователей - это не всегда хорошо. - Сделаем продукт лучше! Добавим новые фичи! Или нет?) - Куда уходят пользователи? И так ли важно количество скачиваний приложения? - Статистика - что собираем, и главное Зачем? - Несколько реальных кейсов из нашего опыта - как мы увеличили выручку, не меняя функциональность приложения.

0. user768334 151 28.02.18 08:50 Сейчас в теме

Мониторинг изменений рабочих конфигураций. Часть 1. Сохранение конфигураций из базы SQL без конфигуратора

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

Перейти к публикации

Комментарии
Сортировка: Древо
1. Evil Beaver 5186 28.02.18 11:12 Сейчас в теме
А чо, весело и задорно! Хотя, заявленные задачи я бы решал другими средствами, но пусть расцветает сто цветов!
Silenser; GreenDragon; +2 Ответить
2. kraynev-navi 365 28.02.18 11:59 Сейчас в теме
(1) А можно в подробностях?
3. Evil Beaver 5186 28.02.18 12:17 Сейчас в теме
(2) Начнем с того, что не все организационные проблемы надо решать техническими средствами. Организационные меры тоже работают. Одна из лучших мер - отобрать у разработчиков админский доступ к боевой системе. Доступ как в ядерное хранилище - под роспись со сканированием сетчатки и анализом мочи от участкового врача.

Больше подробностей по пунктам задач:

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


Боевая база в режиме "поддержки" с замочками, как типовая. Изменения в ней исключены. Обновление боевой системы выполняет сервер CI с помощью утилиты deployka, а не человек. А если уж человек заходил и изменения в конфигурацию внесены, то есть "конфигурация поставщика", с которой можно сравнить и понять - что изменено. А если сняли с поддержки совсем, так что и "конфигурация поставщика" исчезла - то смотрим журнал доступа и устраиваем показательную казнь.

Оперативный визуальный контроль внесенных изменений без запуска конфигуратора.

Не понял тезис и задачу. Как выглядит "Оперативных контроль изменений" и что именно решает?

Не часто встречающийся случай. Конфигуратор банально занят другим разработчиком, а CF-ник «дозарезу» нужен. (Сказать разработчику «Ей, Вася, а выгрузи-ка мне CF-ник» вы не можете по нескольким причинам: другой сотрудник не сидит рядом, или отошел на часок, или, возможно, он работает в другом часовом поясе, или вы даже не знаете кто он, а может быть он даже совсем из другой организации-подрядчика и вам сложно найти его контакты через менеджеров.)


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

Теперь по контр-тезисам:

Ваши разработчики ведут разработку в хранилище.


Да, и более того - это совсем не больно. Нет ни одной причины совсем не использовать хранилище в разработке на 1С (если вы не Евгений Сосна, но он использует GIT вместо хранилища, а это не совсем одно и то же, что и вообще без версионирования)

Хотфиксы появляются в рабочей базе только из хранилища.
Да, иначе бардак, Адъ и Израиль. Но бывают авральные хотфиксы, которые потом спокойно и не спеша вносятся в хранилище. Для этого и нужен "режим поддержки" для контроля отличий (см. выше)

Хотфиксы всегда проходят тесты (ах, да, тесты!)
Хотфиксы не проходят тесты, ибо это ХОТ-фиксы, когда пожар и у всех подгорает. Не до тестов.

Никто никогда не вносит изменения в рабочую базу динамически.

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

Если рабочая база подключена к хранилищу ее никогда не отключали по ошибке

База не подключена, она стоит на поддержке и за счет этого "неизменна". Включение режима изменений только для авралов. Полное снятие с поддержки - показательная казнь.

Никто никогда не спутал рабочий конфигуратор и не накатил туда что-то не то.

Доступ в боевой конфигуратор человеку (а не серверу CI) только после справки от врача (и желательно с другой машины). Тут сложно перепутать.

При сравнении/объединении с новым релизом не бывает ошибки, связанной с неверным выбором файла релиза. Или альтернативное утверждение: новые релизы всегда устанавливаются из файлов поставки.

Сервер CI не ошибается с выбором файла релиза.

Администраторы базы данных никогда не ошибались с восстановлением БД из других баз данных или бекапов.

И как здесь поможет инструмент, предлагаемый в статье?

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

Нет, мы, напротив, злостные параноики, поэтому пароли от боевых баз у разработчиков отсутствуют.
artbear; user740371; support; amon_ra; Ko1t; vvst; Dementor; VladimirL; IgorS; freddy121; kuntashov; antonj; GreenDragon; jif; kraynev-navi; 1cWin; Bronislav; Berckk; user774630; kalyaka; NeviD; Alexander87; JohnyDeath; +23 Ответить
16. chuprin 02.03.18 02:26 Сейчас в теме
(3) Очень хороший, годный комментарий. И прямо просит столь же развернутого ответа.
Сразу скажу, что Андрей Овсянкин (Evil Beaver) прав. Нет, ПРАВ!!! На 150%.
И примерно так выглядит наша цель. Цель, к которой мы идем не первый год. Можно прямо брать пост и рисовать RoadMap.

Целью является «Волшебный Мир»с единорогами и розовыми пони. Теми самыми, которые питаются леденцами и какают бабочками. Кто-то уже сумел построить такой мир, кто-то нашел его и переселился. И это здорово, это дарит надежду. Что и остальные из «Злого Леса» могут со временем выбраться в дивный новый мир.
Действительно здорово. Смотришь, например, Infostart Event, и понимаешь, что сообщество растет. То, что когда-то воспринималось как ересь отчаянных гиков, идущих против системы, становится понемногу если не стандартом, то Best Practics.
Есть и плохая новость (на самом деле – не новость). Не везде так здорово. Не всем повезло жить в мире Полудня или НИИ ЧАВО Стругацких. Многие живут в грустном антиутопичном мире, который хорошо описан, например, в цикле статей Ивана Белокаменцева.
https://infostart.ru/profile/73629/
Да и в Gitter есть немало постов про то, что не все гладко.
https://gitter.im/EvilBeaver/oscript-library
И ведь знаешь, как правильно надо делать… Вот и идем мы отсюда – туда, в волшебный мир.
Анекдот про социализм.
http://anekdotov.me/sovetskie/51683-odnoj-nogoj-my-stoim-v-socializme-a-drugoj-uzhe.html
За рамками статьи – много боли. Озера и моря.
Каждый тезис можно развернуть если не в книгу, то в большую статью с примерами из жизни, кульминацией и развязкой.
Собственно, описанный в статье кейс, является решением вполне конкретной жизненной задачи. Кейс этот получил весьма интересное и перспективное развитие. Об этом будет следующая статья.
По поводу «Организационный момент», «показательная казнь», «Сервер CI не ошибается»
У нас холдинговая структура. И, мягко говоря, не всегда можно насадить свое мнение.
Т.е. есть очень уважаемый в организации программист. И незаменимый. То, что незаменимость эта следствие некомпетентности или специально выстроенная ситуация – оставляем за кадром. Так есть. Это реальность, данная нам в ощущениях.
Главное – он полезный. И текущие потребности организации закрывает. И все довольны. А хранилище и регламенты ему не интересны. И даже будут мешать. А вокруг степь на сотни километров и другого все равно не найдем.
И тут какие-то пи… Нет, безусловно, очень умные и грамотные люди из Москвы. К сожалению, оторванные от реальности и не знающие местной специфики, начинают рассказывать, что все не так. Уважаемый человек, на самом деле - вредитель. А то, что раньше делалось за день, будет делаться неделю.
Более того, над людьми (внутренними заказчиками) будет совершаться самое страшное насилие. Их будут заставлять думать. Думать, что же они хотят. Зачем им это надо. Как они будут проверять, что все работает, как они хотели. И, внезапно, появится контроль того, как они используют то что им сделали из того, что они хотели. И апофигеем – анализ достижения целей, которые декларировались, как приоритетные, при аргументации необходимости разработки.
И вот этому «уважаемому человеку» мы собираемся устроить «показательную казнь».
Очень серьезный политический шаг. И за «базар» придется отвечать.
А программист говорит - «мамой клянусь, ничего такого не делал, это все они».
И разговор это очень быстрый. Потом можно долго бегать как в фильме «О чем говорят мужчины» https://www.youtube.com/watch?v=2wcIEybNscs&feature=youtu.be&t=1394
Нужна доказательная база. Вот эту доказательную базу мы и получаем. Да, были изменения в рабочей конфигурации. А в хранилище не было. И задачи на хотфикс не было. Ну как так-то? Ай-яй-яй. Это предметный разговор.
Но, в общем случае, приводить удаленное подразделение к «общему знаменателю» стратегически правильно, но не всегда своевременно и экономически оправданно.
Да и нам это тоже не очень надо. У нас есть маленький кусочек конфигурации, отвечающий за интеграцию. И мы хотим, чтобы он был реализован, работал и не изменялся без нашего ведома.
А вопрос с сопровождением отдельно взятой маленькой недружественной организацией может решиться и естественным путем (например, ее продадут или сократят). Ну да, мы не за идею работаем, тупо за деньги.
Кстати, в волшебном мире такой контроль тоже полезен. На всякий случай. Только в штатной ситуации такое изменение рабочей ИБ должно быть привязано к задаче на деплоймент (в том числе, к автоматической задаче). И это не так сложно промониторить. Определение повода для «показательной казни» тоже можно автоматизировать.
Мне очень нравится идея включить подобный функционал в репозиторий OneScript,но PowerShell тоже имеет аргументы на параллельное существование. Его можно через PsExec запустить удаленно в недружественной среде.
Если нельзя сделать все сразу хорошо – ведь это не значит, что не нужно делать вообще ничего.
Не ожидал, что это скажу, но надо использовать то, что работает.
И вообще, это только кусочек мозаики, паззла. Где есть и безопасность, и мониторинг, и бэкапы, и управление требованиями, и управление задачами, и регламенты, и обучение, и методология, и Framework, и инфраструктура, и организационные изменения, и многое другое.
Еще раз повторю. В комментарии коллеги – все правильно. Просто многих пугает, как жить в переходный период. А здесь работает простое правило бойскаута.
https://plus.google.com/+SergeyTeplyakov/posts/ZaxnrarBvKS
Если каждый день делать немного лучше – в результате неизбежно станет хорошо. Главное, не останавливаться.
support; mr.lynx; Berckk; farukshin; kraynev-navi; tsukanov; Evil Beaver; +7 Ответить
19. Evil Beaver 5186 02.03.18 10:03 Сейчас в теме
(16) Спасибо за камент. Если что - никого не хотел обидеть. Я написал, что статья хорошая, просто я бы решал по-другому, но я не истина в последней инстанции, напротив, мы тут все делимся опытом и каждый делает для себя выжимки из чужого опыта, приправляя своим. Главное потом - не забыть поделиться результатом, чтобы в сообществе было больше разных знаний и опытов. "Пусть расцветает сто цветов" из моего первого комментария - это как раз об этом.

Спасибо за развернутый ответ.
20. tsukanov 64 02.03.18 11:31 Сейчас в теме
(16) Вот не первый раз вижу как за повершел оправдываются.
Не надо. Все вы правильно делаете
17. chuprin 02.03.18 02:34 Сейчас в теме
(3)
Не понял тезис и задачу. Как выглядит "Оперативных контроль изменений" и что именно решает?

Тимлид просматривает Gitlab без использования конфигуратора. Обычно, это быстрее и удобнее.
18. chuprin 02.03.18 02:44 Сейчас в теме
(3)
Не часто встречающийся случай. Конфигуратор банально занят другим разработчиком, а CF-ник «дозарезу» нужен. (Сказать разработчику «Ей, Вася, а выгрузи-ка мне CF-ник» вы не можете по нескольким причинам: другой сотрудник не сидит рядом, или отошел на часок, или, возможно, он работает в другом часовом поясе, или вы даже не знаете кто он, а может быть он даже совсем из другой организации-подрядчика и вам сложно найти его контакты через менеджеров.)

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

Один из печальных кейсов. Запустили обновление ИБ, а там - реструктуризация. Надо было срочно обновляться. Ну как обычно бывает. На тестовый прогон времени не было. А реструктуризация затянулась на несколько часов. Вот тут-то и понадобился CF, чтобы понять, что же там происходит. Прерывать и откатывать на бэкап (да-да, бэкапы перед обновлением делать надо всегда, желательно автоматизированно. Даже внешне самый безобидный деплой может стать фатальным. Ваш КО) или дожидаться реструктуризации.
Тогда обошлись ночной копией. Сейчас бы взяли версию из git/
Evil Beaver; +1 Ответить
21. amon_ra 2 13.04.18 12:53 Сейчас в теме
(3)
Доступ в боевой конфигуратор человеку (а не серверу CI) только после справки от врача (и желательно с другой машины). Тут сложно перепутать.

божечки, какие прекрасные слова! Андрей, можно я тебя буду всем цитировать и сбрасывать на твой комментарий ссылки?)
22. Evil Beaver 5186 13.04.18 16:34 Сейчас в теме
(21) Можешь даже слать мне деньги и ключи от квартир :)
23. amon_ra 2 17.04.18 16:32 Сейчас в теме
(22)с этим сложнее будет)

З.ы. вот я слоупок, только увидел сообщение)
4. zqzq 17 28.02.18 15:00 Сейчас в теме
Вообще, половину проблем решает подключение рабочей базу к хранилищу с минимальными правами (без возможности захвата объектов, только получение из хранилища). Тогда и шаманить в рабочей базе станет физически невозможно, и не спутаешь с тестовой, и сидеть в её конфигураторе тоже никто не будет.

Также автоматизированное обновление рабочей базы из хранилища (нединамическое обязательно) часть других проблем решает.
6. farukshin 75 28.02.18 16:03 Сейчас в теме
(4)
половину проблем решает подключение рабочей базу к хранилищу с минимальными правами (без возможности захвата объектов, только получение из хранилища). Тогда и шаманить в рабочей базе станет физически невозможно


К сожалению, не решает. А что помешает в конфигураторе рабочей базы отключить ее от хранилища?
10. zqzq 17 01.03.18 08:52 Сейчас в теме
(6) Я же написал, половину. Неадекватных и злонамеренных сотрудников не рассматриваю, это не техническая проблема, а административная. Если всё так плохо, нужно не пускать в рабочий конфигуратор, как выше писали.
15. GreenDragon 01.03.18 16:17 Сейчас в теме
(10) Вы наверное очень отчаянный человек, если подключаете продакшн базы к хранилищу. Я полтора года назад тоже такую ересь сотворил. В итоге когда упало хранилище, намертво и качественно, мы оказались в ситуации, когда база вроде бы работает, но в конфигуратор продакшн-базы путь заказан - не доходило даже до запроса идентификационных данных хранилища. В итоге был крайне весёлый вечер. По итогу пошли по рекомендуемому многими пути формирования поставки из хранилища. В общем - свят, свят...
5. baton_pk 371 28.02.18 15:56 Сейчас в теме
будем использовать OneScript (начиная с версии 1.0.16), PowerShell (версии по умолчанию достаточно)


прямо больно до слёз! Чего не хватило в односкрипте, чтобы выкинуть из этого списка PowerShell ???

PS. Это не упрёк, а вопрос - мы же допилим, если что :)
starik-2005; JohnyDeath; kraynev-navi; Evil Beaver; STivO; +5 Ответить
7. Evil Beaver 5186 28.02.18 17:03 Сейчас в теме
(5) И во вложениях - доработанный gitsync. А что именно доработано? Может это включить в основной gitsync?
8. baton_pk 371 28.02.18 17:26 Сейчас в теме
(7)
переделав команду export, убрав из нее работу с хранилищем.

Видимо, это. То есть, гитсинк тут и не нужен, нужен мелкий скрипт с v8runner и gitrunner.
artbear; МихаилМ; +2 Ответить
13. chuprin 01.03.18 12:25 Сейчас в теме
(5)
Чего не хватило в односкрипте, чтобы выкинуть из этого списка PowerShell ???

Все просто. Задача стояла - получить из SQL cf, валидный для разбора в git. Первым по запросу "BLOB поле в файл" попался PS-скрипт. Конечно, можно то же самое реализовать в односкрипте. А если функционал будет добавлен в гитсинк, то мы первые начнем пользоваться.
9. awk 689 28.02.18 23:21 Сейчас в теме
Разворчались... У меня тестовый контур, и кф файл нужен из бызы разработчика, для базы тестирования... А согнать разработчика с отладки, что бы тестировщик что-то обновил... Так что плюс однозначный...
12. МихаилМ 01.03.18 09:27 Сейчас в теме
(9)
для этого данный инструмент необязателен.
достаточно написать скрипт создания пустой базы , копирования из рабочей конфиг в пустую, выгрузку цф.
11. МихаилМ 01.03.18 09:24 Сейчас в теме
(0)
перепишите скрипт так чтобы он сразу раскладывал по папкам с понятными названиями.
14. YPermitin 592 01.03.18 15:23 Сейчас в теме
Однозначно +!
За PowerShell вторую бы звезду поставил :)
awk; tsukanov; +2 Ответить
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Одесса (Украина)
зарплата от 40 000 руб.
Полный день

Программист 1С
Санкт-Петербург
Полный день

Аналитик 1С
Москва
зарплата от 80 000 руб. до 120 000 руб.
Полный день

1С Developer
Одесса (Украина)
зарплата от 60 000 руб. до 120 000 руб.
Полный день

Бизнес-аналитик 1С
Санкт-Петербург
зарплата от 70 000 руб. до 90 000 руб.
Полный день