Comments 20
Спасибо) Что-то всё очень сложно)
1. Версию выставлять через гит не очень практично, так как несколько разработчиков со своими фиче ветками всегда будут иметь разные версии приложения, то есть в TestFlight/Firebase версии будут идти хаотично, а не инкрементально.
2. В скрипте не выставили "For install builds only", зачем гонять этот скрипт на каждый билд проекта локально и тратить несколько секунд впустую.
3. Инрементить версию нужно не только проекта, но и его тестов и его эктеншенов. Поэтому мы используем fastlane - одной строкой кода он понимает что и где нужно заикрементить.
Наоборот - версию выставлять через гит практично. Но для этого должна быть корректно выстроена работа с гит. Мы выкладывали в TestFlight/тестовый Google Play версии только с ветки "rc" - наверно напишу отдельную статью про git, GitHub, GitLab - у начинающих часто с ними проблемы... Это позволит версиям быть последовательно, а не хаотично, и всегда у сборки будет новый номер.
Да, можно поставить, но лично для меня это не принципиально. Скорость сборки проектов актуальна для больших проектов, когда важна каждая миллисекунда. Для пет-проектов и небольших проектов, считаю не тем, на что нужно обращать внимание.
Про тесты согласен. Пет-проекты обычно пишутся без тестов. И это также более актуально для больших проектов. С 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 )
релизный бот есть в другой команде через слак, но наша команда посмотрела на это и решила, что чрезмерные усложнения того не стоят на данный момент.
Вроде уже все на kts начинают мигрировать, а в нем вообще можно указать как константу версию в toml файле. Я конечно не пробовал версию приложения та прописывать, но не думаю что будут проблемы, надо этим заняться кстати....
Про Kotlin + Compose + kts и SwiftUI, планировал следующую статью в зависимости от того, как эта зайдёт. Спасибо за совет про toml-файл - когда буду готовить следующую статью, то посмотрю на этот файл.
Ну если раньше с этим особо не работали, то как пример смотрите now in Android, помню были у меня проблемы пока у них не передрал несколько моментов.
Благодарю, изучу этот проект позже https://github.com/android/nowinandroid
Зарегистрировался только ради этого комментария.
Я, конечно, в мобильной разработке ламер, но в xamarin (c#) все проще... Просто вывести номер сборки либы и усе (ну, само собой настроить автоувеличение номера сборки)
Как показать номер версии на экране загру…