Hotfix sa pag-develop ng app: esensya, mekanismo at paano gamitin

Ano ang hotfix at kailan ito kailangan?

Hotfix (mainit na pag-aayos) — isang patch para sa production version ng application na inilalabas nang wala sa pagkakasunod-sunod upang malutas ang isang kritikal na problema. Ang hotfix ay inihahatid sa mga user sa loob ng ilang oras, hindi araw, at inilaan lamang para sa mga sitwasyon kung saan ang application ay hindi magagamit, nawawalan ng data, o lumalabag sa seguridad ng user.

Karaniwang mga senaryo para sa hotfix: crash sa pagsisimula sa ilang device (regression pagkatapos ng huling release), pagtagas ng personal na data dahil sa hindi tamang awtorisasyon, hindi gumaganang integration ng pagbabayad (pagkawala ng kita), paglabag sa GDPR/CCPA compliance. Ang lahat ng sitwasyong ito ay may severity P0 o P1 sa klasipikasyon ng insidente. Nakaplanong gawain — optimization, refactoring, bagong screen — hindi kailanman ginagawa sa pamamagitan ng hotfix.

Mahalagang tuntunin: ang hotfix ay naglalaman ng minimal na bilang ng mga pagbabago (1-2 file, 10-20 linya ng code). Kung mas maliit ang diff, mas mababa ang panganib na magpakilala ng bagong error. Kung para sa pag-aayos ay kinakailangan ang pagbabago ng arkitektura o pagdagdag ng bagong module — ito ay hindi hotfix, kundi emergency release na nangangailangan ng kumpletong code review at QA.

Paano naiiba ang hotfix sa regular na release

Ang mga pangunahing pagkakaiba sa pagitan ng hotfix at nakaplanong release ay bilis, dami ng mga pagbabago, at antas ng pagsubok. Ang nakaplanong release ay maaaring magsama ng maraming feature, dumaan sa buong QA cycle (regression + integration + UI tests) at tumagal ng 1-2 linggo mula sa code freeze hanggang sa deploy. Hotfix ay naglalaman ng isa o dalawang pag-aayos, dumadaan sa pinabilis na pagsusuri (2 approvals sa halip na 3) at minimal na smoke test.

Mula sa pananaw ng proseso ng Git, ang hotfix ay ginagawa mula sa release tag, hindi mula sa develop branch. Tinitiyak nito na tanging ang mga pagbabagong kinakailangan upang malutas ang problema ang mapupunta sa hotfix, nang hindi sinasadyang makuha ang mga hindi tapos na feature mula sa develop. Pagkatapos ng deploy, ang hotfix ay ibinabalik sa main at develop (sa pamamagitan ng cherry-pick o merge).

Paghahambing ng nakaplanong release at hotfix

Mahalaga: hindi lahat ng agarang gawain ay hotfix. Kung sinabi ng manager na “kailangan agad magdagdag ng button” — ito ay hindi hotfix, kundi priority shift. Ang tunay na hotfix ay tinutukoy ng severity para sa user, hindi ng pagkaapurahan para sa negosyo. Kriterya: kung ang application ay hindi nag-crash at ang data ay hindi tumatagas — ang gawain ay naghihintay ng nakaplanong release.

Proseso ng hotfix: mula sa pagtuklas hanggang sa deploy

Ang unang hakbang pagkatapos matuklasan ang kritikal na problema ay triage — mabilis na pagtatasa ng severity. Kinukumpirma ng on-call engineer ang bug, sinusuri ang mga log at crash reports, tinutukoy kung ang problema ay regression ng huling release o matagal nang bug. Kung severity P0 — ang hotfix pipeline ay sinimulan. Yugto ng triage ay hindi dapat tumagal nang higit sa 15 minuto.

Ikalawang hakbang — paggawa ng branch mula sa huling release tag (v2.5.0 → hotfix/v2.5.1). Ang developer ay naglalapat ng minimal na pag-aayos, nag-commit na may prefix na HOTFIX sa mensahe, nag-push, at nagbubukas ng PR na may markang [HOTFIX]. Fast-track code review: dalawang reviewer ay awtomatikong itinatalaga sa pamamagitan ng CODEOWNERS, oras ng pagsusuri — hindi hihigit sa 30 minuto. Kung walang pagbabago sa loob ng 20 minuto — ang reviewer ay lalaktawan, ang susunod ay itatalaga.

Ikatlong hakbang — pagbuo at deploy sa pamamagitan ng CI/CD. Ang hotfix pipeline ay naiiba sa karaniwan: ang mahabang integration tests (na tumatagal ng mga oras) ay nilalaktawan, tanging smoke suite ang pinapatakbo (10-15 kritikal na senaryo, 5-10 minuto). Pagkatapos ng deploy, pagmamanman: crash rate, error rate, API latency — sa loob ng 30 minuto. DORA metrics para sa hotfix: oras ng pagbawi (MTTR) ay dapat na mas mababa sa 1 oras.

# .github/workflows/hotfix-deploy.yml
name: Hotfix Deploy Pipeline
on:
  pull_request:
    types: [labeled]
    branches: [hotfix/*]

jobs:
  hotfix-checks:
    runs-on: ubuntu-latest
    if: contains(github.event.label.name, 'hotfix-critical')
    steps:
      - uses: actions/checkout@v4
      - name: Validate diff size
        run: bash .github/scripts/diff-check.sh 30
      - name: Build
        run: ./gradlew assembleRelease
      - name: Smoke test
        run: ./gradlew smokeTest
      - name: Deploy to staging
        run: fastlane deploy_staging
      - name: Approve & deploy to production
        if: success()
        run: fastlane deploy_production
        env:
          HOTFIX_MODE: true

Sa pipeline na ito, ang mga pangunahing pag-optimize: pagsusuri ng diff (hindi hihigit sa 30 linya), paglaktaw sa integration tests, awtomatikong deploy sa staging at production kung matagumpay ang smoke test. HOTFIX_MODE environment variable ay nag-activate ng mga karagdagang pagsusuri sa runtime — halimbawa, pinalawak na pag-log para sa mabilis na diagnostic ng mga problema.

Hotfix branches sa Git: tamang estratehiya

Ang estratehiya ng pagtatrabaho sa hotfix branches ay inilalarawan sa Gitflow Workflow. Pangunahing tuntunin: ang hotfix branch ay ginagawa mula sa huling release tag (git checkout -b hotfix/v2.5.1 tags/v2.5.0), hindi mula sa develop o main. Tinitiyak nito na ang hotfix ay nakabatay sa parehong estado ng code na kasalukuyang nasa produksyon at hindi kumukuha ng hindi tapos na mga pagbabago mula sa develop.

Pagkatapos ng pag-aayos, ang hotfix branch ay pinagsasama sa main (o master) at develop. Sa main — isang normal na merge commit na may tag ng bagong release ng pag-aayos (v2.5.1). Sa develop — merge o cherry-pick, depende sa patakaran ng team. Kung ang develop ay naglalaman ng mas maraming pagbabago kaysa main, inirerekomenda ang cherry-pick ng specific na commit ng hotfix upang maiwasan ang mga conflict. GitFlow ay nagrerekomenda na i-merge muna ang hotfix sa main, at pagkatapos ay ang main sa develop.

# Gumawa ng hotfix branch mula sa pinakabagong release tag
git checkout -b hotfix/v2.5.1 tags/v2.5.0

# Ilapat ang pag-aayos
git commit -m "HOTFIX: Fix crash on Android 14 notification permission"

# I-merge sa main at i-tag ang release
git checkout main
git merge --no-ff hotfix/v2.5.1
git tag -a v2.5.1 -m "Hotfix release v2.5.1"

# I-merge din sa develop
git checkout develop
git merge --no-ff hotfix/v2.5.1

# Linisin ang pansamantalang branch
git branch -d hotfix/v2.5.1

Mahalaga: kung ang hotfix ay nag-aayos ng bug na umiiral sa kasalukuyang develop branch (ang bug ay ipinakilala ilang sprint na ang nakalipas), pagkatapos i-merge ang hotfix sa main at develop, ang develop ay naglalaman na ng pag-aayos. Kung ang bug ay ipinakilala lamang sa release branch (sa pamamagitan ng cherry-pick na naipon ang bug), sa develop ang pag-aayos ay maaaring hindi kailangan. Root cause analysis ay tumutulong matukoy kung kailangan ang cherry-pick sa develop.

Mga panganib ng hotfix at kung paano mabawasan ang mga ito

Ang pangunahing panganib ng hotfix — pagpapakilala ng bago, mas malubhang error dahil sa pagmamadali. Ayon sa pananaliksik ng Stripe (2021), 15% ng hotfix ay nagdudulot ng regression at nangangailangan ng pangalawang hotfix. Ito ang batas ng pagkakataon: mas mabilis nating inaayos, mas mataas ang posibilidad na magkamali. Pagbawas ng panganib ay nakakamit sa pamamagitan ng mahigpit na paglilimita sa laki ng diff (hindi hihigit sa 30 linya) at sapilitang awtomatikong smoke test.

Ikalawang panganib — akumulasyon ng technical debt. Kung ang team ay regular na gumagamit ng hotfix sa halip na nakaplanong release, ang code base ay bumababa: ang hotfix commits ay hindi dumadaan sa refactoring, ang pansamantalang solusyon ay hindi pinapalitan ng tama, ang dokumentasyon ay hindi naa-update. Health check: kung ang hotfix ay inilalabas nang higit sa isang beses sa isang buwan — ang proseso ng release ay nangangailangan ng pagsusuri.

Ikatlong panganib — sikolohikal. Ang regular na hotfix ay nakakapagod sa team: ang on-call developers ay nasa patuloy na stress, ang code review ay nagiging pormalidad (lahat ay gusto ng mabilis), bumababa ang kultura ng kalidad. Normal na dalas ng hotfix para sa isang mature na team ay 1-2 bawat quarter. Kung higit pa — ang problema ay hindi sa hotfix, kundi sa kalidad ng nakaplanong release.

Ano ang gagawin pagkatapos ng hotfix

Pagkatapos ng deploy ng hotfix at pagpapatatag ng metrics, isinasagawa ang post-mortem (blameless retrospective). Ang team ay sumasagot sa apat na tanong: ano ang nangyari, bakit hindi nahuli ng mga pagsusuri ang bug, ano ang ginawa upang ayusin, paano maiiwasan ang pag-ulit. Ang post-mortem ay isinasagawa sa loob ng 24-48 oras pagkatapos ng hotfix, habang ang mga detalye ay sariwa pa sa memorya. Blameless culture — pangunahing prinsipyo: tinatalakay ang mga proseso, hindi ang mga tao.

Ang resulta ng post-mortem — konkretong action items na may mga responsableng tao at deadline. Karaniwang action items: magdagdag ng unit test para sa kaso na hindi napansin, palawakin ang smoke test suite, pagandahin ang monitoring (magdagdag ng alert sa metric), i-update ang runbook para sa mga katulad na insidente. Action items ay dapat makumpleto bago ang susunod na nakaplanong release.