Это можно развернуть? Какой номер следующей версии? Как автоматически создавать примечания к выпуску?

Альфа. Бета. Производство. Дважды - iOS и Android. Плюс Codepush. Это могут быть версии вашего приложения React Native. Я хочу поделиться с вами, ребята, как мы развертываем все автоматически, используя GIT flow и Обычные коммиты. Вдохновлен семантикой-релизом.

Когда мы выпустим эти версии?

  • Альфа-версия. Каждую ночь. Для внутреннего тестирования. На основе ветки разработки.
  • Бета-версия. Активируется нажатием на бета-ветку.
  • Производственная версия. Загружено в Apple Store и Google Play. Активируется нажатием на главную ветку.

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

Как выглядит наша версия?

Мы используем семверь. Крупный. Незначительный. Пластырь. Это могло быть 1.3.4. Когда мы выпускаем версию, мы создаем уникальный тег в GIT. Например, android/production/1.3.4/7683 или ios/alpha/1.5.0/8754.

Почему мы не храним версию в package.json 🚫

Если бы мы сохранили версию вpackage.json файле (как это делают многие), мы не смогли бы автоматически увеличить версию. Поскольку CircleCI изменяет его, CircleCI придется отправить изменение обратно в репозиторий. Это вызовет новый релиз. Потому что каждое нажатие вызывает релиз. Не говоря уже о том, сколько Bump version коммитов у нас будет в истории GIT.

Как это работает с производственной версией?

В этом примере мы нажимаем на основную ветку и ожидаем, что Android и приложение iOS будут загружены в магазины. Мы смоделируем сбой сборки iOS.

Нажмите на Мастера # 1

Основная ветвь была «быстро перенаправлена» (объединена) от фиксации A к фиксации D. Последняя версия для обоих находится на фиксации A (см. Теги).

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

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

Android
Наш скрипт (Android Analysis) находит последний тег для android/production (просто с помощью инструмента командной строки git). Тег находится в фиксации A. Он получает последнюю версию путем синтаксического анализа имени тега. Это 1.3.4. Затем, анализируя коммиты, он узнает номер следующей версии.

  • Зафиксируйте B. Функция (feat ключевое слово). Это означает, что мы должны увеличить младшее число 1.4.0. Если вы увеличиваете младший номер, вы должны сбросить номер патча (см. Документацию semver).
  • Зафиксируйте C. Исправить (fix ключевое слово). Увеличивает номер патча 1.4.1.
  • Зафиксируйте D. Это просто обновление документации (ключевое слово doc). Номер версии не изменился.

Вот и все. Получили следующий номер версии. Никаких ручных действий! Следующая версия 1.4.1 старше текущей версии 1.3.4. Выпуск продолжается. Решено автоматически. Мы можем передать номер Fastlane и построить релиз. Когда сборка готова, она продолжает развертывание версии в магазине. После развертывания он создает новый тег для HEAD (фиксация D) и генерирует примечания к выпуску. Android готов!

iOS
Наш скрипт (этап анализа iOS) находит последний тег для ios/production. Это продолжается так же, как и в части Android. Он получает номер следующей версии 1.4.1 и продолжает этапы сборки и развертывания.

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

Что нам теперь делать? Android уже выпущен. Если мы что-то изменим и перейдем к мастеру, он снова выпустит Android. Мы могли бы дождаться CircleCI и отменить задание вручную. 🤔 К счастью, в этом нет необходимости. Посмотрим почему.

Нажмите на мастер # 2

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

Android
Со времени выпуска последней производственной версии Android (1.4.1) сделана только одна фиксация. И это то, что было изменено с момента последней версии. Потому что Android был успешно выпущен (Push to master # 1). Новая фиксация E не увеличивает номер версии. Потому что это просто обновление строительных инструментов. Рабочий процесс для Android заканчивается этапом анализа Android.

iOS
Ситуация будет такая же, как и при отправке на мастер №1. Остался только один коммит. Но эта фиксация не меняет версию. Последний выпуск версии iOS 1.3.4 при фиксации A. Он анализирует коммиты и выясняет, что новая версия будет 1.4.1. Он продолжает сборку, развертывание и на этот раз будет успешным. 🎉

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

Примечания к выпуску

Он даже может создавать примечания к выпуску, анализируя коммиты. Это наша история GIT после перехода к мастеру №2.

Примечания к выпуску для iOS включают фиксацию B как новую функцию и commitC как исправление (патч). Он пропустит фиксацию C и зафиксирует D, потому что они ничего не меняют для пользователей.

Подходит для Codepush? 👍

Скорее всего, вы уже слышали о codepush. Инструмент, который дает нам возможность выпустить только часть javascript. Пользователи будут получать обновления немедленно. Хорошая идея. Но в реальном мире, когда мы готовили релиз, всегда было трудно понять, сможем ли мы выпустить только javascript или нет. Всегда были сомнения. И что-то еще нам нужно было делать для каждого релиза.

Теперь у нас есть этот инструмент выпуска. Он анализирует коммиты для нас. Нашим разработчикам просто нужно отметить коммит, над которым они работают. Допустим, они напишут ключевое слово в сообщении фиксации. Например [codepush-ok].

Дальше делает точно так же, как и при загрузке в магазины. Находит последний тег выпуска codepush. Анализируйте коммиты с этого выпуска. Если есть одна фиксация, которая не помечена как [codepush-ok], она отменит развертывание. Если все коммиты отмечены [codepush-ok], мы можем выпустить версию кода. Разве это не легко?

Как вы выпускаете приложения React Native?

Буду рад, если вы оставите комментарий и расскажете свой секрет релиза. Как вы справляетесь с версией приложения React Native? Вы все еще делаете это вручную? Вы используете package.json?

📝 Прочтите этот рассказ позже в Журнале.

🗞 Просыпайтесь каждое воскресное утро и слышите самые интересные истории, мнения и новости недели, ожидающие в вашем почтовом ящике: Получите примечательный информационный бюллетень›