Build Number — ano ito, kahulugan ng parameter at increment

Ano ang Build Number

Build Number — ay isang natatanging integer identifier na itinalaga sa bawat build ng mobile application. Ginagamit ito ng mga app store upang matukoy ang pagiging bago ng bersyon — mas malaki ang numero, mas bago ang build.

Sa Android ang parameter na ito ay tinatawag na versionCode, sa iOS — CFBundleVersion. Ang parehong parameter ay sapilitan para sa publikasyon at dapat na monotonically tumaas sa bawat bagong build.

Ayon sa datos ng Google Play Console Help (2025), ang versionCode ay sinusuri sa bawat pag-upload ng APK: kung ang na-upload na build ay may versionCode na mas maliit o katumbas ng na-publish na, tinatanggihan ng Google Play ang file na may error.

Gamitin ang Build Number para sa panloob na pagsubaybay ng mga build — iugnay ang numero sa commit hash sa version control system para sa mabilis na pagkilala ng problematikong release.

Bakit Kailangan ang Build Number

Build Number ay lumulutas sa problema ng natatanging pagkilala ng bawat binuong bersyon ng application. Kung wala ito, imposibleng matukoy kung aling build ang mas bago kung hindi nagbago ang Version Name.

Ang mga app store tulad ng Google Play at App Store ay gumagamit ng Build Number upang malutas ang mga salungatan sa pag-update. Kung ang gumagamit ay nag-install ng bagong bersyon sa ibabaw ng luma, inihahambing ng system ang Build Number at nag-aalok lamang ng update kung mas malaki ang halaga.

Ang mekanikong ito ay kritikal para sa tamang paghahatid ng mga update: kung walang monotonically tumataas na Build Number, ang mga gumagamit ay maaaring manatili sa lumang bersyon ng application.

Mga Format ng Build Number

Build Number ay maaaring maging isang simpleng sequential number (1, 2, 3...) o compound, na nag-e-encode ng karagdagang impormasyon. Ang mga compound na numero ay kadalasang may kasamang petsa ng build o numero ng build ng CI/CD system.

Para sa Android ang versionCode ay isang integer ng uri int, maximum na halaga — 2100000000. Para sa iOS ang CFBundleVersion ay isang string ng tatlong numerong pinaghihiwalay ng tuldok, bawat isa ay hindi hihigit sa 255.

Ayon sa datos ng Apple Developer (2025), sinusuportahan ng CFBundleVersion ang hanggang 3 bahagi, ngunit ginagamit ng App Store ang mga ito bilang isang solong ordinal na numero para sa paghahambing ng bersyon.

Build Number sa Android

Sa Android ang Build Number ay itinakda gamit ang parameter na versionCode sa file na build.gradle. Ito ay isang integer na dapat na natatangi para sa bawat bersyon ng application na nai-publish sa Google Play.

Ang parameter ay idineklara sa loob ng block na android.defaultConfig at dapat tumaas sa bawat bagong release. Hindi pinapayagan ng Google Play ang pag-upload ng APK na may versionCode na ginamit na para sa ibang bersyon ng parehong application.

Ayon sa datos ng Google Play Developer API (2025), ang maximum na halaga ng versionCode ay 2100000000. Inirerekomenda na magsimula sa 1 at dagdagan ng 1 para sa bawat bagong build upang maiwasan ang pagkaubos ng limitasyon.

Gumamit ng compound na versionCode na nag-e-encode ng numero ng bersyon: Major * 1000000 + Minor * 1000 + Patch — pinapasimple nito ang pagmamapa sa semantikong bersyon.

Mga Limitasyon ng versionCode sa Android

versionCode ay may mahigpit na limitasyon: ito ay isang 32-bit na integer na may senyales, kaya ang maximum na halaga ay 2100000000. Kapag naubos ang limitasyon, ang application ay hindi maaaring i-update sa Google Play.

Para sa Android App Bundle, ang versionCode ay tinutukoy din sa base module, at ang bawat feature module ay maaaring magkaroon ng sariling versionCode. Pinagsasama ng Google Play ang mga ito sa isang sistema ng pag-verify.

Ang limitasyong ito ay mahalagang isaalang-alang kapag pumipili ng estratehiya ng pag-ve-version — ang masyadong mabilis na paglaki ng numero ay maaaring magdulot ng mga problema sa pangmatagalan.

Build Number sa iOS

Sa iOS ang Build Number ay itinakda gamit ang key na CFBundleVersion sa file na Info.plist. Hindi tulad ng Android, ang parameter na ito ay isang string, ngunit dapat ding tumaas sa bawat bagong build.

Ang format ng CFBundleVersion — mula isa hanggang tatlong numero na pinaghihiwalay ng tuldok. Ang bawat numero ay hindi maaaring lumampas sa 255. Ini-interpret ng App Store ang string bilang isang sequence ng mga numero para sa paghahambing: ang 1.0.1 ay itinuturing na mas bago kaysa 1.0.0.

Ayon sa datos ng Apple Developer Documentation (2025), hinihingi ng App Store Connect ang pagiging natatangi ng CFBundleVersion para sa bawat na-upload na build. Kung ang isang build na may numerong ginamit na ay na-upload, tatanggihan ito ng system.

Pamahalaan ang CFBundleVersion sa pamamagitan ng agvtool o mga script ng build ng Xcode upang garantiyahan ang monotonikong pagtaas ng numero sa bawat build.

Integrasyon sa Xcode Build Settings

Xcode ay nagpapahintulot sa pamamahala ng CFBundleVersion sa pamamagitan ng mga setting ng Build Settings. Ang field na “Current Project Version” ay nagtatakda ng base value, at ang mga script ng Build Phase ay maaaring awtomatikong dagdagan ito.

Para sa CI/CD gamitin ang fastlane plugin na increment_build_number, na nagbabasa ng kasalukuyang bersyon mula sa Info.plist at dinadagdagan ito ng isang tiyak na halaga. Garantisado nito ang pagiging natatangi ng bawat build.

Ang pamamaraang ito ay ganap na nag-a-automate ng pamamahala ng Build Number at nag-aalis ng mga pagkakamali ng tao sa paghahanda ng release.

Awtomatikong Increment ng Build Number

Awtomatikong increment ng Build Number ay isang karaniwang kasanayan sa modernong CI/CD pipelines. Ang manu-manong pagtaas ng numero ng build ay humahantong sa mga error at salungatan sa pag-publish.

GitHub Actions, GitLab CI at Jenkins ay nagbibigay ng mga built-in na variable na may numero ng build. Ang mga variable na ito ay ginagamit sa mga script ng Gradle o Xcode para sa awtomatikong pagpasok ng Build Number.

Ayon sa datos ng GitLab CI Documentation (2025), ang variable na CI_PIPELINE_IID ay garantisadong natatanging numero para sa bawat pipeline, na perpekto para gamitin bilang Build Number.

I-configure ang awtomatikong increment sa antas ng CI/CD — aalisin nito ang pangangailangan na manu-manong baguhin ang Build Number sa bawat commit sa release branch.

Mga Popular na Tool sa Pag-automate

GitHub Actions ay sumusuporta sa built-in na variable na run_number, na awtomatikong tumataas para sa bawat pagpapatakbo ng pipeline. Ang halaga ay maaaring ipasa sa Gradle sa pamamagitan ng versionCode.

Jenkins ay gumagamit ng variable na BUILD_NUMBER, na available sa lahat ng yugto ng build. Para sa mga proyekto ng Xcode, pinapatakbo ng Jenkins ang agvtool gamit ang numerong ito.

Pumili ng tool na integrated sa iyong technology stack upang mabawasan ang karagdagang configuration.

Build Number at Version Name

Build Number at Version Name ay gumagana bilang isang pares: ang una — para sa mga makina, ang pangalawa — para sa mga tao. Ang Build Number ay nagbibigay ng teknikal na pagiging natatangi, ang Version Name — semantika na naiintindihan ng gumagamit.

Sa Android ang dalawang parameter na ito ay independyente: ang versionCode ay maaaring tumaas nang hindi binabago ang versionName (halimbawa, para itama ang error sa build). Sa iOS, ang CFBundleVersion ay hindi rin nakatali sa CFBundleShortVersionString.

Ayon sa datos ng Stack Overflow Developer Survey (2024), 82% ng mga team ay gumagamit ng awtomatikong increment ng Build Number, ngunit 45% lamang ang nag-a-automate ng pag-update ng Version Name — ito ay isa sa mga karaniwang sanhi ng error sa release.

Palaging dagdagan ang Build Number sa bawat build, kahit na hindi nagbabago ang Version Name — garantisado nito ang tamang paggana ng mekanismo ng update sa mga app store.

Mga Pinakamahusay na Kasanayan para sa Build Number

Simulan ang versionCode sa 1 at dagdagan ng 1 para sa bawat build. Para sa iOS gumamit ng kahalintulad na pamamaraan sa CFBundleVersion. Iwasan ang mga compound na numero kung walang mahigpit na pangangailangan — ang simpleng sequential number ay mas madaling subaybayan.

Iugnay ang Build Number sa numero ng build ng CI/CD system — pinapasimple nito ang pagsubaybay mula sa error patungo sa partikular na commit. Ang Git tag na may numero ng build at bersyon ay pinakamahusay na kasanayan para sa kontrol ng release.

Mga Halimbawa ng Configuration ng Build Number

Mga halimbawa ng code ay nagpapakita kung paano i-configure ang awtomatikong increment ng Build Number sa parehong platform.

versionCode sa Gradle na may CI variable

Sa Android ang versionCode ay maaaring itakda sa pamamagitan ng environment variable ng CI/CD. Kung hindi nakatakda ang variable, ginagamit ang default na halaga.

android {
    defaultConfig {
        versionCode System.getenv("CI_PIPELINE_ID")?.toInteger() ?: 1
        versionName "1.2.0"
    }
}

versionCode ay nakakakuha ng halaga mula sa CI/CD variable, na garantisadong natatangi ang numero para sa bawat build sa pipeline.

Increment ng CFBundleVersion sa pamamagitan ng agvtool

Sa iOS para sa awtomatikong pagtaas ng Build Number ay ginagamit ang agvtool, na naka-built in sa Xcode Command Line Tools.

# Pagtaas ng build number ng 1
xcrun agvtool next-version -all

# Pagtatakda ng tiyak na build number
xcrun agvtool new-version -all "3.0.1"

Ang flag na -all ay nag-a-update ng bersyon sa lahat ng target ng proyekto, na garantisadong naka-sync ang mga halaga sa pagitan ng pangunahing application at mga extension.

Fastlane para sa Pag-automate

Fastlane — isang popular na tool para sa pag-automate ng build ng mobile application. Ang plugin na increment_build_number ay awtomatikong nagtataas ng Build Number.

increment_build_number(
    build_number: ENV["BUILD_NUMBER"] ||
                 latest_testflight_build_number + 1
)

Fastlane ay integrated sa anumang CI/CD system at sumusuporta sa parehong Android at iOS na mga proyekto.