Команда курса тщательно анализирует рынок и учитывает запросы и уровень аудитории. Так как курс не предполагает наличия знаний о программировании на старте и многие студенты впервые сталкиваются с кодом, для создания первого приложения были выбраны сториборды. Это позволяет быстро получить красивое и функционирующее приложение уже за первый спринт.
Также стоит учесть, что переход компаний на новые инструменты и подходы занимает время, и не все команды используют те подходы, которые вам кажутся верными. Умение работать со сторибордами и XIB'ами по-прежнему актуально, так как многие все еще используют их для разработки или поддержки существующих проектов.
Обучение студентов работе со сторибордами помогает им быть готовыми к разнообразным рабочим ситуациям. Также наш курс содержит модули, где студенты верстают кодом, а также используют гибридный подход, что увеличивает их конкурентоспособность на рынке труда.
В то же время, курс продолжает развиваться, и методисты стремятся включать в него актуальные технологии и подходы.
Спасибо, за интерес к статье! Действительно стоило упомянуть про передачу данных между контроллерами, да и просто про индикаторы в сторибордах. Материал в этом смысле – взгляд со стороны код-ревьювер , на этапе ревью такие ошибки студент уже победил (иногда не без помощи Наставников курса).
Быть может, если материал будет полезным, мы с командой соберем еще кейсов :)
хранить ключи для подписи в репозитории это совсем не хорошо по моему скромному мнению.
Полностью с вами соглашусь — совсем не хорошо, и так у нас было на Android проектах до того, как переехали на этот процесс. Но даже это не так страшно, так как у нас развернут локальный Gitlab.
Выше в статье приведён пример Fastfile, где, к примеру, вызывается match — экшен, который подписью и занимается. Ключи живут в отдельном закрытом репозитории, куда доступ только у технической учетки и ребят, которые настраивали процесс. Как оно работает описано в codesigning guide . Аналогично сделали для ключей Android.
у вас в компании отсутсвует ReleaseEngineer/DevOps/Сисадмин и сборкой занимаються тестировщики
Да. Сборкой мобильных приложений занимаются тестировщики. Это не сложно, тем более когда мобильщики помогают.
Из статьи совсем не понятно, где преимущество перед сборкой отдельными job'ами с хранением результата сборок
Не было цели показывать преимущество. Что именно включать в сборку, каким порядком запускать и каким образом — решать вам.
В каком шаге pipeline у вас тестирование на соответствие гайдланам Google Play и AppStore?
Что конкретно имеете в виду? Раскройте, я не поняла.
Ручное тестирование проводим после успешной загрузки альфа-сборки.
Автоматизации тестирования мобильных приложений к примеру с популярным Appium тоже нет?
Есть.
Сразу деплоите в магазин и без подписей?
Сначала подписываем, потом отправляем в альфу google play market и TestFlight. А у вас как?
Можете рассказать подробнее, а то складывается ощущение, что сделано не для удобства, а как дань моде?
Могу рассказать поподробнее.
В нашей компании процессом автоматизации разработки исторически начали заниматься тестировщики. Тестировщик тогда в компании был единственным, в свободное время погружался в ci/cd и понемногу внедрял каждый из шагов.
Так что поначалу наверное это была дань моде и желание достичь экономии в тестировании и разработке. В цифрах никто экономию не считал, но задачи свои процесс решает — разработчики не выливают приложения вручную, доступа до ключей подписи у них нет, запуск автотестов происходит до загрузки архива в сторы, тестировщики всегда в курсе, когда выходит новая сборка на тест (у нас нет необходимости вводить расписания релизов).
Information
Rating
Does not participate
Location
Лимассол, Government controlled area, Кипр
Date of birth
Registered
Activity
Specialization
Разработчик мобильных приложений, Инженер по автоматизации тестирования
Спасибо за текст! Веру в хороших дизайнеров восстановила 🥹 это так хорошо, что расплакалась
Спасибо за такой подробный обзор 🫶🏻 не задача, а мечта!
Спасибо за материал!
Привет! Спасибо за комментарий.
Команда курса тщательно анализирует рынок и учитывает запросы и уровень аудитории. Так как курс не предполагает наличия знаний о программировании на старте и многие студенты впервые сталкиваются с кодом, для создания первого приложения были выбраны сториборды. Это позволяет быстро получить красивое и функционирующее приложение уже за первый спринт.
Также стоит учесть, что переход компаний на новые инструменты и подходы занимает время, и не все команды используют те подходы, которые вам кажутся верными. Умение работать со сторибордами и XIB'ами по-прежнему актуально, так как многие все еще используют их для разработки или поддержки существующих проектов.
Обучение студентов работе со сторибордами помогает им быть готовыми к разнообразным рабочим ситуациям. Также наш курс содержит модули, где студенты верстают кодом, а также используют гибридный подход, что увеличивает их конкурентоспособность на рынке труда.
В то же время, курс продолжает развиваться, и методисты стремятся включать в него актуальные технологии и подходы.
Спасибо, за интерес к статье! Действительно стоило упомянуть про передачу данных между контроллерами, да и просто про индикаторы в сторибордах. Материал в этом смысле – взгляд со стороны код-ревьювер , на этапе ревью такие ошибки студент уже победил (иногда не без помощи Наставников курса).
Быть может, если материал будет полезным, мы с командой соберем еще кейсов :)
Отдельных нет, но мы к этому идём.
Полностью с вами соглашусь — совсем не хорошо, и так у нас было на Android проектах до того, как переехали на этот процесс. Но даже это не так страшно, так как у нас развернут локальный Gitlab.
Выше в статье приведён пример Fastfile, где, к примеру, вызывается match — экшен, который подписью и занимается. Ключи живут в отдельном закрытом репозитории, куда доступ только у технической учетки и ребят, которые настраивали процесс. Как оно работает описано в codesigning guide . Аналогично сделали для ключей Android.
:) а как у вас?
Да. Сборкой мобильных приложений занимаются тестировщики. Это не сложно, тем более когда мобильщики помогают.
Не было цели показывать преимущество. Что именно включать в сборку, каким порядком запускать и каким образом — решать вам.
Что конкретно имеете в виду? Раскройте, я не поняла.
Ручное тестирование проводим после успешной загрузки альфа-сборки.
Есть.
Сначала подписываем, потом отправляем в альфу google play market и TestFlight. А у вас как?
Могу рассказать поподробнее.
В нашей компании процессом автоматизации разработки исторически начали заниматься тестировщики. Тестировщик тогда в компании был единственным, в свободное время погружался в ci/cd и понемногу внедрял каждый из шагов.
Так что поначалу наверное это была дань моде и желание достичь экономии в тестировании и разработке. В цифрах никто экономию не считал, но задачи свои процесс решает — разработчики не выливают приложения вручную, доступа до ключей подписи у них нет, запуск автотестов происходит до загрузки архива в сторы, тестировщики всегда в курсе, когда выходит новая сборка на тест (у нас нет необходимости вводить расписания релизов).