Как я могу разместить APK-файл Android для каждого pull-запроса, чтобы QA мог проверить их перед слиянием? - PullRequest
0 голосов
/ 26 сентября 2018

Чтобы улучшить наш рабочий процесс QA, мы хотим автоматически создавать APK-файл для каждого pull-запроса на Github, чтобы мы могли проверить его ПЕРЕД тем, как ветвь будет объединена.Мы уже выяснили, как создать файл, но теперь нам интересно, как интегрировать это в наш рабочий процесс.

Кажется, что большинство доступных бета-программ (например, Crashlytics Beta, Google Play) в основном фокусируются на создании одной бетыверсия незадолго до релиза, но не разрешать параллельное размещение нескольких APK.

Вот пример идеального рабочего процесса:

  1. Разработчик заканчивает кодирование и создает запрос на извлечение
  2. Выполнение тестов
  3. Если тесты успешны, APK автоматически создается и загружается куда-то (это та часть, которую мы пытаемся выяснить)
  4. QA рассматривает pull-запрос и должен иметь возможность легко загрузить правильный APK на свое тестирующее устройство
  5. Если во время QA нет проблем, pull-запрос объединяется
  6. Файл APK автоматически удаляется

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

Ответы [ 3 ]

0 голосов
/ 04 октября 2018

Существует множество способов достичь этого.Но, на мой взгляд, лучший способ - создать следующий этап, который будет выдавать apk как artefact , и позже ваша команда QA сможет загрузить apk на устройство и протестировать его.Как пишет anaxad , вы также можете отправить файл apk, используя почту и список рассылки.Но такое решение будет более сложным, потому что вам нужно создать задачу (например, с помощью docker), которая будет отправлять почту с помощью apk.

0 голосов
/ 04 октября 2018

На самом деле Crashlytics позволяет иметь несколько версий APK.Каждая версия может иметь собственную строку версии и, конечно, заметки о выпуске , чтобы помочь QA найти правильный APK.

Точка 3 из вопроса может быть описана таким образом: CI настроен для загрузки сборкик Crashlytics.Это может быть достигнуто с помощью задачи gradle:

gradle assembleRelease crashlyticsUploadDistributionRelease

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

build.gradle:

//example function for change log 
def getLastGitCommitMessage() {
  try {
    "git log -1 --pretty=%B".execute().text.trim()
  } catch (e) {
    'Undefined message.'
  }
}

android {
  buildTypes {
    ...
    pullrequest { 
      //invitation
      ext.betaDistributionGroupAliases = "QA, devs"
      // notification
      ext.betaDistributionNotifications = true
      // last commit message as release notes
      ext.betaDistributionReleaseNotes = getLastGitCommitMessage()
    }
  }
}

В этом случае команда построения и загрузки будет такой:

gradle assemblePullrequest crashlyticsUploadDistributionPullrequest
0 голосов
/ 04 октября 2018

Сделайте вашу систему сервером.

После этого во время генерации APK укажите путь к вашему серверу.Если вам это нравится, то каждый раз, когда ваш апк будет обновляться, вам нужно использовать одну переменную?Который будет определять ваш apk для развертывания на локальном сервере или нет.

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

Следуйте за этим вопросом.

Некоторый демонстрационный код.

debug {
   applicationVariants.all { variant ->
       variant.outputs.each { output ->
           def apk = output.outputFile;
           def newName;
           newName = apk.name.replace("-" + variant.buildType.name, "")
                   .replace(project.name, name);
           newName = newName.replace("-", "-" + version + "-" + milestone +
                   "-" + build + "-");
           output.outputFile = new File(apk.parentFile, newName);
       }
   }
}
...