Путешествие в свободный от стресса релиз
Это видео гарантирует снижение уровня стресса перед следующим релизом блокбастера.
Лучшая мера успеха гибкой команды - это когда работающее программное обеспечение выпускается для клиентов. Но даже опытные команды разработчиков программного обеспечения испытывают боль, когда пришло время проверять завершенные проблемы на наличие артефактов; проверки кода были пропущены, код не был объединен, сборка для объединенного кода завершилась неудачно…Звучит знакомо?
В этой презентации вы узнаете:
- Кодирование лучших практик, которые улучшат вашу способность поставлять качественный продукт. Узнайте, почему ревью кода необходимы для обеспечения качества, и как мониторинг и исправление неудачных сборок гарантируют более быстрое время релиза.
- Как настроить и развернуть центр выпуска релиза программного обеспечения Jira Software. Узнайте, как сэкономить часы работы, позволив хабу (концентратору) релиза обеспечить четкое представление о ходе и статусе релиза.
- Полная автоматизация от сборки, написания кода к релизу. Оптимизируйте рабочий процесс, выпуская свою версию прямо из хаба релиза.
Вопросы & ответы
Наши ведущие Джейсон Вонг и Меган Кук выбрали свои любимые вопросы и ответы из этой презентации. Читайте дальше, чтобы узнать больше о том, как сделать успешный релиз без стресса.
Вопрос 1: Каковы 3 главных нетехнических фактора, которые делают использование центра выпуска релиза успешным?
Ответ 1:
(1) Отправьте с уверенностью: заинтересованные стороны внутри и вне команды смогут знать, что именно готово к релизу в любое время в течение цикла релиза.
(2) Экономьте время, быстрее принимайте решения: автоматически и мгновенно узнайте, какие функции выполнены и готовы к отправке, а какие имеют проблемы. Хаб релиза проверяет все ваши задачи в вашей версии, чтобы вам не приходилось вручную согласовывать задачи и код.
(3) Запись релизов: узнайте, что вышло (когда и какой релиз), просмотрев выпущенные версии и что в настоящее время планируется для каждого из следующих релизов, просмотрев не выпущенные версии.
Вопрос 2: Кто обычно управляет версиями релиза в Atlassian?
Ответ 2. У каждой команды в Atlassian свой особый подход, но в целом мы стараемся максимально автоматизировать процесс, чтобы выпустить исправления производственных багов или выпустить новую версию продукта с исправлением багов сможет любой разработчик в команде с минимальными накладными расходами.
Команды, как правило, имеют список того, что необходимо сделать, но мы стараемся максимально сократить это. Такие инструменты, как хаб релиза, помогают в этом процессе убедиться, что то, что мы планируем выпустить, имеет наивысшее качество, и нет никакого несоответствия между состояниями проблем программного обеспечения Jira Software и их фактической разработкой.
У некоторых из более крупных команд (например, Jira Software and Confluence) фактически есть специальная ротация для мастера багов/ менеджера релизов, который управляет всеми релизами.
Для больших и младших релизов, как правило, есть специальный человек, который следит за релизом, следит за тем, чтобы масштаб действия была управляемым, а вся работа, предшествующая релизу, управлялась рисками и временем. Это может контролироваться руководителем команды или менеджером по разработке, но мы стараемся, чтобы это вращалось среди членов команды, чтобы все знали процесс и понимали требования к выпуску релиза качественного программного обеспечения.
При планировании сроков руководители команд будут координировать свои действия с менеджерами по продуктам и маркетингу в отношении определения ожиданий того, когда будет готов релиз и нужно ли управлять масштабом или временем. Именно среди этих людей принимаются решения о том, какие функции будут выпущены в каких версиях.
Вопрос 3: Как вы получаете ответ на ветвь / фиксацию (commit) / запрос на извлечение / сборку / развертывание для связи с задачей?
Ответ 3:
- Ветвь - включите ключ задачи в название ветви.
- Фиксация - включите ключ задачи в сообщение о фиксации.
- Запрос на извлечение - включите ключ задачи в имя ветви источника, включенное сообщение о фиксации или заголовок запроса на извлечение.
- Сборка - включить ключ задачи во включенное сообщение фиксации.
- Развертывание - включите ключ задачи во включенное сообщение о фиксации.
Вопрос 4: Каков ваш опыт работы с конфликтами, возникающими при работе с одним и тем же кодом в изолированных ветках задач?
Ответ 4: Наш опыт показывает, что это редко проблема. Большинство задач имеют небольшое совпадение кода, но иногда возникают конфликты.
Обычно возникают 2 проблемы:
- Долгосрочные ветки функций изолированы от других текущих разработок.
- Массовые задачи рефакторинга, которые необходимо разделить до тех пор, пока они не будут завершены, протестированы и готовы к выпуску релиза.
В первом случае серьезным вариантом является разработка и частая интеграция, но при этом сами функции остаются за флагами функций, чтобы только наши собственные собачьи решения или несколько избранных клиентов увидели текущие изменения. Это обеспечивает постоянную интеграцию конфликтующего кода и сводит к минимуму вероятность конфликта, а также минимизирует риск и влияние при добавлении большой функции в основную ветку разработки.
Если это невозможно, и в случае больших рефакторингов, мы обеспечиваем, чтобы ветка разработки как можно чаще интегрировалась в ветку функции (путем объединения изменений в ветке базы / разработки с веткой функции). Это гарантирует, что вся текущая разработка будет завершена и протестирована на долгосрочную ветвь функций как можно чаще. Если возникают какие-либо конфликты слияния, гораздо проще найти людей, которые внесли изменения, чтобы помочь разрешить конфликты слияния или, по крайней мере, сохранить их масштаб действия минимальным, чтобы облегчить разрешение.
Лучшее решение состоит в том, чтобы разбить любую работу на куски, которые можно объединить в стабильную или ветвь разработки как можно чаще. Это минимизирует вероятность одновременного внесения изменений в одни и те же файлы в ветвях функций.
Вопрос 5: Какую стратегию вы рекомендуете для управления параллельными ветками для текущей разработки (функций), исправлений и их развертывания в различных средах (QA / Staging / Production)?
Ответ 5: У нас есть несколько стратегий ветвей, задокументированных на нашем сайте git. В частности, смотрите раздел сравнения рабочих процессов.
Более подробные сведения можно найти в некоторых предыдущих выступлениях, «Правильное получение Git» и рабочие процессы непрерывного развертывания более подробно рассматриваются в рабочих процессах Git для команд SaaS.
Короче говоря, есть 2 преобладающих рабочих процесса: рабочий процесс выпуска продукта для загружаемых продуктов и рабочий процесс SAAS для онлайн-сервисов (рабочие процессы Git для команд SaaS).
Для загружаемых продуктов большинство команд используют вариант рабочего процесса Gitflow, в котором мастер используется для текущей разработки, а каждый предыдущий вспомогательный выпуск релиза имеет свою собственную ветку, из которой создаются ветки с исправлениями ошибок и объединяются с ними, а когда необходимо, создается версия с исправлениями ошибок. В каждой ветке предыдущего выпуска релиза все изменения объединяются в последующих выпусках релизов и мастере, чтобы убедиться, что все исправления багов включены во все последующие версии.
Вопрос 6: Хорошо ли работает релиз-хаб с Kanban и частыми выпусками релизов?
Ответ 6: Да, это работает очень хорошо. Кнопка Release на доске Kanban может быть использована для создания новой версии, содержащей все задачи для этого выпуска релиза. После создания этой версии хаб релиза можно использовать для проверки любых предупреждений или для получения обзора версии.
Даже без доски Kanban вы можете в любое время создать версию и добавить к ней задачи, даже если эти задачи были решены. Затем можно использовать хаб релиза для проверки любых предупреждений, чтобы убедиться, что релиз готов.
Вопрос 7: Может ли релиз-хаб показывать информацию о задачах из нескольких проектов Jira Software или это релиз-хаб и исправление для конкретной версии?
Ответ 7: Хаб релиза- это подробный вид версии. Поскольку версии в настоящее время относятся к конкретному проекту, хаб релиза также относится к проекту.
Вопрос 8: Можете ли вы иметь предупреждения о хабе релиза автоматически заполнять в комнате Hipchat ?
Ответ 8: На сегодняшний день нет интеграции между предупреждениями о выпуске релиза и Hipchat, и в настоящее время у нас нет планов по их созданию. Мы думали о том, как релиз-хаб может улучшить командное сотрудничество с Hipchat, и хотели бы узнать больше от наших клиентов о том, как они могут использовать эту интеграцию или любые другие интеграции с другими нашими продуктами.
Вопрос 9: К чему подключена кнопка «Выпустить релиз»? Сценарий для развертывания на вашем рабочем сервере в качестве задания в Bamboo?
Ответ 9: Кнопка «Выпустить релиз» имеет несколько функций, связанных с ней:
- Он может установить дату релиза и изменить статус версии на «Выпущено». Если в версии есть какие-либо открытые задачи, это также даст возможность перенести эти задачи в другую версию. Это все доступно с или без интеграции Bamboo.
- Когда Bamboo интегрирован с Jira Software, можно использовать кнопку «Выпустить релиз», чтобы запустить новую сборку, которую можно настроить в Bamboo, чтобы предпринять шаги, необходимые для выпуска вашей версии (например, сценарий для развертывания в рабочей среде или создания нового артефакта).
- Кнопка «Выпустить релиз» также может быть использована для запуска ручной стадии сборки Bamboo, которая была запущена. Это позволяет вам иметь сборку, которая запускается автоматически, но имеет дополнительный этап, который запускается только вручную и фактически выполняет развертывание / выпуск релиза. (Этап будет эквивалентен всей сборке в Варианте № 2, но может использовать артефакты, которые сборка создает в своем исполнении.)
Вопрос 10: Планируете ли вы интегрировать релиз-хаб с Github / GitHub Enterprise?
Ответ 10: Хаб релиза уже работает с GitHub и GitHub Enterprise. Все, что вам нужно сделать, это подключить ваш экземпляр Jira Software к вашей учетной записи GitHub, используя учетные записи DVCS, которые находятся в меню администратора надстроек в Jira Software. Затем вы можете начать отслеживать ход выполнения любой из ваших версий, используя любую связанную информацию о разработке, включенную в хаб выпуска релиза.
По материалам Agile Coach "Stress free release"