Skip to main content
DevOps dari nol · Pelajaran 14 dari 15 · 12 menit

Quality Gate GitHub Actions: Periksa Sebelum Deploy

Belajar quality gate CI dari workflow nyata: typecheck, lint, test, dan build, dependensi job dengan needs, urutan fail-fast, dan branch protection.

Oleh Matthews WongDitinjau pada

Poin utama

Quality gate CI adalah pemeriksaan yang kegagalannya menghentikan pipeline sebelum tahap berikutnya. Di GitHub Actions, step berjalan berurutan dan berhenti di kegagalan pertama, job dengan needs dilewati ketika job yang dibutuhkannya gagal, dan branch protection bisa mewajibkan pemeriksaan sebelum merge. Pemeriksaan murah ditaruh di depan agar commit buruk gagal cepat.

Setelah pelajaran ini, Anda bisa

  • Mengurutkan typecheck, lint, test, dan build menjadi pipeline di mana setiap gate melindungi tahap berikutnya.
  • Memakai needs agar job yang gagal membuat semua tahap setelahnya dilewati, dan menjelaskan arti job yang dilewati.
  • Menyebut apa yang dicakup gate situs ini, apa yang tidak, dan di mana branch protection berperan.
Lihat cara kerjanya

Ikuti diagramnya langkah demi langkah

Tekan Putar, atau melangkah dengan panah. Setiap langkah juga ditulis di bawah diagram.

Bagaimana pemeriksaan yang gagal menghentikan deploy

Sebuah push menjalankan typecheck, lalu lint, lalu build, lalu deploy. Kegagalan di gate pertama membuat semua job berikutnya dilewati, dan pemeriksaan yang tidak pernah dijalankan CI tidak melindungi apa pun.

Langkah 1 dari 6. Satu rantai: push, typecheck, lint, build, deploy. Setiap job menunggu job sebelumnya. Dua kotak pudar di bawah adalah celah yang akan kita bahas.

Tombol: ← → langkah · Home / End · K putar atau jeda

  1. Satu rantai: push, typecheck, lint, build, deploy. Setiap job menunggu job sebelumnya. Dua kotak pudar di bawah adalah celah yang akan kita bahas.

  2. Push memicu workflow. Typecheck dan lint adalah step di job verify, jadi berjalan berurutan: lint hanya mulai jika typecheck lolos.

    Tebak langkah berikutnya Typecheck melaporkan error. Apa yang terjadi pada job build dan deploy? (Tetap berjalan · Dilewati · Hanya deploy yang dilewati)

  3. Error tipe menggagalkan step, sehingga job verify gagal. Job yang membutuhkannya dilewati, begitu pula setiap job yang membutuhkan job itu. Tidak ada yang di-build atau di-deploy.

  4. Perbaiki error lalu push lagi. Typecheck lolos, lint lolos, dan baru setelah itu job build dimulai. Deploy menunggu build dengan cara yang sama.

    needs: verify

  5. Repo ini punya script npm test, tetapi workflow tidak pernah memanggilnya. Test yang gagal tidak akan menghentikan deploy. Gate punya celah tepat di tempat tidak ada job yang berjalan.

    Tebak langkah berikutnya Aturan branch mewajibkan sebuah check, tetapi check itu akhirnya dilewati. Bisakah pull request di-merge? (Tidak, dilewati dianggap gagal · Bisa, dilewati dianggap terpenuhi)

  6. Required status checks adalah pengaturan GitHub, bukan kode workflow. Jika diaktifkan, pull request tidak bisa di-merge sampai check lolos. Check yang dilewati dianggap terpenuhi.

Apa itu quality gate?

Quality gate adalah pemeriksaan yang harus lolos sebelum pipeline berlanjut. Idenya sederhana: tentukan apa yang harus benar pada setiap commit, jalankan pemeriksaan itu secara otomatis, dan buat kegagalan menghentikan jalur. Kandidat yang umum adalah typecheck, linter, test otomatis, dan build.

Baca selengkapnya (1)

Intinya bukan seremoni. Pemeriksaan yang dijalankan dari ingatan akan terlewat di hari ketika Anda terburu-buru, yaitu hari ketika Anda paling membutuhkannya. Gate tidak lupa.

Bagaimana step dan needs mengubah pemeriksaan menjadi gate?

Di dalam satu job, step berjalan berurutan. Kecuali ada kondisi lain, sebuah step hanya berjalan jika step sebelumnya berhasil, karena kondisi defaultnya adalah success(). Runner menentukan lolos atau gagal dari kode exit perintah, jadi typecheck atau linter yang gagal sudah cukup menghentikan job.

Baca selengkapnya (1)

Antar job, needs menyebut job yang harus selesai lebih dulu. Jika sebuah job gagal atau dilewati, semua job yang membutuhkannya ikut dilewati, kecuali ada kondisi seperti always() yang menimpanya. Itulah yang membuat rantai job menjadi gate: build needs verify, deploy needs build.

Pemeriksaan mana yang didahulukan, dan kenapa fail fast?

Taruh pemeriksaan yang paling murah dan paling informatif di depan. Typecheck atau linter melaporkan kesalahan jauh sebelum build penuh selesai, sehingga commit buruk ditolak lebih awal dan job yang lambat dan mahal tidak pernah dimulai. Fail fast menghemat waktu runner dan, yang lebih berguna, membuat sinyalnya sampai ke Anda lebih cepat.

Baca selengkapnya (1)

Matrix menambahkan saklar yang berkaitan. Dengan fail-fast aktif, kegagalan pada job matrix yang tidak boleh gagal membatalkan job matrix yang masih berjalan atau mengantre. Situs ini tidak memakai matrix, tetapi aturannya sama: berhenti membuang waktu pada run yang tidak mungkin berhasil.

Di mana gate situs ini berhenti?

Job verify menjalankan npm ci, lalu typecheck, lalu linter. Job build needs verify dan job deploy needs build, sehingga tidak ada image yang dibuat dari commit yang typecheck atau lint-nya gagal. Build Next sendiri sengaja melewati typecheck dan lint karena keduanya sudah berjalan sekali, dan konfigurasinya meminta skip itu dihapus jika verify tidak lagi menjadi gerbang build.

Baca selengkapnya (1)

Satu celah yang jujur dan satu gate tambahan. Celahnya: repo punya script npm test, tetapi tidak ada workflow yang memanggilnya, jadi test bukan gate. Tambahannya: build juga memicu script prebuild, yang menjalankan pemeriksaan paritas, penempatan, import, dan kunci pesan situs, sehingga pemeriksaan itu memang menjadi gate bagi image. Workflow smoke terpisah mem-build situs dan menjalankan tes browser pada pull request, tetapi deploy tidak menunggunya.

Apa yang ditambahkan branch protection?

Workflow melaporkan hasil; branch protection yang membuat hasil itu mengikat. Dengan required status checks aktif, semua check wajib harus lolos sebelum perubahan bisa di-merge ke branch yang dilindungi. Check berstatus berhasil, dilewati, atau netral dianggap terpenuhi, jadi gate yang tidak sengaja dilewati adalah gate yang terbuka.

Baca selengkapnya (1)

Dua detail yang sering menjebak. Nama job sebaiknya unik di semua workflow, karena nama yang dipakai ulang bisa memberi hasil ambigu dan memblokir merge. Dan workflow deploy ini berjalan pada push ke main, bukan pada pull request, jadi untuk menggerbangi pull request Anda perlu workflow yang berjalan pada event pull_request. File repo tidak bisa menunjukkan apakah branch protection aktif; itu ada di pengaturan repositori.

Cara situs ini melakukannya

Konfigurasi nyata di balik pelajaran ini

Kutipan dari repositori yang membangun dan men-deploy situs ini, apa adanya.

.github/workflows/deploy.yml:38-44
      - run: npm ci
      - run: npx tsc --noEmit
      - run: npm run lint

  build-and-push:
    name: Build & push image
    needs: verify

Seluruh gate-nya. Tiga step berjalan berurutan, dan kegagalan di salah satunya menggagalkan job verify. Job build menyebutnya di needs, sehingga verify yang gagal membuat build dilewati dan, lewat build, deploy juga.

next.config.ts:36-40
  // Run `npx tsc --noEmit` yourself before pushing, as CLAUDE.md already says.
  // If the `verify` job is ever removed or stops gating the build, these two
  // lines must come out in the same change.
  typescript: { ignoreBuildErrors: true },
  eslint: { ignoreDuringBuilds: true },

Sebuah pertukaran yang disengaja: build Docker tidak melakukan typecheck atau lint lagi karena gate sudah melakukannya. Komentarnya adalah katup pengaman yang menyebut syarat persis kapan dua baris ini harus dihapus. Gate yang Anda andalkan sebaiknya selalu ditulis seperti ini.

package.json:12
"prebuild": "node scripts/generate-blog-sources.mjs --check && node scripts/game/check-placements.mjs && node scripts/game/check-imports.mjs && node scripts/check-message-keys.mjs",

npm menjalankan script bernama prebuild secara otomatis sebelum build. Setiap pemeriksaan digabung dengan &&, jadi yang pertama keluar dengan kode bukan nol menghentikan rantai dan menggagalkan build. Itu menjadikannya gate di dalam step build, tanpa mengubah workflow.

.github/workflows/game-smoke.yml:20
  pull_request:

Satu baris yang menjadikan workflow ini pemeriksaan pull request. Workflow deploy tidak punya pemicu seperti itu, karena itu gate untuk pull request membutuhkan workflow atau pemicunya sendiri.

Yang sering rusak

Kesalahan yang benar-benar membuang waktu

  • Job pemeriksaan yang tidak ditunggu siapa pun

    needs yang mengurutkan job. Jika job build tidak menyebut verify, tidak ada yang membuatnya menunggu verify, dan pemeriksaan yang gagal tidak lagi menghentikannya. Setiap kali Anda menambah gate, tambahkan juga ke needs job yang harus dilindunginya.

  • Mematikan pemeriksaan di hilir tanpa gate di hulu

    Build situs ini melewati typecheck dan lint karena verify menjalankannya. Hapus verify, atau biarkan ia tidak lagi menggerbangi build, dan error tipe akan terkirim diam-diam. Komentar konfigurasi menyebut keterkaitan ini; tiru kebiasaan itu setiap kali satu pemeriksaan menggantikan yang lain.

  • Test ada tetapi CI tidak pernah menjalankannya

    Script di package.json tidak melindungi apa pun sampai ada job yang memanggilnya. Di sini npm test tidak ada di job verify, jadi test yang gagal tidak menghentikan deploy. Daftarkan apa yang benar-benar dijalankan pipeline Anda, lalu bandingkan dengan isi package.json.

  • Check wajib yang dilewati

    Branch protection menganggap check yang dilewati sebagai terpenuhi. Jika filter path atau kegagalan di hulu membuat job wajib dilewati, tombol merge menjadi hijau. Pastikan check wajib berjalan pada setiap pull request, atau terima bahwa dilewati berarti lolos.

Pemeriksaan mana menangkap apa
TypecheckTipe yang salah dan kontrak yang rusakYa, job verify
LintKode mencurigakan dan aturan gayaYa, job verify
BuildKode yang tidak bisa dikompilasi atau di-bundleYa, job build (pemeriksaan prebuild lebih dulu)
TestPerilaku yang berubah tanpa sengajaTidak, npm test tidak dipanggil
Coba sendiri

Lakukan di komputer Anda sendiri

Repo kecil apa pun dengan GitHub Actions bisa dipakai. Anda akan membuat gate dua job, merusaknya dengan sengaja, dan melihat job kedua dilewati.

  1. Jalankan pemeriksaan di lokal lebih dulu, dengan urutan yang Anda inginkan di CI. Perbaiki apa pun yang gagal sebelum push.

    npx tsc --noEmit && npm run lint

  2. Buat .github/workflows/gate.yml dengan job verify dan job build yang membutuhkannya.

    name: gate
on:
  push:
    branches: [main]
  pull_request:

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npx tsc --noEmit
      - run: npm run lint

  build:
    needs: verify
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run build

  3. Push dan pastikan kedua job lolos. Lalu tambahkan error tipe dengan sengaja, misalnya mengisi angka dengan string, dan push lagi.

    const count: number = 'three';

  4. Buka run-nya. Job verify seharusnya merah dan job build ditandai dilewati, bukan berjalan. Perbaiki error lalu push agar kembali hijau.

  5. Opsional: di pengaturan repositori, tambahkan aturan branch protection untuk main yang mewajibkan check verify, lalu buka pull request dan lihat merge diblokir selagi check gagal.

Kuis singkat

Tiga pertanyaan sebelum lanjut

Pilih jawaban untuk melihat kenapa benar atau salah. Tidak ada yang disimpan atau dinilai, jadi tebak saja dengan bebas.

  1. 1.Sebuah workflow punya job verify dan build, tetapi build tidak mendeklarasikan needs. verify gagal. Apa yang terjadi pada build?
  2. 2.Repo punya script npm test dan job verify workflow deploy hanya menjalankan npm ci, typecheck, dan lint. Sebuah test mulai gagal. Apa yang terjadi pada push berikutnya ke main?
  3. 3.Aturan branch mewajibkan check verify, tetapi filter path membuat job itu dilewati pada pull request yang hanya mengubah dokumentasi. Bisakah di-merge?
Pikirkan dulu

Jawab dalam hati, lalu cek

  1. 1.Job mana yang harus lolos sebelum job deploy situs ini bisa mulai?Lihat jawabannya

    Jawaban:Build and push, yang sendiri membutuhkan verify (typecheck dan lint). Deploy membutuhkan job build, jadi verify yang gagal melewati keduanya.

  2. 2.Kenapa build Docker mengatur ignoreBuildErrors dan ignoreDuringBuilds?Lihat jawabannya

    Jawaban:Typecheck dan lint sudah berjalan sekali di job verify, jadi mengulanginya di build image hanya membuang waktu. Komentarnya menyebut syarat keluar: jika verify tidak lagi menggerbangi build, hapus kedua baris itu.

  3. 3.Apa yang ditambahkan branch protection yang tidak dimiliki workflow saja?Lihat jawabannya

    Jawaban:Ia membuat check mengikat: dengan required status checks aktif, pull request tidak bisa di-merge sampai check lolos. Tanpanya, check merah hanyalah peringatan.

Pelajari lebih dalam

Bahasan mendalam terkait di situs ini

Sumber

Sumber primer yang diperiksa pada tanggal riset. Ikuti tautannya untuk versi terbaru.

Pelajaran sebelumnyaDocker Logs untuk Pemula: Baca, Batasi, dan Rotasi LogPelajaran berikutnyaDocker No Space Left on Device: Cari Penyebab Disk Penuh