Путь к релизам без стресса

Это видео гарантированно понизит уровень напряжения при подготовке вашего следующего крутого релиза.

Laura Daly Laura Daly
Просмотр тем

Лучшим мерилом успеха любой agile-команды является скорость поставки рабочей версии ПО клиентам. Даже опытным командам разработчиков становится не по себе, когда приходит пора проверять, соответствуют ли результаты выполнения задач тем требованиям, что к ним предъявлялись. И выясняется, что где-то была пропущена проверка кода, где-то не выполнили слияние, в сборках после слияния возникают ошибки… Знакомо?

Из этой презентации вы узнаете следующее.

  • Рекомендации по написанию кода, благодаря которым можно развить навык поставки качественного продукта. Почему без проверок кода нельзя создать качественный продукт и как отслеживание и исправление ошибок в сборках гарантированно поможет выпустить новую версию продукта быстрее.
  • Способы настройки и оптимизации центра управления релизами Jira Software. Как сделать так, чтобы в центре управления релизами можно было получать четкое представление о ходе работы и статусе релиза, и как это поможет избавиться от лишней работы.
  • Ценность внедрения автоматизации на всех этапах от сборки, написания кода до релиза. Выпускайте новую версию прямо из центра управления релизами и оптимизируйте рабочий процесс.

Смотрите и учитесь

Вопросы и ответы

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

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

Ответ 1. (1) Уверенная поставка продукта. Заинтересованные лица в команде и за ее пределами смогут в любой момент цикла релиза узнать, что именно готово к выпуску.

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

(3) Учет релизов. Нужны списки выпущенных и невыпущенных версий. Первый — чтобы знать, что вышло (когда и в какой версии), а второй — чтобы знать, что планируется в данный момент для каждой из будущих версий.

Вопрос 2. Кто обычно управляет версиями релизов в Atlassian?

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

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

В некоторых командах покрупнее (например, занимающихся Jira Software и Confluence), заведено, чтобы всеми релизами управляли поочередно то главный специалист по багам, то менеджер по релизам.

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

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

Вопрос 3. Каким образом вы устанавливаете связь между веткой/коммитом/запросом pull/сборкой/развертыванием и задачей?

Ответ 3.

1. Ветка — ключ задачи добавляется в название ветки.
2. Коммит — ключ задачи указывается в комментарии к коммиту.
3. Запрос pull — ключ задачи указывается в названии исходной ветки, добавленном комментарии к коммиту или заголовке запроса pull.
4. Сборка — ключ задачи указывается в добавленном комментарии к коммиту.
5. Развертывание — ключ задачи указывается в добавленном комментарии к коммиту.

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

Ответ 4. Мы редко сталкиваемся с подобной проблемой. Большинство задач предполагает работу над разными фрагментами кода, но иногда конфликты все же возникают.

Все потенциальные проблемы можно поделить на два типа.

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

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

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

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

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

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

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

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

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

Вопрос 6. Удобно ли использовать центр управления релизами при использовании kanban и частой поставке релизов?

Ответ 6. Да, вполне. Кнопка Release (Выпустить) на доске kanban предназначена для создания новой версии, в которую включаются все задачи, запланированные для этого релиза. Когда версия создается в центре управления релизами, вы можете просмотреть предупреждения (при наличии) или получить представление о версии.

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

Вопрос 7. Можно ли включить в центре управления релизами отображение информации о задачах из нескольких проектов Jira Software или в нем всегда отображается информация только по какому-то конкретному проекту и версии исправления?

Ответ 7. В центре управления релизами приводится подробная информация о версии. В настоящее время версии соотносятся с одним определенным проектом, поэтому центр управления релизами также соотносится с одним определенным проектом.

Вопрос 8. Можно ли настроить центр управления релизами так, чтобы предупреждения автоматически передавались в комнату Hipchat?

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

Вопрос 9. Для чего нужна кнопка Release (Выпустить)? Она выполняет сценарий для развертывания релиза на рабочем сервере в виде задачи в Bamboo?

Ответ 9. Кнопка Release (Выпустить) выполняет несколько функций.

  • Нажав ее, можно задать дату релиза и изменить статус версии на Released (Выпущено). Если какие-то задачи в этой версии окажутся незавершенными, вам предложат переместить их в другую версию. Для этого интеграция Bamboo не обязательна.
  • При наличии интеграции Bamboo с Jira Software с помощью кнопки Release можно запустить новую сборку, настраиваемую в Bamboo, после чего будут предприняты действия для выпуска версии (например, выполнен сценарий для развертывания версии в рабочей среде или создания нового результата сборки).
  • С помощью кнопки Release можно инициировать этап ручной работы для уже запущенной сборки Bamboo. Таким образом, можно настроить автоматическое выполнение сборки с необязательным этапом, который можно запустить только вручную. На нем осуществляется собственно развертывание/выпуск. Этот этап практически не отличается от сборки, описанной в варианте 2, за исключением того, что на нем можно использовать результаты, полученные в ходе создания сборки.

Вопрос 10. Планируете ли вы интеграцию центра управления с GitHub/GitHub Enterprise?

Ответ 10. Центр управления релизами уже можно использовать с GitHub и GitHub Enterprise. Для этого нужно подключить экземпляр Jira Software к аккаунту GitHub, нажав DVCS Accounts (Аккаунты распределенных систем управления версиями) в меню администратора аддонов в Jira Software. После этого можно начать отслеживать состояние любой версии, так как вся соответствующая информация о разработке будет приведена в центре управления релизами.

продолжение темы
Qa at speed