Процесс «Управление релизами» — для постпроектной поддержки или развития продукта / Хабр

Релиз  менеджер

В связи с расширением команды Persha Studia ищет Релиз менеджера для одного из самых ожидаемых ММО проектов года — World of Warplanes.
Если Вы хотите вместе с нами работать над такими проектами, как World of Tanks,  World of Warplanes и другими – приходите, мы ищем грамотных, перспективных и талантливых специалистов!
Предлагаем высокую зарплату и работу над сложными проектами в высокопрофессиональной команде.

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

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

Содержание работы
•  Составление, поддержка в актуальном состоянии Базы Знаний всех взаимосвязей в рамках проекта, передача информации новым командам (архитектура веб-компонентов, принципы их взаимодействия между собой и с игровым сервером);
•  Координация работ нескольких офисов по любым вопросам разработки, тестирования и деплоймента, в результате чего должны быть налажены необходимые связи;
•  Решение коммуникационных и других вопросов по процессам разработки;
•  Отладка существующей системы деплоймента, выработка рабочего регламента, затем непосредственное проведение релизов по выработанному регламенту;
•  Выставление задач на единые для всех проектов компоненты (например,  веб) и доведение их до скоординированного релиза;
•  Вопросы финального пред-релизного тестирования разных компонент;
•  Отслеживание наиболее проблемных мест (в разработке, взаимодействии и пр.) и вычленение проблемы с целью её решения, чтобы в дальнейшем это не мешало нормальной работе;
•  Главная цель – отлаженный и четко структурированный выпуск новых версий.

Требования
•  Предыдущий опыт в качестве Project Manager или Lead разработки, главная черта – нацеленность на Результат
•  Сильные аналитические способности, коммуникативность
•  Умение ясно излагать мысли на бумаге письменно и в виде схем и диаграмм
•  Обязательный технический бэкграунд и понимание процессов при разработке
•  Способность быстро решать проблемы
•  Способность работать автономно над многими задачами одновременно.
•  Хороший английский язык.

Условия работы:
Офис в районе м. Контрактовая площадь (в 5 мин ходьбы от метро)
Гибкий режим работы (начало рабочего дня с 10:00 до 11.00 ч.)
5-дневная рабочая неделя
24 календарных дня оплачиваемого отпуска
Медицинская страховка
Курсы английского языка в офисе

Позиция расчитана на полный рабочий день в Киеве.
Пожалуйста, присылайте Ваше полное резюме на e-mail , указав в subject строке «Релиз  менеджер»

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

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

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

релиз менеджер это

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

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

Отсутствие автоматизации приводит к нагрузке на вашу команду разработчиков и вносит человеческий фактор в ваше окружение, что влияет как на скорость и эффективность работы команды. Правильная автоматизация сформирует неизменный повторяемый процесс, уменьшающий количество ошибок и время релиза. Гибкие методологии — будь то scrum или lean — все крайне рекомендуют автоматизировать сборку, автоматизацию тестов, автоматизацию отгрузки/деплоя, и автоматизацию ревью/обратной связи. Особенно важно, что автоматизация освобождает команды разработки от излишней работы по ручной конфигурации, позволяя сосредоточиться на коде и разработке продукта.

Например, как только разработчик коммитит изменения в систему контроля версий, изменения автоматически интегрируются с остальными модулями. Затем уже собранное приложение автоматически размещается на тестовой среде. Собранные модули затем автоматически деплоятся на тестовую среду. Если были изменения в платформе или окружении, эти изменения автоматически билдятся и переносятся на тестовую платформу. Следующим шагом автоматически проводятся тесты применимости такой сборки, в которые также входят тесты производительности, надежности и емкости. Разработчики и/или руководители уведомляются только в случае ошибок. Однако, основной акцент остается на разработке ядра, а не просто на дополнительной излишней активности. Конечно, какие-то ручные проверки в любом случае останутся, их нужно будет проводить команде релиз-менеджеров, чтобы переходить к следующим шагам, но почти вся деятельность в рамках процесса деплоя может быть более или менее автоматизирована.

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

Существует целый ряд технологий, доступных на рынке в каждом из этих разделов, включая автоматизацию билдов (например Ant, Maven, Make), непрерывную интеграцию (Jenkins, Cruise Control, Bamboo), автоматизацию тестирования (Silk Test, EggPlant, Test Complete, Coded UI), и непрерывный деплой (Bamboo, Prism, Jenkins). Внедрение best practices обычно требует стратегического планирования и инвестиций времени на ранних стадиях вашего проекта. Но это уменьшит организационные расходы и расходы на внедрение изменений на последующих стадиях.

Второй тренд — использование виртуализации и облачных платформ в качестве разработческой и тестовой среды.

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

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

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

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

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

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

Третий тренд — использование распределнных систем контроля версий. Подобные системы, как git, mercurial, perforce — становятся все более и более популярными благодаря той гибкости, которую они дают командам, чтобы взаимодействовать на уровне кода. Фундаментальная основа таких систем заключается в том, что каждый пользователь держит у себя версию репозитория со всей историей на своем компьютере. Нет необходимости в отдельном мастер-репозитории, однако большая часть команд использует его все равно как best-practice. Распределенные системы позволяют программистам работать оффлайн и коммитить изменения локально.

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

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

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

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

Определение слова релиз, релиз-кандидат


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

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

Что такое релиз-кандидат?

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

Релиз-менеджер

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

Иногда производители могут пропускать стадию выпуска релиз-кандидата, а могут выпустить их несколько. В этом случае им присваиваются номера – RC1, RC2 и так далее.

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

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

Но даже этот этап может быть разбит на две фазы. Сначала выпускается релиз для производителей – RTM (Release to manufacturing). К примеру, операционные системы сначала поставляются сборщикам компьютеров, с тем, чтобы к тому моменту, когда новая версия операционной системы появится в свободном доступе, в продаже уже были компьютеры, на которых она установлена.

И наконец, выпускается общедоступный релиз – GA (General availability). Он тиражируется на различных носителях и поступает в свободную продажу. Это уже окончательная версия нового продукта, предназначенная для всех пользователей. Далее последуют только выпуски обновлений, патчей и сервис-паков. И так до выпуска новой версии программы, а там все начнется сначала!

Процесс Управления Релизами.

Основные понятия.

Релизы содержат одно или несколько авторизованных изменений. Они могут классифицироваться в первую очередь по уровню релиза. Часто релизы разделяют на:

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

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

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

· Срочные исправления – обычно внедряются как быстрые исправления проблем и известных ошибок.

Единицы релиза. В отношении аппаратного обеспечения вопросы возникают только при полной замене ПК или при раздельной замене плат и дисководов жестких дисков (или даже оперативной памяти и процессоров). Для программного обеспечения изменения возможны на уровне системы, комплекса, программы или модуля. Хорошим примером может быть библиотека DLL (Dynamic Link Library) в среде Windows, часто используемая несколькими программами. Иногда в составе пакета поставляется новая версия DLL, что может потребовать нового тестирования и переустановки всех других программных пакетов. В данном процессе также прорабатывается принцип минимального содержания релиза.

Цель процесса.

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

Задачами Процесса Управления Релизами являются:

· Планирование, координация и внедрение (или организация внедрения) программных и аппаратных средств.

· Разработка и внедрение рациональных процедур для распространения и инсталляции изменений в ИТ-системах.

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

· Коммуникации и оповещение пользователей, учет их ожиданий при планировании и развертывании новых релизов.

· Определение состава релизов и планирование их развертывания совместно с Процессом Управления Изменениями.

· Внедрение новых версий программных и аппаратных средств в рабочую инфраструктуру под контролем Управления Изменениями и при поддержке Управления Конфигурациями. Релиз может включать любое количество Конфигурационных Единиц, а также не только программные и аппаратные средства, но и документацию, например, отчеты, планы, руководства по поддержке.

· Обеспечение сохранности оригинальных копий программ в Библиотеке эталонного программного обеспечения (DSL) и регулярного обновления базы данных CMDB; то же касается аппаратных средств на Складе DHS.

Процесс Управления Релизами.

Процесс Управления Релизами состоит из следующих видов деятельности:

· разработка политики в отношении релизов и их планирование;

· компоновка и конфигурирование релизов;

· тестирование и приемка релизов;

· планирование развертывания релизов;

· оповещение, подготовка и обучение;

· распространение и инсталляция релизов.

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

Рис. 1 Управление Релизами.

Успешное проведение Управления Релизами зависит от входной информации, поступающей из других процессов ITIL, и от взаимодействия с этими процессами (рис. 1). Главными являются интерфейсы со следующими процессами.

Управление Конфигурациями отвечает за регистрацию доступных версий программного и аппаратного обеспечения в базе данных CMDB в качестве Базисных Конфигураций. Программы, включаемые в Библиотеку DSL, и аппаратные средства для DHS регистрируются в CMDB с согласованным уровнем детализации.

Релиз менеджер

Мониторинг статуса, выполняемый Процессом Управления Конфигурациями, отражает статус каждой Конфигурационной Единицы, например, «В активном использовании», «В разработке», «В тестировании», «В запасе» или «В архиве».

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

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

ИТ-сервис обычно включает в себя инфраструктурное аппаратное обеспечение вместе со стандартным или разработанным собственными силами программным обеспечением.

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

HP Codar.

Программа HP Codar помогает существенно ускорить выпуск приложений за счет автоматического развертывания и повышения прозрачности процесса выпуска релиза. Программа HP Codar обеспечивает полный обзор различных версий приложения в течение всего жизненного цикла.

Основные характеристики:

· Быстрая автоматизация за счет использования декларативных топологических моделей — программа HP Codar позволяет использовать содержимое из внешних источников, что помогает легко создавать модели приложений и сразу же начинать развертывание. Создайте визуальную топологическую карту компонентов приложения с указанием конечного состояния, а программа HP Codar незаметно для вас скоординирует все компоненты и организует развертывание.

· Полный обзор версий и управление процессом разработки — программа HP Codar обеспечивает полный обзор различных версий приложения в течение всего жизненного цикла. Вы можете просматривать, какие версии приложения развернуты в различных средах, и управлять процессом разработки за счет продвижения и отклонения сборок.

· Управление инфраструктурой вместе с кодом — экспорт моделей приложения в виде файлов JSON позволяет управлять моделями, а также сохранять и обновлять их параллельно с написанием кода. Во время развертывания программа HP Codar будет использовать последнюю версию модели, что гарантирует тщательное тестирование, воспроизводимость и прозрачность развертываний приложения.

· Использование разнообразных инструментов — возможность использования разнообразных средств HP и других производителей, а также программ с открытым кодом для разработки, подготовки и развертывания приложений значительно повышает гибкость. Можно воспользоваться публичными интерфейсами API и новым уровнем интеграции с инструментами Jenkins, Chef и Puppet. Это позволяет добавлять существующие проектные элементы в HP Codar в качестве компонентов и использовать их для развертывания приложений.

· Предварительный просмотр и отладка рабочих процессов — программа HP Codar включает полную версию продукта HP Operations Orchestration, который обеспечивает предварительный просмотр и отладку рабочих процессов, созданных с помощью HP Codar. Это является большим преимуществом при поиске и устранении проблем развертывания.

Подробное изложение вопросов, затронутых в лабораторной, можно найти в литературе [1, 3]. Практические аспекты этих вопросов можно отыскать в работах [2, 4,5,6,7,8].

Знания следует самостоятельно проверить путем ответов на контрольные вопросы.

Список использованной литературы:

а) основная литература:

1. Введение в реальный ITSM / Роб Ингланд; Пер. с англ. – М.: Лайвбук, 2010. – 132 с.

2. Евгений Аксенов, Игорь Альтшулер Аутсорсинг: 10 заповедей и 21 инструмент. — СПб.: Питер, 2009. — 464 с.

б) дополнительная литература:

3. ИТ-Сервис-менеджмент. Введение. М. 2003

4. Кэмерон C. Управление контентом предприятия. Вопросы бизнеса и ИТ. Пер. с англ. А. Кириченко. — М.: Логика бизнеса, 2012. — 176 с.

5. Ланкин В.Е., Бричеева Н.Н., Макарова И.В. Управление ИТ-сервисами и контентом. Учебное пособие. Таганрог, 2012. – 100 с.

6. Овладевая ITIL / Роб Ингланд; Пер. с англ. – М.: Лайвбук, 2011. – 200 с.

7. Введение в ИТ Сервис-менеджмент / Ян Ван Бон, Георгес Кеммерлинг, Дик Пондман; Рус.редакция — Потоцкий М.Ю..

8. Метрики для управления ИТ-услугами / Питер Брукс, 2008 — 288 с.

9. Марк Р. Гилберт. Магический квадрант для управления контентом, 2010.

10. Бьерн Страуструп. Жизненные циклы информационных систем

Список контрольных вопросов:

1. Виды релизов.

2. Пример единицы релиза.

3. Цель процесса релиза.

4. Задачи процесса релиза.

5. За какие функции отвечает управление конфигурациями?

6. За какие функции отвечает процесс управления изменениями?

7. Что такое HP CODAR?

8. Основные функции HP CODAR.



Дата добавления: 2016-12-31; просмотров: 199 | Нарушение авторских прав


Похожая информация:


Поиск на сайте:


Работа Релиз Менеджер, Москва — 464 вакансии

.

.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *