Google Play-da Internal Testing Track: mohiyati va trekni sozlash

Internal Testing Track nima?

Internal Testing Track — Google Play Console-da testning birinchi darajasi, build-larni dasturchilar jamoasi ichida tarqatish uchun mo'ljallangan. Asosiy maqsad — ish qobiliyatini tez tekshirish, integratsiyalarni sinash va auditoriyani Closed yoki Open treklariga kengaytirishdan oldin tanqidiy xatolarni aniqlashdir.

Google Play-ning boshqa treklaridan farqli o'laroq, Internal Testing faollashtirishdan oldin Google tekshiruvini talab qilmaydi. Build konsolga yuklanganidan bir necha daqiqa o'tgach testerlar uchun mavjud bo'ladi. Bu treki kunlik build-lar (daily builds) va CI/CD pipeline-dan avtomatik yetkazib berish uchun ideal qiladi.

Google Play Console hujjatlariga (2024) ko'ra, Internal Testing Track ikkita tarqatish variantini qo'llab-quvvatlaydi: elektron pochta ro'yxati (100 ishtirokchigacha) va Google Groups (miqdor cheklovisiz). Guruhlar ishtirokchilari tez-tez o'zgaradigan katta jamoalar uchun, elektron pochta esa doimiy tarkibli dasturchilar uchun mos keladi.

Internal Testing Track-ni qachon tanlash

Internal treki dasturning hali beqaror va API-lar o'zgarishi mumkin bo'lgan dastlabki rivojlanish bosqichlarida tanlanadi. CI/CD pipeline-i har bir yangi build-ni Internal trekiga yuklaydi va jamoa darhol yangi versiyani oladi. Xatolar va crash-log-lar build tashqi testerlar yoki foydalanuvchilarga yetib bormasdan oldin Play Console orqali yig'iladi.

Yangi dasturchi hisoblari uchun Internal Testing Track nashrga tayyorgarlikning birinchi bosqichi sifatida xizmat qiladi. Google bu bosqichda build-larni tekshirmaydi, bu jamoaga ko'rib chiqishga topshirishdan oldin mahsulot sifatiga o'zlari ishonch hosil qilish imkonini beradi.

Google Play Console-da Internal Testing Track-ni qanday sozlash

Internal Testing Track sozlash Google Play Console-da Release > Testing > Internal Testing bo'limida amalga oshiriladi. Jarayon trekni yaratish, birinchi build-ni yuklash va testerlarni qo'shishni o'z ichiga oladi.

Trekni yaratish uchun Internal Testing bo'limiga o'ting va Create track tugmasini bosing. Trek yaratilgandan so'ng, tizim birinchi build-ni AAB (Android App Bundle) formatida yuklashni taklif qiladi. Google barcha test turlari uchun AAB ni tavsiya qiladi, chunki format dastur hajmini qurilma arxitekturasiga qarab optimallashtiradi.

Build yuklanganidan so'ng, trekka kirish testerlarni qo'shish orqali ochiladi. Kamida bitta testersiz trek faol hisoblanmaydi. Google Play Console trek holatini, yuklangan build-lar ro'yxatini va har bir ishtirokchi bo'yicha o'rnatish statistikasini ko'rsatadi.

// build.gradle - Internal Testing Track-ga avtomatik yuklash
android {
    def versionCode = System.env.GIT_COMMIT_COUNT ?: "1"
    def versionName = "1.0." + versionCode

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

// Gradle Play Publisher plagin orqali joylashtirish
plugins {
    id 'com.github.triplet.play' version '3.9.0'
}

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

Internal trekiga testerlarni qo'shish

Internal Testing Track-ga testerlarni qo'shish ikki usulda mumkin: elektron pochta orqali va Google Groups orqali. Elektron pochta ro'yxati doimiy tarkibli kichik jamoalar uchun mos keladi. Har bir tester konsolda qo'lda qo'shiladi va ko'rsatilgan manzilga taklifnoma oladi.

Google Groups o'zgaruvchan tarkibli yoki avtomatlashtirilgan kirish boshqaruviga ega jamoalar uchun afzal. Guruhni trekka qo'shish kifoya va uning barcha a'zolari build-larga kirish huquqiga ega bo'ladi. Guruh tarkibini o'zgartirish Play Console sozlamalarini yangilamasdan amalga oshiriladi.

Testerlar dasturni qurilmada Google Play orqali o'rnatadilar. Trekka qo'shilgandan so'ng, ular dasturni yangilash uchun mavjud (agar avval boshqa trekdan o'rnatgan bo'lsalar) yoki o'rnatish uchun yangi dastur sifatida ko'radilar. Internal trekidagi build-lar umumiy foydalanishga chiqarilmaydi — ularni faqat trek ishtirokchilari ko'radi.

Internal trekida metrikalarni yig'ish

Google Play avtomatik ravishda Internal Testing Track-dagi barcha build-lar uchun Android Vitals ni yig'adi: crash chastotasi, ANR va ishga tushirish tezligi. Dasturchi birinchi tester build-ni o'rnatgandan so'ng darhol Play Console-da metrikalarni ko'radi. Ma'lumotlar agregatsiya kechikishisiz real vaqtda mavjud.

Internal Testing-ni Closed va Open treklaridan farqlari

Internal Testing Track Closed va Open treklaridan kirish tezligi, tekshiruv talablari va auditoriya ko'lami bilan farqlanadi. Internal moderatsiyani talab qilmaydi, Closed Google Groups sozlash va tekshiruvni talab qiladi, Open to'liq Google tekshiruvidan o'tadi.

Internal treki — build kutishsiz mavjud bo'lgan yagona trek. Closed va Open bir necha soatdan 2 kungacha davom etadigan Google tekshiruvini talab qiladi. Yangi dasturchi hisoblari uchun Open Testing Track majburiy: dastur ishlab chiqarishga chiqarishdan oldin 14 kunlik ochiq testdan o'tishi kerak.

Internal Testing-ni CI/CD orqali avtomatlashtirish

Internal Testing Track-ga yuklashni avtomatlashtirish Android loyihalarining CI/CD pipeline-lari uchun standart amaliyotdir. Gradle Play Publisher avtomatik build nashr qilish uchun eng mashhur plagin hisoblanadi. U AAB ni imzolaydi, Google Play-ga yuklaydi va trekni tayinlaydi.

Fastlane build-larni Play Console-ga yuklash uchun supply harakatini taqdim etadi. track parametri maqsadli trekni ko'rsatadi: internal, closedalpha, openbeta yoki production. Versiyalarni boshqarish va service account Fastfile-da bir marta sozlanadi.

# Fastfile - Internal Testing Track-ga avtomatik yuklash
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

Google Play Service account Google Cloud Console-da Publisher roli bilan yaratiladi va Play Console-dagi dasturchi hisobiga bog'lanadi. Service account-ning JSON kaliti CI/CD repozitoriyasida himoyalangan o'zgaruvchi sifatida saqlanadi (GitHub Secrets, GitLab CI Variables, Jenkins Credentials).