Pull to refresh

Comments 20

Спасибо) Что-то всё очень сложно)
1. Версию выставлять через гит не очень практично, так как несколько разработчиков со своими фиче ветками всегда будут иметь разные версии приложения, то есть в TestFlight/Firebase версии будут идти хаотично, а не инкрементально.
2. В скрипте не выставили "For install builds only", зачем гонять этот скрипт на каждый билд проекта локально и тратить несколько секунд впустую.
3. Инрементить версию нужно не только проекта, но и его тестов и его эктеншенов. Поэтому мы используем fastlane - одной строкой кода он понимает что и где нужно заикрементить.

  1. Наоборот - версию выставлять через гит практично. Но для этого должна быть корректно выстроена работа с гит. Мы выкладывали в TestFlight/тестовый Google Play версии только с ветки "rc" - наверно напишу отдельную статью про git, GitHub, GitLab - у начинающих часто с ними проблемы... Это позволит версиям быть последовательно, а не хаотично, и всегда у сборки будет новый номер.

  2. Да, можно поставить, но лично для меня это не принципиально. Скорость сборки проектов актуальна для больших проектов, когда важна каждая миллисекунда. Для пет-проектов и небольших проектов, считаю не тем, на что нужно обращать внимание.

  3. Про тесты согласен. Пет-проекты обычно пишутся без тестов. И это также более актуально для больших проектов. С fastline к сожалению не довелось работать.

Спасибо)

Мы выкладывали в TestFlight/тестовы Google Play версии только с ветки "rc"

не совсем понял как QA тестирует сборки ? Я прямо сейчас делаю новую фичу в своей фиче ветке (коллега делает другую в своей). Я сделал 5 комимитов и хочу чтобы QA глянул, что всё более менее работает, для это я просто пушу сборку в Firebase из своей ветки через github/gitlab actions. Коллега через час только накоммитил 2 комита и тоже говорит QA проверить сборку, для это запускает Firebase сборку из своей ветки. Как я понимаю у нас разъедутся версии, моя будет более свежая, так как имеет больше коммитов, но будет идти до версии коллеги, хотя у него версия ниже.

Для фиче-веток можно отдельные теги вводить ;)

Если вы делаете сборки с разных веток, то это не значит, что одна версия более свежая. Это значит что у вас 2 совершенно разные версии. Соответственно для тестирования нужны совершенно разные номера версий. Как вариант, после номер версии ещё выводить хеш-код коммита, его не сложно добавить. Но лично мне так не нравится, выглядит "не красиво" - хотя в сторах видел много приложений, у которых в номере версии указывается хеш-код коммита.

Хотя наверное согласен с вами, гит тоже хороший подход. Просто для нас это оказалось лишнее усложнение и мы ушли от этого довольно давно, и сейчас просто на каждый билд происходит инкремент на CI во время сборки в FB, номер берется из CI, где каждый запуск всегда больше предыдущего, поэтому номера всегда идут последовательно.

Да, потому что у вас видимо не маленький проект. А я пишу как раз для начинаюших, у кого ещё нет CI/CD и прочего)

Тогда извиняюсь, что-то пропустил момент про начинающих) Всё равно большое спасибо, было интересно почитать)

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

Надеюсь статья получилась не слишком сложной для начинающих.

Мы сборки под Firebase не делали. У нас у всех проектов свой бекенд и публикуем сразу в AppStore/GooglePlay. Тестировщики тестируют на своих девайсах или эмуляторах.

Для TestFlight у нас кстати отдельная версионность через release bot-а, он просто дергает fastlane.incrementMajorVersion(), то есть повышает с x.y.z до x+1.y.z, можно конечно поднимать и minor/patch только. Тут с вами согласен, release у нас тоже как у вас RC получатся, только инкрементируем через файтлэйн)

Круто. Тоже планировал бота написать, но пока руки до этого не дошли.

Тут я немного слукавил, бот не в прямом смысле, а отдельная релиз джоба на CI )

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

Я сейчас параллельно учусь в школе 21 (от Сбера) и как раз один из текущих проектов, это проект CI/CD, где бонусным заданием как раз надо создать CI/CD бота. Так что у меня скоро появится такой бот и прикручу его к своим проектам.

Прикольно ) Удачи вам с проектом и возможно ждем статью про бота)

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

Про Kotlin + Compose + kts и SwiftUI, планировал следующую статью в зависимости от того, как эта зайдёт. Спасибо за совет про toml-файл - когда буду готовить следующую статью, то посмотрю на этот файл.

Ну если раньше с этим особо не работали, то как пример смотрите now in Android, помню были у меня проблемы пока у них не передрал несколько моментов.

Зарегистрировался только ради этого комментария.

Я, конечно, в мобильной разработке ламер, но в xamarin (c#) все проще... Просто вывести номер сборки либы и усе (ну, само собой настроить автоувеличение номера сборки)

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

Sign up to leave a comment.

Articles