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

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

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

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

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

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

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

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

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

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

Ответ 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 Workflow, в которой текущая разработка ведется в главной ветке, а каждой предыдущей промежуточной версии соответствует отдельная ветка, от которой отходят (и впоследствии с ней сливаются) ветки исправлений. При необходимости выполняется сборка релиза с исправлениями. Все изменения в каждой предыдущей ветке релиза включаются в последующие ветки релиза и главную ветку, чтобы ни одна из последующих версий не была выпущена без исправлений.

Вопрос 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