Руководство: Управление выпусками программного обеспечения для небольших групп

Формализация процесса управления релизами (если есть)

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

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

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

Введите контрольный список выпуска программного обеспечения

Возможно, вы знакомы с идеей контрольного списка для некоторых операций, согласно Манифесту контрольного списка , книге Атула Гаванде. Я считаю, что формальный процесс выпуска (как и многие другие задачи в мире разработки программного обеспечения) предоставляет разработчикам возможность реализовать этот протокол. Контрольный список процесса выпуска должен храниться в общем документе, предпочтительно в виде совместной вики или электронной таблицы на Google Диске.

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

Глядя на эту электронную таблицу, заинтересованные стороны могут принять решение о том, «ПРОДОЛЖАТЬ» или «НЕ ПРОДОЛЖАТЬ», в зависимости от результатов шагов. Например, если стресс-тест в тестовой среде пойдет не так, в зависимости от события руководитель проекта может принять решение об отмене производственной версии.

Предлагаемые шаги для использования в качестве основы

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

1. Создайте ветку релиза

Скорее всего, вы знакомы с концепцией Git Workflow или с идеей веток релиза, тема, которая была объяснена в предыдущем сообщении в блоге.

В идеале у вас должно быть как минимум три ветки:

• master : это должно отражать текущее состояние того, что находится в производственной среде. Каждая новая фиксация на мастере должна содержать только новый релиз.
• develop : эта ветка должна содержать завершенные (и протестированные) предстоящие функции. Обычно для каждой функции создают отдельную ветку, а затем объединяют ее для разработки , когда функция будет готова.
• release : ветки релиза представляют собой набор коммитов, готовых к отправке в производство, а также некоторые дополнительные исправления незначительных ошибок, связанные с релизом.

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

Чтобы создать новую ветку выпуска , из ветки разработки в вашем терминале git введите:

$ git checkout -b release/xyz

Удобно использовать соглашение об именах, такое как определенное выше, заменяя xyz номером версии major.minor.patch в соответствии с вашими потребностями (это политика, которую вы должны определить в своей команде и придерживаться ее).

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

2. Ударная версия

Следующим шагом будет изменение (изменение или увеличение) номера версии в ветке выпуска .

Вы должны открыть AndroidManifest.xml/package.json/pom.xml/ или любой другой файл, в котором хранится версия приложения в вашем проекте (YMMV), обновить номер версии, а затем зафиксировать изменения в текущей ветке выпуска .

Важно обновить номер версии по двум причинам.

Во-первых, вы можете отслеживать и сопоставлять функции, представленные в каждой версии, а во-вторых, вы будете знать, какую версию они используют, если им потребуется устранить неполадки или обратиться к вам за поддержкой. Если вы создаете мобильное приложение, номер версии, которую вы обновляете на этом шаге, обычно отображается на стороне пользователя, в разделе « О программе» или в Google Play или Apple App Store . Этот шаг также является хорошей возможностью для обновления в зависимости от среды. -файлы конфигурации (хотя я бы предложил хранить их в отдельном репозитории), например, сделать так, чтобы ответвление указывало на производственную базу данных, или любые другие настройки, необходимые в процессе сборки.

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

$ git push -u origin release/xyz

3а. Объединить ветку релиза с мастером и пометить его

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

 $ git checkout master $ git merge --no-ff release/xyz $ git push

Флаг --no-ff является необязательным, однако его использование рекомендуется для принудительного создания нового объекта фиксации, даже если слияние может быть выполнено с использованием метода быстрой перемотки вперед.

Затем пришло время пометить релиз на главной ветке:

$ git tag -a xyz -m 'description of new version, features or fixes included'

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

3б. Используйте запрос на вытягивание для слияния ветки релиза

Другая часто используемая альтернатива — использовать запрос на вытягивание для слияния ветки релиза с веткой master .

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

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

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

4. Разверните мастер в производственной среде

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

На этом этапе вы готовы развернуть изменения и воплотить их в жизнь. Идите вперед и разверните основную ветку. Этот шаг будет зависеть от используемого вами стека инфраструктуры. Это может включать подключение к вашему экземпляру Amazon EC2 для загрузки вашего приложения, отправку на удаленный сервер Heroku, подключение через ssh к вашему VPS для копирования новой версии или любой другой процесс.

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

5. Слияние обратно в ветку разработки и удаления релиза

Теперь, когда релиз почти завершен, вам нужно объединить ветвь релиза в ветку разработки , обновить номер версии на последней и перенести все исправления ошибок, сделанные в основную ветку разработки:

 $ git checkout develop $ git merge release/xyz

Теперь пришло время удалить ветку релиза :

$ git branch -d release/xyz

6. Генерация журнала изменений

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

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

 <app's name or component released> <version xyz> | <date> <developer's name in charge of release> | <developer's email> Features: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Bugs fixed: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Enhancements: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Optional: known issues plus other release notes.

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

• Генератор журнала изменений Github от Skywinder,
• ReadmeGen от fojuth
• github-изменения, автор lalitkapoor

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

7. Общайтесь с заинтересованными сторонами

Здесь вы обычно делаете некоторые из следующих действий:

• Сообщите команде с помощью внутреннего инструмента обмена сообщениями (например, Slack), что новый выпуск завершен. Я рекомендую создать новый канал (например , #releases ) с единственной целью — сообщать о событиях, связанных с выпуском. В канал Slack легко добавить хуки, чтобы опубликовать сообщение после того, как действие было выполнено.
• Кроме того, отправьте электронное письмо заинтересованным сторонам со ссылкой на журнал изменений или прикрепленный файл журнала изменений.
• Напишите сообщение в блоге (если у вас есть блог для вашего приложения или продукта) или твит.

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

8. Уход за трекером проблем

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

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

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

Об автоматизации процесса выпуска

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

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

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

Использование лучших практик

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

Найдите наиболее подходящий день для проведения релиза

Я обычно выпускаю приложения, над которыми работаю, по четвергам, между полуднем и закрытием рабочего дня.

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

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

Сделайте резервную копию вашей базы данных перед новой версией

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

Поэтапное развертывание

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

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

В консоли разработчика Android есть хороший инструмент, который реализует поэтапное развертывание ваших приложений Android.

Непрерывная интеграция

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

Мартин Фаулер — большой сторонник непрерывной интеграции. Он описывает огромное количество преимуществ, которые могут быть добавлены к вашему процессу выпуска при использовании этой практики. Это обширная тема, о ней написано много книг и сообщений в блогах, и я упоминаю ее здесь, потому что считаю, что это придаст вам гораздо больше уверенности в ваших действиях. Среди многих преимуществ использования CI вы найдете: снижение риска, улучшенную видимость, чтобы знать, что работает, а что нет, более раннее обнаружение ошибок, повышенную частоту развертываний и многое другое.

Отправной точкой внедрения CI является настройка «сервера непрерывной интеграции». некоторые хорошие инструменты, которые стоит попробовать: CruiseControl, Bamboo, Jenkins и Travis.

Exitlude: Все получится

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

Exitlude, Убийцы

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

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

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

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