Internal Testing Track sa Google Play: esensya at pag-setup ng track

Ano ang Internal Testing Track?

Internal Testing Track — unang antas ng pagsubok sa Google Play Console, dinisenyo para sa pamamahagi ng mga build sa loob ng development team. Ang pangunahing layunin ay mabilis na pagsusuri ng functionality, pagsubok ng mga integrasyon at pagtuklas ng mga kritikal na error bago palawakin ang audience sa Closed o Open tracks.

Hindi tulad ng ibang Google Play tracks, ang Internal Testing ay hindi nangangailangan ng beripikasyon ng Google bago ang aktivasyon. Ang build ay nagiging available sa mga tester sa loob ng ilang minuto pagkatapos i-upload sa console. Ginagawa nitong ideal ang track para sa daily builds at awtomatikong paghahatid mula sa CI/CD pipeline.

Ayon sa dokumentasyon ng Google Play Console (2024), ang Internal Testing Track ay sumusuporta sa dalawang paraan ng pamamahagi: listahan ng email (hanggang 100 kalahok) at Google Groups (walang limitasyon sa bilang). Ang mga grupo ay angkop para sa malalaking koponan kung saan madalas magbago ang mga kalahok, at ang email para sa nakapirming komposisyon ng mga developer.

Kailan pumili ng Internal Testing Track

Ang Internal track ay pinipili sa mga unang yugto ng pag-develop, kapag ang app ay hindi pa stable at ang mga API ay maaaring magbago. Ang CI/CD pipeline ay nag-a-upload ng bawat bagong build sa Internal track at ang koponan ay agad na nakakatanggap ng sariwang bersyon. Ang mga error at crash log ay kinokolekta sa pamamagitan ng Play Console bago makarating ang build sa mga panlabas na tester o user.

Para sa mga bagong account ng developer, ang Internal Testing Track ay nagsisilbing unang yugto ng paghahanda para sa publikasyon. Hindi sinusuri ng Google ang mga build sa yugtong ito, na nagpapahintulot sa koponan na mismo tiyakin ang kalidad ng produkto bago isumite para sa pagsusuri.

Paano i-setup ang Internal Testing Track sa Google Play Console

Ang pag-setup ng Internal Testing Track ay ginagawa sa Google Play Console sa seksyong Release > Testing > Internal Testing. Kasama sa proseso ang paggawa ng track, pag-upload ng unang build at pagdaragdag ng mga tester.

Para gumawa ng track, pumunta sa seksyong Internal Testing at i-click ang Create track. Pagkatapos gawin ang track, mag-aalok ang system na i-upload ang unang build sa format na AAB (Android App Bundle). Inirerekomenda ng Google ang AAB para sa lahat ng uri ng pagsubok dahil ino-optimize ng format ang laki ng app para sa arkitektura ng device.

Pagkatapos i-upload ang build, ang access sa track ay bubuksan sa pamamagitan ng pagdaragdag ng mga tester. Kung walang kahit isang tester, ang track ay hindi itinuturing na aktibo. Ipinapakita ng Google Play Console ang status ng track, listahan ng mga na-upload na build at estatistika ng pag-install para sa bawat kalahok.

// build.gradle - awtomatikong pag-upload sa Internal Testing Track
android {
    def versionCode = System.env.GIT_COMMIT_COUNT ?: "1"
    def versionName = "1.0." + versionCode

    defaultConfig {
        versionCode versionCode.toInteger()
        versionName versionName
    }
}

// I-deploy sa pamamagitan ng Gradle Play Publisher plugin
plugins {
    id 'com.github.triplet.play' version '3.9.0'
}

play {
    track = "internal"
    serviceAccountCredentials = file("play-account.json")
}

Pagdaragdag ng mga tester sa Internal track

Ang pagdaragdag ng mga tester sa Internal Testing Track ay posible sa dalawang paraan: sa pamamagitan ng email at sa pamamagitan ng Google Groups. Ang listahan ng email ay angkop para sa maliliit na koponan na may nakapirming komposisyon. Ang bawat tester ay idinaragdag nang manu-mano sa console at tumatanggap ng imbitasyon sa tinukoy na address.

Ang Google Groups ay mas gusto para sa mga koponan na may pabago-bagong komposisyon o awtomatikong pamamahala ng access. Sapat na idagdag ang grupo sa track at lahat ng miyembro nito ay makakakuha ng access sa mga build. Ang pagbabago sa komposisyon ng grupo ay nangyayari nang hindi ina-update ang mga setting sa Play Console.

Ini-install ng mga tester ang app sa pamamagitan ng Google Play sa device. Pagkatapos idagdag sa track, nakikita nila ang app bilang available para sa update (kung dati nila itong na-install mula sa ibang track) o bilang bagong app para i-install. Ang mga build mula sa Internal track ay hindi nai-publish sa publiko — tanging mga kalahok ng track ang nakakakita sa kanila.

Pagkolekta ng mga metrik sa Internal track

Awtomatikong kinokolekta ng Google Play ang Android Vitals para sa lahat ng build sa Internal Testing Track: dalas ng crash, ANR at bilis ng pagsisimula. Nakikita ng developer ang mga metrik sa Play Console agad pagkatapos i-install ang build ng unang tester. Ang data ay available sa real-time nang walang pagkaantala ng agregasyon.

Mga pagkakaiba ng Internal Testing sa Closed at Open tracks

Internal Testing Track ay naiiba sa Closed at Open tracks sa bilis ng pag-access, mga kinakailangan sa pagsusuri at laki ng audience. Ang Internal ay hindi nangangailangan ng moderasyon, ang Closed ay nangangailangan ng setup ng Google Groups at pagsusuri, ang Open ay sumasailalim sa buong pagsusuri ng Google.

Ang Internal track ay ang tanging track kung saan ang build ay available nang walang paghihintay. Ang Closed at Open ay nangangailangan ng pagsusuri ng Google na tumatagal mula ilang oras hanggang 2 araw. Para sa mga bagong account ng developer, ang Open Testing Track ay kinakailangan: ang app ay dapat sumailalim sa 14 na araw na bukas na pagsubok bago ipalathala sa produksyon.

Automasyon ng Internal Testing sa pamamagitan ng CI/CD

Ang automasyon ng pag-upload sa Internal Testing Track ay karaniwang kasanayan para sa mga CI/CD pipeline ng Android projects. Ang Gradle Play Publisher ay ang pinakasikat na plugin para sa awtomatikong pag-publish ng mga build. Pinipirmahan nito ang AAB, ina-upload sa Google Play at itinatalaga ang track.

Ang Fastlane ay nagbibigay ng aksyong supply para sa pag-upload ng mga build sa Play Console. Ang parameter na track ay nagpapahiwatig ng target na track: internal, closedalpha, openbeta o production. Ang pamamahala ng bersyon at service account ay naka-configure nang isang beses sa Fastfile.

# Fastfile - awtomatikong pag-upload sa Internal Testing Track
platform :android do
    desc "Build and deploy to Internal Testing"
    lane :internal do
        gradle(task: "bundleRelease")
        supply(
            track: "internal",
            aab: "app/build/outputs/bundle/release/app-release.aab",
            skip_upload_metadata: true,
            skip_upload_images: true
        )
    end
end

Ang service account ng Google Play ay ginagawa sa Google Cloud Console na may tungkuling Publisher at iniuugnay sa account ng developer sa Play Console. Ang JSON key ng service account ay iniimbak sa CI/CD repository bilang protektadong variable (GitHub Secrets, GitLab CI Variables, Jenkins Credentials).