Управление релизами на ГИС ЖКХ — делимся опытом и боремся с интуицией

    Почему опоздать на авиарейс и не полететь — это не всегда плохо? Кто виноват в том, что вы опоздали на стыковку? Зачем приезжать в аэропорт заранее? Может ли полететь А380 в Астрахань? Почему интуиция не всегда работает? Неожиданности случаются — никогда не было и вот опять? Почему пассажиры хлопают пилоту после посадки?

    Предположим, вы разрабатываете государственную информационную систему (ГИС) общероссийского масштаба. Проектная команда (аналитики, разработчики, тестировщики, служба поддержки, служба инфраструктуры и др.) составляет более сотни человек. Система была внедрена в опытную или в промышленную эксплуатацию. Тысячи организаций интегрировались с вашей системой и начали работать с ней, еще большее количество планирует интеграцию. Десятки тысяч организаций работают через Web-интерфейс. В системе для граждан размещается полезная информация, а также предоставляются интересные функции. Заказчик и/или пользователи требуют новых доработок. Миллионы людей по всей стране регистрируются и пользуются системой. От внешнего мира прилетают подарки в виде изменений цен на нефть, санкций, ограничений и т.д.

    Представили? Так вот, именно таким проектом в настоящий момент является проект ГИС ЖКХ, о котором ранее мы начали рассказывать и теперь хотим продолжить.

    Источник

    Первые опыты братьев Райт


    Скорее всего, если вы работаете в небольшой компании и разрабатываете “маленькие проекты”, то многие релизные процессы как таковые у вас отсутствуют. Схема работы выглядит примерно так. Вы просто прикидываете, что было бы неплохо выпустить какие-то фичи через 4-5 месяцев. Далее вы месяцок другой пишете постановки, разрабатываете разрабатываете, потом стараетесь все это хозяйство стабилизировать, чтобы выпустить новую версию ПО в эксплуатацию. Конечно, к моменту выпуска обнаруживается, что какие-то доработки никак не получается стабилизировать, где-то вскрываются недочеты в постановках, так как постановки делались давно и сейчас уже что-то поменялось, где-то оказалось, что подписались под нереальной функциональностью и др. Тем не менее, такой подход вполне себе работает, но, как правило, до тех пор, пока проектная команда небольшая и интенсивность изменений невелика (система была не введена в эксплуатацию или пилотировалась на части пользователей и т.д.). В принципе, без процессов можно масштабироваться до довольно крупных проектов — и до 20 человек и до 40 человек — все зависит от крутости отдельных личностей и их самоотверженности. Наверняка многим знакома ситуация, когда проектная команда, состоящая из крутых и отчаянных специалистов, в случаях когда уже сроки горят и почти все пропало дружно напрягалась и … “на своих плечах”, “на морально-волевых” через горы коробок из-под съеденной пиццы в итоге вытаскивала версию в эксплуатацию.

    Уилбер и Орвилл Райт, вошедшие в историю как братья Райт, первыми в мире построили самолет и совершили на нем полет. Источник

    Поверьте, мы тоже через это прошли (именно поэтому мы так любим теперь всевозможные безумства типа Гонки Героев, марафоны и т.п.). Но в какой-то момент мы поняли, что все имеет предел и что при реализации систем масштаба ГИС ЖКХ без внятного релизного процесса мы гарантировано получаем три основных неприятных момента:

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

    Опыт ЛАНИТ по развитию ГИС ЖКХ говорит нам о том, что одним из важнейших моментов для перехода на “промышленные рельсы” при реализации больших проектов является качественное построение релизного процесса. Этого, конечно, недостаточно для полного счастья, но релизный процесс лежит в основе всего, и без него у вас гарантированно все будет гораздо хуже, чем могло бы быть.

    В этой статье мы опишем две главных, по нашему мнению, практики, которые лежат в основе эффективного релизного процесса в IT-системах масштаба ГИС ЖКХ:

    • использование схемы регулярной поставки функциональности,
    • сокращение релизного цикла.

    С одной стороны, эти практики довольно хорошо известны и используются в рамках многих методологий, а также зафиксированы в Agile Manifesto. Однако они во многом противоречат интуиции, требуют определенной квалификации и навыков, а потому сложны для обоснования и встречают непонимание как у Заказчика, так и внутри проектной команды. Для их внедрения в стандарты корпоративной деятельности потребуется очень хорошее понимание “чего мы хотим добиться” и “почему именно внедрение этих практик приведет к желаемому результату”. Ниже мы рассмотрим с примерами эти практики и основные проблемы при их внедрении.

    Когда мы анализировали наши внутренние процессы, связанные с управлением релизами, в голове появилась ассоциация с работой современной авиакомпании.

    Регулярное авиасообщение


    Авиакомпания сделала анализ рынка, спрогнозировала, какие маршруты будут иметь большой пассажиропоток и стали бы выгодны на следующий сезон, договорилась с кем нужно, получила права на нужные маршруты, запустила регулярные авиарейсы. Расписание авиарейсов известно задолго, как правило, за полгода-год. Кто конкретно полетит, авиакомпании, конечно же, неизвестно — она ориентируется на среднюю прогнозную заполняемость. Далее авиакомпания может заключить долгосрочные договоры с аэропортами, продумать, какие воздушные суда наиболее выгодно ставить на рейсы, наладить свои внутренние процедуры и т.д. Это все способствует оптимизации расходов.

    Источник

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

    У регулярного авиасообщения есть и свои минусы. Если сотрудник купил билет на рейс, но не успел, то самолет его не дожидается. Неприятно? Да. Может быть так, что сотруднику нужно улететь сегодня, а рейсы есть только завтра или вовсе только через неделю. Не очень хорошо? Да. Зато большим плюсом является то, что вы можете за полгода-год запланировать свою поездку и быть уверенным, что авиарейс состоится. Вы точно знаете, когда прилетите, и можете сообщить это время вашим близким, которые вас могут встретить, или вы можете лететь с пересадкой и не волноваться, что вы не успеете на стыковку. Ну и вообще, вдумайтесь, огромный, тяжелый железный самолет, который для 90% человечества непонятно вообще как летает, очень быстро понесет вас черт знает куда и стоить вам это будет почти как сутки-двое в поезде.


    Вернемся к проекту. В ГИС ЖКХ используется регулярная поставка функциональности. Команда ЛАНИТ делает план-график релизов на 1 год, где фиксирует даты релизов так, чтобы выпуски были примерно 1 раз в месяц. Так как за год может еще все сто раз поменяться (об этом ниже), то в момент составления графика мы еще точно не знаем, какие конкретно доработки будут реализованы и выпущены в эксплуатацию.

    При планировании учитывается график регламентных работ, которые требуются для инфраструктуры/службы эксплуатации. Необходимо, чтобы глобальные и разнородные изменения не накладывались друг на друга — так снижаются риски и легче держать все под контролем. Например, устанавливать новую версию ППО и одновременно апгрейдить версию СУБД или обновлять прошивку контроллеров СХД — очень плохая идея.

    Принципиальный момент состоит в том, что даты релизов впоследствии не меняются. Если версия запланирована на какую-то дату, то мы должны разбиться в лепешку, но выдержать запланированный срок.

    Дальше мы расскажем зачем и почему.

    То, что условия для каждого релиза примерно одинаковые (длительность, команда, специфика реализуемых задач и т.д.) позволяет планировать и отладить все процедуры по подготовке и выпуску. Люди, не погруженные в производственные процессы, могут не понимать всей сложности выпуска версии на таком большом проекте как ГИС ЖКХ. Для того, чтобы версия была выпущена, нужно проделать массу операций, таких как регрессионное тестирование (может быть, несколько раз), нагрузочное тестирование, тестирование скриптов развертывания и миграции данных, проанализировать статистику функционирования (SQL-запросы, сервисы и т.д.). Ситуация усугубляется тем, что эти операции могут быть долгими, например, развертывание версии на тестовом стенде может занимать сутки. Если что-то пойдет не так, то можно легко выйти из графика. Поэтому если у вас не будет плана-графика с регулярными и примерно одинаковыми по длительности циклами, то гарантирую, что каждый выпуск будет для вас на 146% гораздо более серьезным испытанием.

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

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

    Так же, как регулярное транспортное сообщение, это основа глобальной транспортной системы, релизный процесс на основе регулярной поставки функциональности — это базис для эффективного развития системы масштаба ГИС ЖКХ. Если этот процесс налажен, то на него уже можно “нанизывать” планы по реализации и поставке функциональности.

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

    Посадка на самолет после окончания регистрации


    У авиакомпаний имеется отлаженная процедура регистрации на рейс, которая в частности, включает правило о том, что пассажир должен зарегистрироваться на рейс не позднее, чем за 40 минут до вылета. Зачем нужны эти 40 минут? Они нужны для того, чтобы было достаточно времени для проверки багажа, загрузки его в самолет, для того чтобы на основании веса багажа и количества зарегистрированных пассажиров можно было рассчитать необходимое топливо, заправить самолет и т.д. Кроме того, это время нужно и для того, чтобы у пассажиров было достаточно времени, чтобы найти нужный выход/терминал. Понятно, что с грузом или пассажиром может что-то пойти не так (пассажир заблудился в аэропорту или что-то случилось с багажом) и не хватит даже этих 40 минут. Но все же время окончания регистрации — это выработанный за многие годы компромисс между тратой времени пассажира и риском нештатных ситуаций.

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


    Источник

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

    Почему это плохо?

    Во-первых, надо мужественно признаться и принять тот факт, что, что все “дожимания”, “а вдруг успеем” — это скорее всего прокол управления производством. Это значит, что не были заранее предприняты различные меры и ситуация была доведена до критической. Теперь ситуация будет исправляться за счет “геройств” отдельных людей или команды — овертаймы, костыли, удача и т.п. По опыту это краткосрочно может привести к решению проблемы, но если вы так будете делать постоянно, то это приводит к “выгоранию” людей и прочим очень неприятным последствиям.

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

    К сожалению, ситуации, когда имеется ну очень-очень важная задача и ее обязательно нужно выпустить в текущем релизе, возникают. Но главная мысль — такие ситуации не должны быть общепринятой практикой и поощряться, а наоборот признаваться проблемой и рассматриваться на “ретроспективах”.

    Задержка рейса из-за VIP-пассажира


    Допустим, вы купили билеты на авиарейс с пересадкой. Допустим, вы прикинули адекватное время между стыковками. Вы приехали заранее в аэропорт, прошли регистрацию, сели в самолет, отзвонились папе с мамой, и тут вам объявляют, что рейс задерживается, т.к. на него опаздывает важная правительственная делегация (конечно, вместо этого вам скажут о непогоде или дополнительных проверках :)). Вы вместе со всем самолетом ждете эту делегацию и в итоге улетаете с существенным опозданием. Прилетев в промежуточный пункт, вы обнаруживаете, что у вас осталось всего 30 минут, чтобы сориентироваться в огромном аэропорте, физически добраться до другого терминала. Может быть вы, конечно, и успеете, а может быть, вы что-то в спешке напутаете и убежите не в тот терминал или даже просто не успеете пройти все нужные процедуры. А если вы — тоже член какой-то другой правительственной организации (но просто скромный) и тоже спешите куда-то?

    Источник

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

    В релизном процессе, если вдруг какая-то задача никак не успевается к запланированному сроку, тоже возникает сильнейший соблазн сдвинуть весь релиз — например, на недельку. Кажется, что это легкое и хорошее решение, особенно если эта задача на контроле у Главного заказчика.

    Давайте рассмотрим, к чему это все приводит в конечном итоге.

    В проекте ГИС ЖКХ в рамках очередного релиза выпускается до 100 задач и еще исправления дефектов. Сдвиг релиза означает, что пользователи получат нужную им функциональность или исправления дефектов позже. Конечно, обсуждаемая задача является действительно важной, но при этом многие из остальных 99 задач тоже очень важные, но поскольку с ними все нормально, то мы про них уже забыли.

    Далее. Если мы начинаем регулярно сдвигать версию, то тогда заказчик начинает терять веру в план релизов. У него заседает в голове всегда мысль, что да, конечно, следующий релиз запланирован на 10-е число, но скорее всего что-нибудь случится и будет сдвиг на неделю, а то и на две. Причины сдвигов могут быть разные, но в конце концов все они забываются и остается ощущение нестабильного и непрозрачного процесса.

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

    Если мы допускаем сдвиг версии, то это ухудшает возможности по оптимизации процесса. Напротив, если процедура выпуска однообразна и регулярна, то мы имеем возможность ее совершенствовать. После выпуска версии мы проводим “ретроспективу”, где обсуждаем основные положительные и отрицательные моменты, которые случились за время итерации. С каждым повторением мы делаем какие-то улучшения, в результате накладные расходы снижаются, количество ошибок снижается, результат улучшается.

    Почему большой самолет не всегда лучше


    Авиакомпания может использовать разные типы самолетов на маршруте — региональные самолеты на 75-110 пассажиров (типа SSJ-100), или узкофюзеляжные самолеты на 140-180 пассажиров (типа A320, Boeing 737), или широкофюзеляжные самолеты на 200-300 пассажиров (типа A330, A340), или такие монстры как A380, способные перевезти от 525 до 853 пассажиров. Упрощенно можно считать, что авиакомпания выбирает нужный тип самолета и нужную интенсивность рейса как компромисс желания пассажира иметь, как можно больше рейсов в день и желания авиакомпании снизить расходы на перевозку одного пассажира с целью максимизировать свою прибыль.

    Сейчас в мой родной город Астрахань летают как минимум три авиакомпании, делая по одному рейсу в день на региональных или узкофюзеляжных самолетах. Даже если инфраструктура аэропорта в Астрахани допускала бы прием А380 (самый большой и самый вместительный самолет компании Airbus), то для того, чтобы его загрузить, пришлось бы резко сократить интенсивность полетов, что было бы совсем неудобно для пассажиров. Если разница в стоимости не велика, то пассажиры предпочтут большее число рейсов в день.

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

    Здесь в полный рост встает вопрос по поводу накладных расходов.

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

    Рисунок 1. Зависимость накладных расходов на единицу продукции от длины релизного цикла (для наших условий)

    Действительно, если мы захотим реализовать непрерывный релизный процесс в стиле “реализовали задачу, нажали на кнопку, все работает в проде” или выпускать версию каждую неделю, то это точно потребует от нас существенных первоначальных усилий для перестройки работы. Скорее всего это будет связано с дальнейшим повышением уровня автоматизации, а также повышением дисциплины и отладки всех процедур. Возможно, это повлечет некоторые архитектурные изменения. Мы не работали пока так, чтобы релизный цикл достаточно долгое время составлял две недели или меньше, поэтому поведение кривой в указанном диапазоне — это мое предположение, которое основывается на опыте выпуска небольших промежуточных версий и хотфиксов.

    В районе трех-четырехнедельного цикла мы скорее всего имеем локальный минимум по затратам на единицу продукции, а дальше с ростом длины релизного цикла затраты начинают резко расти. Об этом ниже.

    Дополнительный груз — дополнительное топливо


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

    Если мы выпускаем релиз каждые три-четыре недели, то это требует выполнения определенных процедур для выпуска каждой версии — это два цикла регрессионного тестирования, нагрузочное тестирование, тестирование скриптов развертывания и миграции данных (об этом детальнее напишем в отдельной статье). Ошибочно полагать, что при увеличении цикла до двух месяцев, например, нам потребуется для выпуска выполнить те же самые работы. Дело в том, что если цикл большой, то в него попадает больше изменений. Это в свою очередь вызывает рост потенциальных проблемных мест — в сложной системе этот рост если не экспоненциальный, то точно (из-за взаимного влияния изменений) нелинейный. На самом деле, мы уже сейчас видим, что нам для четырехнедельного цикла не хватает одной итерации регрессионного тестирования. По факту в рамках первого регресса мы выявляем некоторое количество дефектов, исправляем их, а объем изменений оказывается таким, что требуется провести еще один “финальный” регресс. Этот финальный регресс у нас уже более компактный, проходит существенно быстрее и без проблем, но он все же требуется. Если бы мы перешли на двухнедельный релизный цикл, то скорее всего мы смогли бы обойтись только одним регрессом. С другой стороны, если мы увеличиваем цикл до 1,5-2 месяцев, то для стабилизации нам требуется уже не 1,5 регресса, а два-три.

    Стюардесса в салоне нового лайнера объявляет о том, что находится в самолете:
    — На первой палубе — багаж, на второй — бар, на третьей — поле для гольфа, на четвертой бассейн.
    И добавляет:
    — А теперь, господа, пристегнитесь. Сейчас со всей этой фигней мы попробуем взлететь.

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

    Никогда не было и вот опять


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

    Источник

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

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

    Если же, напротив, вы выпускаете релиз каждые две недели, то задачу можно попробовать включить в текущую версию или на худой конец в следующую. В этом случае, от момента готовности задачи до ее выпуска пройдет в худшем случае 4 недели, а скорее всего 2-3. Это чаще всего вполне приемлемо. А это означает, что вы скорее всего обойдетесь без дополнительных затрат на инфраструктуру.

    В зависимости от того, насколько часто у вас могут возникать изменения, тем больше преимуществ вы получите от короткого релизного цикла.

    На проектах масштаба ГИС ЖКХ незапланированные срочные изменения возникают достаточно регулярно. Признание этого факта требует некоторых усилий (да что уж там скрывать — большого мужества), т.к. здесь мы тоже в некотором роде вступаем в противоречие с интуицией и нежеланием работать с рисками. Дело в том, что если рассмотреть какой-то конкретный риск, который может привести к необходимости сделать специальную версию, то его вероятность скорее всего окажется микроскопической. Если в прошлом месяце не было никаких доработок в связи с изменением законодательства или какими-то вновь вскрывшимися региональными особенностями, то мы ничего подобного не ожидаем и в следующем месяце. Поэтому делается вывод — что раз вероятности каждого из событий малы, то ничего вообще и не произойдет. Однако это неправильный вывод. Дело в том, что вероятность того, что реализуется хотя бы один риск, равна сумме вероятностей реализации каждого из отдельных рисков. Поэтому если принять во внимание масштаб всего, что происходит даже за один месяц релизного цикла (количество ключевых сотрудников, принимающих участие в подготовке версии, решений, которые принимаются, количество внешних систем, с которыми ГИС интегрируется, сложность инфраструктуры, сложность предметной области и т.д.), то эта вероятность уже вполне себе может быть существенной. Например, даже с релизным циклом в один месяц у нас, начиная с января 2018 по май 2018 года, уже три раза возникали без преувеличения сверхважные и сверхсрочные задачи, которые надо было сделать ASAP и которые требовали специальной версии. Что уж говорить про релизный цикл в 4-5 месяцев! Если бы мы выпускались каждые 5 месяцев, то скорее всего к этим двум спецверсиям добавилось бы еще 2-3 промежуточные версии, что делает релизные циклы более 1-1,5 месяцев совсем экономически нецелесообразными в наших условиях.

    Поэтому релизные процессы, которые позволяют гибко реагировать на изменения, — это большое благо на проектах масштаба ГИС ЖКХ.

    Хлопаем пилоту только после посадки!


    Каждая недоделанная доработка несет в себе риски для выпуска версии. Нельзя верить на слово производственным менеджерам, какие бы честные глаза у них не были! Лучше верить фактам.

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

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

    Источник

    Мало того, из-за сложности предметной области ГИС ЖКХ всегда остаются риски того, что при проектировании были заложены неоптимальные решения или не учтены какие-то региональные особенности. Многие моменты могут быть выявлены только при опытно-промышленной эксплуатации. Это еще один аргумент за то, чтобы делать релизный цикл короче и выпускать доработки быстрее в эксплуатацию. Вы быстрее получите обратную связь, быстрее апробируете свои решения и сможете быстрее сделать то, что действительно нужно заказчику и рынку. Если релизный цикл длинный, то это наоборот провоцирует делать избыточную функциональность, что повышает риск потратить много сил на то, что потом окажется неправильным или ненужным.

    Экипаж прощается с пассажирами


    Мы рассмотрели основные практики управления релизами, которые для нас оказались основополагающими. Это регулярная поставка функциональности и уменьшение релизного цикла. Несмотря на широкую известность, к сожалению, эти практики на деле не совсем очевидны и в чем-то противоречат интуиции, поэтому часто натыкаются на препятствия при их внедрении.

    В рамках ГИС ЖКХ данные практики внедрены, успешно функционируют долгое время и показывают хороший результат. Мы добились того, что план-график релизов строго соблюдается, процедура подготовки к выпуску версии стала более контролируемой и проходит на порядок спокойнее и штатно, мы можем гибко реагировать на изменения.

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

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

    Об этом можно будет поговорить в следующий раз.

    Было бы интересно услышать ваше мнение. Вы согласны с приведенными в статье утверждениями и рекомендациями? Как у вас устроено управление релизами на крупных проектах? Легко ли проходило внедрение?

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

    Используете ли вы регулярную поставку функциональности?
    Если используется регулярная поставка, то какова длительность релизного цикла?

    ГК ЛАНИТ

    366,00

    Ведущая многопрофильная группа ИТ-компаний в РФ

    Поделиться публикацией
    Комментарии 32
      +1
      Делаете ли вы разделение времени внутри одного цикла на разработку нового и исправление дефектов или эти процессы идут параллельно?
        +2
        Внутри цикла у нас специально выделяется некоторое время (примерно 1,5 недели сейчас), на стабилизацию версии. К началу стабилизации все доработки уже должны быть смержены в релизную ветку и протестированы. Далее добавление новых доработок в эту релизную ветку запрещается и там идет только исправление «наведенных» ошибок. За эти 1,5 недели мы делаем регрессивное тестирование, тестирование скриптов миграции данных и развертывания, НТ и тд.

        А так вообще разработка доработок у нас идет в ветках параллельно и никогда не останавливается ;-)
        0

        Егор, было бы интересно услышать пользователей системы. В госпроектах они обычно подневольные даже если в релизе выдали не то что нужно, так как нет альтернатив.

          0

          Посмотрите на форуме bankir.ru, узнаете много интересного от пользователей. 75 страниц непрерывной радости от этой замечательной системы.

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

            Вообще, сам по себе термин «выдали то или не то» очень субъективен. Чем определяется «подневольность» вообще? В основном тем, что в нормативке прописаны требования к организациям сферы ЖКХ по размещению той или иной информации в определенные сроки. Поэтому, более объективный критерий — это позволяет ли ГИС ЖКХ выполнить организации предписанные ей требования или нет.

            Уверяю, что все такие «блокирующие» доработки или инциденты находятся под постоянным контролем и реализуются максимально оперативно.
              0
              Спасибо за ответ! Менеджмент и разработчики могут рассказать любые красивые истории. Но мне было бы интереснее узнать от пользователей с опытом работы в вашей системе Как сделать ЖКХ, чтобы оно было ГИС повлияли ли на них как-либо частые релизы ГИС ЖКХ…
              GnuriaN Loki3000 crea7or deee MaximKovalev teifo servekon kolodinivan anatan pavlyuts ulvham andrnl evgensoft andewil стало ли лучше или «воз и ныне там»?
                0
                Снова статья для отпущения грехов. Многие претензии как были так и остались к заказчикам и к исполнителям. Проектированием и проверкой вместе с министерством не занимались, а потом сайт и api сделать не могли вменяемые. За 2 года пром эксплуатации так до конца и до ума ничего не довели. На сайт добавили функционал о котором просили в октябре 2016 года только в этом году. И вообще в декабре 2016 министерства вместе с разрабами обещали версию 12 в которой все будет красиво… до сих пор ждем. Работой с api сейчас другая контора занимается и основные вопросы не к api, а к скорости обмена данными.
                  +1
                  >> Снова статья для отпущения грехов.
                  да нет, просто решили поделиться опытом построения релизного процесса

                    +3
                    >> Работой с api сейчас другая контора занимается и основные вопросы не к api, а к скорости обмена данными

                    вообще в ГИС сейчас ежедневно загружаются очень большие объемы данных.
                    вот например на днях загрузили 17 млн платежных документов (система могла принять и больше, просто столько нам отправили)

                    время от времени сталкиваюсь с утверждениями что все плохо, когда разбираемся предметно основные проблемы заключаются в следующем:
                    — в ГИСе реализовано много бизнес- и форматно-логических контролей для обеспечения целостности; по нашей статистике 9% данных не загружается по этой причине. К заказчику поступали обращения убрать контроли и разрешить грузить все подряд, но это было отвергнуто, тк Заказчик считает, что это приведет к снижению качества данных.
                    — неправильная реализация взаимодействия с ГИС-ом в части массовой загрузки — надо учитывать что ГИС — это удаленная система, доступ к которой идет через каналы связи идет, работа организована асинхронном режиме через очереди и тд. (возможно, что у нас тут недостаток документации и думаю сделать на хабре пост на эту тему)
                    — ошибки самого ГИС-а — по нашей статистике доля таких ошибок менее 0,25%. Соглашусь, что нужно вообще сделать 0 — мы работаем над этим.

                    Если есть желание конкретно разобраться в какой-то проблеме — напишите в личку, посмотрим.
                      0
                      Егор, может проблемы как раз в сервисе очередей на каком либо древнем веблоджике, проданном вами же? Пока все звучит как голословные убеждения из книжки «100 приемов для борьбы с конструктивным фидбэком».
                      Как вы собираете метрики производительности, применяется ли трассировка запросов?
                      Могут ли конечные пользователи получать статистику и трассировку по своим запросам?
                        0
                        У нас используется JBOSS AMQ и в целом сплошные опенсурсные технологии — посмотрите предыдущую статью про ГИС ЖКХ, которую вы упоминали.
                        О каком веблоджике вы говорите?
                          –2
                          Jboss AMQ тоже на разных версиях основан — древнем кластеризуемом с бубном или современном кластеризуемом Artemis.

                          А что по поводу конкретных метрик и трассировки?
                    –1
                    ГИС ЖКХ стало каким-то паноптикумом жуликов. Проверил сведения по нескольким многоквартирным домам: вместо управляющих организаций указаны какие-то прохиндеи… Обращаешься с жалобой в поддержку, предлагаешь разместить информацию о подлинных управляющих организациях — или не отвечают совсем, или посылают лесом… Видимо за небольшую денежку любые жулики могут вписать себя в ГИС ЖКХ в качестве управляющей организации и, затем, беспрепятственно стричь купоны… При этом государство (в лице ГИС ЖКХ) де-юре в доле — помогает жуликам собирать деньги и легализовать денежные средства, полученные преступным путём…
                      0
                      Стало ли лучше? Нет. Основная проблема, что тех.поддержка толком не знает как решать те или иные вопросы. Очень часто при заливке через шаблоны выскакивают ошибки, которые не пойми как исправить. Но с опытом просто уже знаешь как исправить эти ошибки и просто не обращаешься в суппорт.

                      Насколько я понял, разработчики столкнулись с проблемой вариативности расчетов КУ на местах. В соседних домах одни и те же услуги могут считаться с кардинальными отличиями или список услуг может отличаться. Из-за этого очень сложно разработать универсальные проверки, например для шаблона ПД. Из чего следует, что при проверке шаблонов выскакивают ошибки, которые нужно исправлять на каждой УК индивидуально.
                        0
                        воз и ныне там
                      +1
                      Как пользователь системы я скажу, что применительно к ГИС ЖКХ практикуется подход, что багу называть фичей и пытаться убедить в том, что так и должно быть.
                      Дабы не быть голословным, предлагаю оценить количество записей полученных в результате поиска
                      image
                      cloud.mail.ru/public/DKdn/9kGFnz6ct
                        0
                        Если что, то в результате записей 11 шт. 10 на первой странице, и 1-а на второй
                      +1
                      Удлось поработать на этом проекте в роли разработчика.
                      Постановка рабочего процесса была очень комфортная, спасибо.
                      –1
                      Вся страна ждет что отменят эту фигню
                      я туда каждый день вбиваю кучу данных, вбивается иногда попыток с десяти с разным успехом и лучше не становится. Ладно что не руками а сервак в цикле дрлбится.
                        0
                        интресный факт
                          0
                          вся страна считала деревянный дом на две половины частным домом, а разработчики гиса его признали многоквартирным. и теперь администрация меняет в системе тип дома иначе инфу не передать, но реально его многоквартирным никто не считает
                            +2
                            Это не разработчик ГИС так считает, это муниципалитет так выгрузил частный сектор с признаком МКД.
                              0
                              Строго говоря сейчас государство полагает, что в частном секторе может быть три основных вида домов: частные жилые дома (на одну семью), сблокированные дома (несколько семей в доме, но части дома примыкают лишь стенами и являются блоками одного и того же дома), многоквартирные дома (даже если в них две квартиры (жилых помещения), но в доме проживает более одной семьи) где имеются общие помещения (чердак или подвал, например)…
                              0
                              Ох, оставлю свои 5 копеек о ГИС ЖКХ.

                              Целый месяц пинал поддержку, чтобы там появилась моя собстенность. Ещё 2 месяца пинал поддержку, чтобы с ней хоть что-то можно было делать из заявленного функционала сервиса. Так и не заработало. Там так всё плохо на техническом уровне, что в форме обратной связи есть поле «Браузер», когда это можно узнавать программно. В итоге попросил закрыть все мои обращения, пожелал удачи. Может попробую через года три снова.
                                –2
                                Система сомнительной ценности на наши с вами деньги. За последние годы такого барахла выходит всё больше и больше. А потом удивляемся, что денег нет.
                                  +3
                                  У меня три вопроса: один к автору и два ко всем.
                                  К автору: вы пишите
                                  «Принципиальный момент состоит в том, что даты релизов впоследствии не меняются. Если версия запланирована на какую-то дату, то мы должны разбиться в лепешку, но выдержать запланированный срок.»
                                  как быть, если случается неприятность и запланированная задача не может попасть в плановый релиз? «выпиливаете» её? а как быть, если она ключевая? У нас в практике было, что нам таки приходилось двигать релизы (не сильно, но да) и сидеть по ночам до выпуска — чтобы сделать то, что хотел заказчик (а потом ещё так же сидеть, чтобы довести до приемлемого качества результаты ночных бдений).

                                  Ко всем:
                                  1. Уважаемые коллеги, понимаю, что тема острая, но есть ли что-то по сути статьи сказать? Можно вычеркнуть при прочтении «ГИС ЖКХ» и читать как «Большие/маленькие/средние проекты/системы» (кому-что нравится). Вот мне понравился вопрос
                                    «Но мне было бы интереснее узнать от пользователей с опытом работы в вашей системе повлияли ли на них как-либо частые релизы ГИС ЖКХ… »
                                    . Правда, на мой взгляд, основная идея статьи о том, как упорядочить хаос в процессе разработке и сделать процесс предсказуемым.
                                  2. Примеряя на себя статью, появилась мысль (наверняка, не новая — как и многое в этом мире) — а если релизы ранжировать по сложности изменений: мелочь — раз в неделю, среднее — раз в месяц, а совсем большое — квартал или реже? Кто-то подход такое реализовывал и можно ли кратко поделиться результатами?
                                    +5
                                    >> как быть, если случается неприятность и запланированная задача не может попасть в плановый релиз? «выпиливаете» её? а как быть, если она ключевая? У нас в практике было, что нам таки приходилось двигать релизы (не сильно, но да) и сидеть по ночам до выпуска — чтобы сделать то, что хотел заказчик (а потом ещё так же сидеть, чтобы довести до приемлемого качества результаты ночных бдений).

                                    Это очень хороший вопрос. По сути я про это и пишу в своем посте.

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

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

                                    Поэтому мы всячески стараемся до этого не доводить:
                                    1. Стараемся делать долгосрочный план по фича, чтобы заранее видеть проблемы
                                    2. Делаем фичи в ветках или в танке, но предусматриваем «рубильник» для ее отключения в случае чего
                                    3. В крайнем случае вымерживаем (такое редко бывает)
                                    4. Стараемся задачи нарезать помельче, чтобы по ним было меньше рисков
                                    5. Делаем краткосрочный план по версии и пристально отслеживаем все задачи-кандидаты в версию
                                    6. Делаем буфер/запас на непредвиденные ситуации
                                    7. Вообще у нас есть специальный этап по стабилизации версии, в рамках которого мы только регрессом, нт-шим и не даем добавлять новых фич
                                    и тд

                                    общем это целая отдельная тема
                                      +4
                                      >> Примеряя на себя статью, появилась мысль (наверняка, не новая — как и многое в этом мире) — а если релизы ранжировать по сложности изменений: мелочь — раз в неделю, среднее — раз в месяц, а совсем большое — квартал или реже? Кто-то подход такое реализовывал и можно ли кратко поделиться результатами?

                                      Я могу сказать с какими идеями мы нахлебались горя:
                                      1. Лучше не готовить несколько релизов одновременно, например, одновременно готовить релиз к выпуску через 2 недели и через 2 месяца, тк каждый релиз — это дополнительная инфраструктура (стенды, ветки и тд).
                                      2. Лучше не планировать релиз (а тем более если их несколько) слишком на долгий срок, тк риски возрастают экспоненциально.
                                      3. Лучше даже не пытаться делать задачи, которые требуют 2-3 месяца. Надо обязательно их резать на части и выпускать более мелкими частями. Каждая такая задача — это мина замедленного действия.

                                      поэтому я бы стал реализовывать предложенную вами схему, а вместо этого исповедую схему: все задачи делаются в фича ветках (или в транке, но с рубильником), релиз в любой момент времени может готовиться только один.
                                      но это наш опыт ;-)
                                        0
                                        По сути — у нас релизы выкатывались примерно каждые 40 дней. Крупные доработки живут в отдельной ветке, попадают в основную только после полного тестирования. Релизная ветка выделяется из основной, далее несколько итераций сборки-тестирования-исправлений, когда качество продукта стало достаточно хорошим, принимается решение о выкате релиза на публику. Далее переходим к следующему релизу. И так далее. Скучно, конечно, никаких авралов, в выходные никто не выходит, потому что все делается вовремя и качественно.
                                        +3

                                        Возникло сразу несколько вопросов:


                                        1. Существуют ли в системе ГИС ЖКХ отдельные компоненты с независимым релизным циклом (намёк на микросервисы)?


                                        2. Что мешает регулярно наращивать компетенции и уровень автоматизации, чтобы постепенно стремиться к "прозрачным релизам по кнопке без даунтайма"?


                                        3. Как вы думаете, существует ли недостижимый предел частоты релизов для вашего проекта?



                                        Заранее спасибо.

                                          +2
                                          1. Именно «микро» сервисы у нас есть. Но в рамках задач, рассматриваемых в данной статье они мало помогают. Как мне кажется, нам более полезно иметь более крупные подсистемы с независимым релизным циклом. Мы в эту сторону смотрим.
                                          2. Ничего не мешает. Мы это делаем. Стремимся, но не факт что дойдем :-)
                                          3. Я в идеале хотел бы, чтобы вообще можно было выпускать любую фичу когда она готова не зависимо от других. Думаю, это теоретически возможно, но неизвестно дойдем ли мы до этого на практике (чем дальше будем совершенствовать процесс, тем меньше уже будет отдача от него).

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

                                        Самое читаемое