Комментарии 33
Делаете ли вы разделение времени внутри одного цикла на разработку нового и исправление дефектов или эти процессы идут параллельно?
Внутри цикла у нас специально выделяется некоторое время (примерно 1,5 недели сейчас), на стабилизацию версии. К началу стабилизации все доработки уже должны быть смержены в релизную ветку и протестированы. Далее добавление новых доработок в эту релизную ветку запрещается и там идет только исправление «наведенных» ошибок. За эти 1,5 недели мы делаем регрессивное тестирование, тестирование скриптов миграции данных и развертывания, НТ и тд.
А так вообще разработка доработок у нас идет в ветках параллельно и никогда не останавливается ;-)
А так вообще разработка доработок у нас идет в ветках параллельно и никогда не останавливается ;-)
Егор, было бы интересно услышать пользователей системы. В госпроектах они обычно подневольные даже если в релизе выдали не то что нужно, так как нет альтернатив.
Посмотрите на форуме bankir.ru, узнаете много интересного от пользователей. 75 страниц непрерывной радости от этой замечательной системы.
Игорь, подневольные — это не значит, что бесправные и не имеющие никаких рычагов влияния. Очень даже наоборот. Многие организации — это крупные компании, которые имеют серьезный ресурс и активно участвуют в составлении роадмепа по доработкам.
Вообще, сам по себе термин «выдали то или не то» очень субъективен. Чем определяется «подневольность» вообще? В основном тем, что в нормативке прописаны требования к организациям сферы ЖКХ по размещению той или иной информации в определенные сроки. Поэтому, более объективный критерий — это позволяет ли ГИС ЖКХ выполнить организации предписанные ей требования или нет.
Уверяю, что все такие «блокирующие» доработки или инциденты находятся под постоянным контролем и реализуются максимально оперативно.
Вообще, сам по себе термин «выдали то или не то» очень субъективен. Чем определяется «подневольность» вообще? В основном тем, что в нормативке прописаны требования к организациям сферы ЖКХ по размещению той или иной информации в определенные сроки. Поэтому, более объективный критерий — это позволяет ли ГИС ЖКХ выполнить организации предписанные ей требования или нет.
Уверяю, что все такие «блокирующие» доработки или инциденты находятся под постоянным контролем и реализуются максимально оперативно.
Спасибо за ответ! Менеджмент и разработчики могут рассказать любые красивые истории. Но мне было бы интереснее узнать от пользователей с опытом работы в вашей системе Как сделать ЖКХ, чтобы оно было ГИС повлияли ли на них как-либо частые релизы ГИС ЖКХ…
GnuriaN Loki3000 crea7or deee MaximKovalev teifo servekon kolodinivan anatan pavlyuts ulvham andrnl evgensoft andewil стало ли лучше или «воз и ныне там»?
GnuriaN Loki3000 crea7or deee MaximKovalev teifo servekon kolodinivan anatan pavlyuts ulvham andrnl evgensoft andewil стало ли лучше или «воз и ныне там»?
Снова статья для отпущения грехов. Многие претензии как были так и остались к заказчикам и к исполнителям. Проектированием и проверкой вместе с министерством не занимались, а потом сайт и api сделать не могли вменяемые. За 2 года пром эксплуатации так до конца и до ума ничего не довели. На сайт добавили функционал о котором просили в октябре 2016 года только в этом году. И вообще в декабре 2016 министерства вместе с разрабами обещали версию 12 в которой все будет красиво… до сих пор ждем. Работой с api сейчас другая контора занимается и основные вопросы не к api, а к скорости обмена данными.
>> Снова статья для отпущения грехов.
да нет, просто решили поделиться опытом построения релизного процесса
да нет, просто решили поделиться опытом построения релизного процесса
>> Работой с api сейчас другая контора занимается и основные вопросы не к api, а к скорости обмена данными
вообще в ГИС сейчас ежедневно загружаются очень большие объемы данных.
вот например на днях загрузили 17 млн платежных документов (система могла принять и больше, просто столько нам отправили)
время от времени сталкиваюсь с утверждениями что все плохо, когда разбираемся предметно основные проблемы заключаются в следующем:
— в ГИСе реализовано много бизнес- и форматно-логических контролей для обеспечения целостности; по нашей статистике 9% данных не загружается по этой причине. К заказчику поступали обращения убрать контроли и разрешить грузить все подряд, но это было отвергнуто, тк Заказчик считает, что это приведет к снижению качества данных.
— неправильная реализация взаимодействия с ГИС-ом в части массовой загрузки — надо учитывать что ГИС — это удаленная система, доступ к которой идет через каналы связи идет, работа организована асинхронном режиме через очереди и тд. (возможно, что у нас тут недостаток документации и думаю сделать на хабре пост на эту тему)
— ошибки самого ГИС-а — по нашей статистике доля таких ошибок менее 0,25%. Соглашусь, что нужно вообще сделать 0 — мы работаем над этим.
Если есть желание конкретно разобраться в какой-то проблеме — напишите в личку, посмотрим.
вообще в ГИС сейчас ежедневно загружаются очень большие объемы данных.
вот например на днях загрузили 17 млн платежных документов (система могла принять и больше, просто столько нам отправили)
время от времени сталкиваюсь с утверждениями что все плохо, когда разбираемся предметно основные проблемы заключаются в следующем:
— в ГИСе реализовано много бизнес- и форматно-логических контролей для обеспечения целостности; по нашей статистике 9% данных не загружается по этой причине. К заказчику поступали обращения убрать контроли и разрешить грузить все подряд, но это было отвергнуто, тк Заказчик считает, что это приведет к снижению качества данных.
— неправильная реализация взаимодействия с ГИС-ом в части массовой загрузки — надо учитывать что ГИС — это удаленная система, доступ к которой идет через каналы связи идет, работа организована асинхронном режиме через очереди и тд. (возможно, что у нас тут недостаток документации и думаю сделать на хабре пост на эту тему)
— ошибки самого ГИС-а — по нашей статистике доля таких ошибок менее 0,25%. Соглашусь, что нужно вообще сделать 0 — мы работаем над этим.
Если есть желание конкретно разобраться в какой-то проблеме — напишите в личку, посмотрим.
Егор, может проблемы как раз в сервисе очередей на каком либо древнем веблоджике, проданном вами же? Пока все звучит как голословные убеждения из книжки «100 приемов для борьбы с конструктивным фидбэком».
Как вы собираете метрики производительности, применяется ли трассировка запросов?
Могут ли конечные пользователи получать статистику и трассировку по своим запросам?
Как вы собираете метрики производительности, применяется ли трассировка запросов?
Могут ли конечные пользователи получать статистику и трассировку по своим запросам?
ГИС ЖКХ стало каким-то паноптикумом жуликов. Проверил сведения по нескольким многоквартирным домам: вместо управляющих организаций указаны какие-то прохиндеи… Обращаешься с жалобой в поддержку, предлагаешь разместить информацию о подлинных управляющих организациях — или не отвечают совсем, или посылают лесом… Видимо за небольшую денежку любые жулики могут вписать себя в ГИС ЖКХ в качестве управляющей организации и, затем, беспрепятственно стричь купоны… При этом государство (в лице ГИС ЖКХ) де-юре в доле — помогает жуликам собирать деньги и легализовать денежные средства, полученные преступным путём…
Стало ли лучше? Нет. Основная проблема, что тех.поддержка толком не знает как решать те или иные вопросы. Очень часто при заливке через шаблоны выскакивают ошибки, которые не пойми как исправить. Но с опытом просто уже знаешь как исправить эти ошибки и просто не обращаешься в суппорт.
Насколько я понял, разработчики столкнулись с проблемой вариативности расчетов КУ на местах. В соседних домах одни и те же услуги могут считаться с кардинальными отличиями или список услуг может отличаться. Из-за этого очень сложно разработать универсальные проверки, например для шаблона ПД. Из чего следует, что при проверке шаблонов выскакивают ошибки, которые нужно исправлять на каждой УК индивидуально.
Насколько я понял, разработчики столкнулись с проблемой вариативности расчетов КУ на местах. В соседних домах одни и те же услуги могут считаться с кардинальными отличиями или список услуг может отличаться. Из-за этого очень сложно разработать универсальные проверки, например для шаблона ПД. Из чего следует, что при проверке шаблонов выскакивают ошибки, которые нужно исправлять на каждой УК индивидуально.
воз и ныне там
Как пользователь системы я скажу, что применительно к ГИС ЖКХ практикуется подход, что багу называть фичей и пытаться убедить в том, что так и должно быть.
Дабы не быть голословным, предлагаю оценить количество записей полученных в результате поиска
cloud.mail.ru/public/DKdn/9kGFnz6ct
Дабы не быть голословным, предлагаю оценить количество записей полученных в результате поиска
cloud.mail.ru/public/DKdn/9kGFnz6ct
Я вольный пользователь системы. Неудобно. Пользуюсь только для того, чтобы смотреть электронные квитанции за n-ное время. Каждый раз приходится искать, куда их спрятали. Про адаптив вообще речи не идёт. Ну и вишенка на торте — в данный момент сайт не работает из-за «регламентных работ». Пока на Хабре компании добиваются даунтайма в n минут при переезде на другой сервер, у ГИС ЖКХ свой путь.
Удлось поработать на этом проекте в роли разработчика.
Постановка рабочего процесса была очень комфортная, спасибо.
Постановка рабочего процесса была очень комфортная, спасибо.
Вся страна ждет что отменят эту фигню
я туда каждый день вбиваю кучу данных, вбивается иногда попыток с десяти с разным успехом и лучше не становится. Ладно что не руками а сервак в цикле дрлбится.
я туда каждый день вбиваю кучу данных, вбивается иногда попыток с десяти с разным успехом и лучше не становится. Ладно что не руками а сервак в цикле дрлбится.
интресный факт
вся страна считала деревянный дом на две половины частным домом, а разработчики гиса его признали многоквартирным. и теперь администрация меняет в системе тип дома иначе инфу не передать, но реально его многоквартирным никто не считает
Это не разработчик ГИС так считает, это муниципалитет так выгрузил частный сектор с признаком МКД.
Строго говоря сейчас государство полагает, что в частном секторе может быть три основных вида домов: частные жилые дома (на одну семью), сблокированные дома (несколько семей в доме, но части дома примыкают лишь стенами и являются блоками одного и того же дома), многоквартирные дома (даже если в них две квартиры (жилых помещения), но в доме проживает более одной семьи) где имеются общие помещения (чердак или подвал, например)…
Ох, оставлю свои 5 копеек о ГИС ЖКХ.
Целый месяц пинал поддержку, чтобы там появилась моя собстенность. Ещё 2 месяца пинал поддержку, чтобы с ней хоть что-то можно было делать из заявленного функционала сервиса. Так и не заработало. Там так всё плохо на техническом уровне, что в форме обратной связи есть поле «Браузер», когда это можно узнавать программно. В итоге попросил закрыть все мои обращения, пожелал удачи. Может попробую через года три снова.
Целый месяц пинал поддержку, чтобы там появилась моя собстенность. Ещё 2 месяца пинал поддержку, чтобы с ней хоть что-то можно было делать из заявленного функционала сервиса. Так и не заработало. Там так всё плохо на техническом уровне, что в форме обратной связи есть поле «Браузер», когда это можно узнавать программно. В итоге попросил закрыть все мои обращения, пожелал удачи. Может попробую через года три снова.
Система сомнительной ценности на наши с вами деньги. За последние годы такого барахла выходит всё больше и больше. А потом удивляемся, что денег нет.
У меня три вопроса: один к автору и два ко всем.
К автору: вы пишите
Ко всем:
К автору: вы пишите
«Принципиальный момент состоит в том, что даты релизов впоследствии не меняются. Если версия запланирована на какую-то дату, то мы должны разбиться в лепешку, но выдержать запланированный срок.»как быть, если случается неприятность и запланированная задача не может попасть в плановый релиз? «выпиливаете» её? а как быть, если она ключевая? У нас в практике было, что нам таки приходилось двигать релизы (не сильно, но да) и сидеть по ночам до выпуска — чтобы сделать то, что хотел заказчик (а потом ещё так же сидеть, чтобы довести до приемлемого качества результаты ночных бдений).
Ко всем:
- Уважаемые коллеги, понимаю, что тема острая, но есть ли что-то по сути статьи сказать? Можно вычеркнуть при прочтении «ГИС ЖКХ» и читать как «Большие/маленькие/средние проекты/системы» (кому-что нравится). Вот мне понравился вопрос
«Но мне было бы интереснее узнать от пользователей с опытом работы в вашей системе повлияли ли на них как-либо частые релизы ГИС ЖКХ… »
. Правда, на мой взгляд, основная идея статьи о том, как упорядочить хаос в процессе разработке и сделать процесс предсказуемым. - Примеряя на себя статью, появилась мысль (наверняка, не новая — как и многое в этом мире) — а если релизы ранжировать по сложности изменений: мелочь — раз в неделю, среднее — раз в месяц, а совсем большое — квартал или реже? Кто-то подход такое реализовывал и можно ли кратко поделиться результатами?
>> как быть, если случается неприятность и запланированная задача не может попасть в плановый релиз? «выпиливаете» её? а как быть, если она ключевая? У нас в практике было, что нам таки приходилось двигать релизы (не сильно, но да) и сидеть по ночам до выпуска — чтобы сделать то, что хотел заказчик (а потом ещё так же сидеть, чтобы довести до приемлемого качества результаты ночных бдений).
Это очень хороший вопрос. По сути я про это и пишу в своем посте.
Стратегически я хочу донести мысль, что процесс выпуска релизов и процесс долгосрочного планирования — это должны быть перпендикулярные процессы (в идеале). Есть самолет, которые летает строго по расписанию и забирает фичи, которые готовы к выпуску. Все должны с этим смириться. Да, в этом случае надо смириться с тем, что некоторые VIP-пассажиры могут не попасть на этот рейс (но попадут на следующий). Но в целом такой подход единственно правильный на таких проектах.
Надо понимать мотивацию ради чего мы это делаем — это повышение качества и устранение ночных посиделок и авралов о которых вы пишете. Несколько раз можно поавралить, но бесконечно так делать нельзя.
В нашей ситуации мы не можем себе позволить рисковать качеством версии. Если мы допустим, что к-н фича будет делаться до последнего момента и мы не успеем ее протестировать и тд, то мы рискуем порушить систему. В нашем случае — это неприемлемо.
Поэтому мы всячески стараемся до этого не доводить:
1. Стараемся делать долгосрочный план по фича, чтобы заранее видеть проблемы
2. Делаем фичи в ветках или в танке, но предусматриваем «рубильник» для ее отключения в случае чего
3. В крайнем случае вымерживаем (такое редко бывает)
4. Стараемся задачи нарезать помельче, чтобы по ним было меньше рисков
5. Делаем краткосрочный план по версии и пристально отслеживаем все задачи-кандидаты в версию
6. Делаем буфер/запас на непредвиденные ситуации
7. Вообще у нас есть специальный этап по стабилизации версии, в рамках которого мы только регрессом, нт-шим и не даем добавлять новых фич
и тд
общем это целая отдельная тема
Это очень хороший вопрос. По сути я про это и пишу в своем посте.
Стратегически я хочу донести мысль, что процесс выпуска релизов и процесс долгосрочного планирования — это должны быть перпендикулярные процессы (в идеале). Есть самолет, которые летает строго по расписанию и забирает фичи, которые готовы к выпуску. Все должны с этим смириться. Да, в этом случае надо смириться с тем, что некоторые VIP-пассажиры могут не попасть на этот рейс (но попадут на следующий). Но в целом такой подход единственно правильный на таких проектах.
Надо понимать мотивацию ради чего мы это делаем — это повышение качества и устранение ночных посиделок и авралов о которых вы пишете. Несколько раз можно поавралить, но бесконечно так делать нельзя.
В нашей ситуации мы не можем себе позволить рисковать качеством версии. Если мы допустим, что к-н фича будет делаться до последнего момента и мы не успеем ее протестировать и тд, то мы рискуем порушить систему. В нашем случае — это неприемлемо.
Поэтому мы всячески стараемся до этого не доводить:
1. Стараемся делать долгосрочный план по фича, чтобы заранее видеть проблемы
2. Делаем фичи в ветках или в танке, но предусматриваем «рубильник» для ее отключения в случае чего
3. В крайнем случае вымерживаем (такое редко бывает)
4. Стараемся задачи нарезать помельче, чтобы по ним было меньше рисков
5. Делаем краткосрочный план по версии и пристально отслеживаем все задачи-кандидаты в версию
6. Делаем буфер/запас на непредвиденные ситуации
7. Вообще у нас есть специальный этап по стабилизации версии, в рамках которого мы только регрессом, нт-шим и не даем добавлять новых фич
и тд
общем это целая отдельная тема
>> Примеряя на себя статью, появилась мысль (наверняка, не новая — как и многое в этом мире) — а если релизы ранжировать по сложности изменений: мелочь — раз в неделю, среднее — раз в месяц, а совсем большое — квартал или реже? Кто-то подход такое реализовывал и можно ли кратко поделиться результатами?
Я могу сказать с какими идеями мы нахлебались горя:
1. Лучше не готовить несколько релизов одновременно, например, одновременно готовить релиз к выпуску через 2 недели и через 2 месяца, тк каждый релиз — это дополнительная инфраструктура (стенды, ветки и тд).
2. Лучше не планировать релиз (а тем более если их несколько) слишком на долгий срок, тк риски возрастают экспоненциально.
3. Лучше даже не пытаться делать задачи, которые требуют 2-3 месяца. Надо обязательно их резать на части и выпускать более мелкими частями. Каждая такая задача — это мина замедленного действия.
поэтому я бы стал реализовывать предложенную вами схему, а вместо этого исповедую схему: все задачи делаются в фича ветках (или в транке, но с рубильником), релиз в любой момент времени может готовиться только один.
но это наш опыт ;-)
Я могу сказать с какими идеями мы нахлебались горя:
1. Лучше не готовить несколько релизов одновременно, например, одновременно готовить релиз к выпуску через 2 недели и через 2 месяца, тк каждый релиз — это дополнительная инфраструктура (стенды, ветки и тд).
2. Лучше не планировать релиз (а тем более если их несколько) слишком на долгий срок, тк риски возрастают экспоненциально.
3. Лучше даже не пытаться делать задачи, которые требуют 2-3 месяца. Надо обязательно их резать на части и выпускать более мелкими частями. Каждая такая задача — это мина замедленного действия.
поэтому я бы стал реализовывать предложенную вами схему, а вместо этого исповедую схему: все задачи делаются в фича ветках (или в транке, но с рубильником), релиз в любой момент времени может готовиться только один.
но это наш опыт ;-)
По сути — у нас релизы выкатывались примерно каждые 40 дней. Крупные доработки живут в отдельной ветке, попадают в основную только после полного тестирования. Релизная ветка выделяется из основной, далее несколько итераций сборки-тестирования-исправлений, когда качество продукта стало достаточно хорошим, принимается решение о выкате релиза на публику. Далее переходим к следующему релизу. И так далее. Скучно, конечно, никаких авралов, в выходные никто не выходит, потому что все делается вовремя и качественно.
Возникло сразу несколько вопросов:
Существуют ли в системе ГИС ЖКХ отдельные компоненты с независимым релизным циклом (намёк на микросервисы)?
Что мешает регулярно наращивать компетенции и уровень автоматизации, чтобы постепенно стремиться к "прозрачным релизам по кнопке без даунтайма"?
Как вы думаете, существует ли недостижимый предел частоты релизов для вашего проекта?
Заранее спасибо.
1. Именно «микро» сервисы у нас есть. Но в рамках задач, рассматриваемых в данной статье они мало помогают. Как мне кажется, нам более полезно иметь более крупные подсистемы с независимым релизным циклом. Мы в эту сторону смотрим.
2. Ничего не мешает. Мы это делаем. Стремимся, но не факт что дойдем :-)
3. Я в идеале хотел бы, чтобы вообще можно было выпускать любую фичу когда она готова не зависимо от других. Думаю, это теоретически возможно, но неизвестно дойдем ли мы до этого на практике (чем дальше будем совершенствовать процесс, тем меньше уже будет отдача от него).
2. Ничего не мешает. Мы это делаем. Стремимся, но не факт что дойдем :-)
3. Я в идеале хотел бы, чтобы вообще можно было выпускать любую фичу когда она готова не зависимо от других. Думаю, это теоретически возможно, но неизвестно дойдем ли мы до этого на практике (чем дальше будем совершенствовать процесс, тем меньше уже будет отдача от него).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление релизами на ГИС ЖКХ — делимся опытом и боремся с интуицией