IT для неайтишников: Управление релизами, когда и зачем нужно?

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

Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний (АйТи Мегастар/АйТи МегаБокс/АйТи Мегагруп). Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Являюсь одним из идеологов концепции IT~BP (партнёрство между IT и бизнесом).

Процесс управления релизами является частью более глобального процесса управления изменениями. Релиз — это пакет изменений, которые подготовили для внедрения. Логика внедрения изменений в IT и вне IT одинаковая.

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

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

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

За счет такого уровня «абстракции» уходит привязка к определённой области (бухгалтерия, производство, логистика либо иное), уходят специфические термины, вместо этого появляется понятная даже ребёнку схема взаимодействия.

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

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

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

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

В целом, в разработке программного обеспечения всё где-то так. Но процесс идет много быстрее за счет «интерактивного программирования». Программист может быстро собрать свой проект и запустить код, чтобы посмотреть, как он работает. Быстрее выявляются недоработки, быстрее идет работа.

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

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

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

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

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

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

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

Вторая проблема решается через управление релизами, третья через системы контроля версий. Сначала решим третью проблему, потом вернёмся ко второй.

Что такое система контроля версий? Представьте, что вам с кем-то нужно совместно работать над документом. Вы берете текущее состояние документа и делаете от него «ветку», в которую вносите изменения. То есть получаете свою версию документа. А потом у вас есть возможность слить несколько веток изменений в одну, то есть получить итоговый документ.

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

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

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

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

Теперь возвращаемся ко второй проблеме.

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

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

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

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

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

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

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

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

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

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

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

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

Еще нужно описывать состав релиза. Хотя бы какие изменения в него вошли и какие недоработки в рамках него исправляются. Такой документ называют Release Notes (записка к релизу). По таким документам можно восстановить историю релизов.

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

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

Такое часто практикуют при внедрении масштабных проектов, когда разом внедряется много крупных изменений и есть риски все сломать на продуктиве. В IT есть шутка, что быстро поднятое упавшим не считается (упало — полностью сломалось).

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

То есть номер 2.5.14 можно читать как: «После второго раза, как все начали работать совсем по-другому, было сделано 5 средних изменений в процессах работы, после чего успели 14 раз внедрить исправления по критическим ошибкам».

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

Например, номер релиза 2.5.14 говорит, что нам понадобилось 14 сверхсрочных внедрений, скорее всего часть из них была связанна с аварийными ситуациями. Много это либо мало зависит от частоты средних по масштабам изменений. Если они происходят раз в год, то скорее всего внедрялись небольшие, но важные для бизнеса изменения. Если они происходят раз в месяц либо раз в неделю, то в пору задуматься о качестве релиза. Скорее всего, процесс тестирования сломан и не работает. А еще можно почитать Release Notes для каждого релиза, чтобы понять, в чем было дело.

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

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

Мы сделали шаг в сторону от терминологии мира информационных технологий и простыми словами объяснили, что такое процесс управления релизами и зачем он нужен. Конечно, здесь процесс управления релизами описан не совсем полностью. Например, есть процесс планирования релиза. В ходе тестирования релиза существует момент «фичефриз», когда в релиз запрещают вносить изменения по новым доработкам, оставляя возможность вносить только исправление ошибок. Затем наступает момент «кодфриз», когда запрещают вносить даже исправления ошибок. То есть можно вносить исправление только по блокирующим ошибкам. Бывают ситуации, когда релиз приходится двигать по срокам.

Если в компании много разработчиков, управление становится непростой и напряжённой работой. У всех планы, сроки, лишение премий и прочие. Люди пытаются договориться, надавить, обмануть наконец. Например, внедрить новый функционал под видом исправления ошибок. Бывают курьёзы, когда разработчиков спрашивают, почему для исправления опечатки в одном слове (должна поменяться 1 строка кода), пришлось изменить 2 тысячи строк кода? Иногда ответы на этот вопрос поражают своей изворотливостью.

Тем не менее это необходимая работа, которая помогает предотвращать многие проблемы. Если нет тестовых стендов и изменения попадают напрямую на продуктив, то будет нескончаемый поток ошибок с продуктива. А команда разработки будет тратить 50–80 процентов своего времени на исправление ошибок, а не на полезную работу.

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

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

Если не смотреть за метриками, то будет не понятно нужно было ли вносить какие-то изменения либо нет. А раз так, то вообще зачем что-то разрабатывать и вносить. Возможно, просто делается какая-то бесполезная работа. Кстати, анализ Realese Notes тоже помогает выявить работу ради работы.

Иногда процесс управления релизами неверно считают частью процесса обеспечения качества (QA), хотя он больше относится к процессу управления изменениями. Такое делать нельзя, теряется контроль за метриками и управление информационным продуктом. Метрики и инциденты возникают на продуктиве, а не на стендах тестирования.

Если вы дочитали до конца, и написанное было для вас полезным, то спасибо вам.

Полезные материалы по теме: