DevOps adalah pendekatan yang menggabungkan development dan operations untuk mempercepat delivery sambil menjaga kualitas. Panduan singkat ini akan memandu kamu membangun pipeline CI/CD pertama pada GitHub Actions, mulai dari konsep dasar, penyiapan repositori, contoh workflow YAML, hingga deployment otomatis dan monitoring praktis untuk tim kecil atau pemula.
Cara Membuat Pipeline CI/CD di GitHub Actions dari Nol?
Membangun pipeline CI/CD dari nol sebenarnya bisa dilakukan dengan langkah yang jelas dan terukur. Pertama, kamu perlu memahami prinsip kerja DevOps serta tujuan utama dari pipeline. Setelah itu, siapkan repositori, struktur project, dan repository secrets yang dibutuhkan.
Selanjutnya, tulis workflow YAML dalam .github/workflows untuk build, test, dan deploy; terakhir tambahkan monitoring serta rollback. Pada bagian pertama kita mulai dari konsep agar langkah berikutnya lebih mudah dipahami.
💻 Mulai Belajar Pemrograman
Belajar pemrograman di Dicoding Academy dan mulai perjalanan Anda sebagai developer profesional.
Daftar SekarangMemahami Konsep Dasar DevOps untuk Pipeline
DevOps adalah pendekatan kolaborasi antara tim development dan operations untuk merilis software lebih cepat dan stabil. Fokus utamanya kecepatan rilis, kualitas kode, dan umpan balik yang cepat dari pengguna ataupun sistem. Dalam praktik modern, banyak tim memakai metrik DORA, seperti deployment frequency, lead time for changes, change failure rate, dan time to restore service untuk mengukur keberhasilan.
Prinsip DevOps sangat memengaruhi desain pipeline CI/CD. Hampir semua langkah berulang sebaiknya diautomasi, dari build, test, sampai deploy. Testing dijalankan sedini mungkin agar bug tertangkap sebelum menyentuh lingkungan produksi. Kepemilikan bersama berarti developer ikut bertanggung jawab atas kualitas dan reliability setelah rilis, bukan hanya menulis fitur.
Bayangkan kamu punya aplikasi web sederhana dengan back-end API dan front-end kecil. Tujuan pipeline-mu jelas: setiap push ke branch utama akan memicu build, menjalankan unit test, lalu jika lulus, otomatis deploy ke lingkungan staging atau production.
Dengan GitHub Actions, tujuan ini diterjemahkan ke file workflow yang mendefinisikan kapan pipeline berjalan, langkah-langkah job, dan kondisi lulus atau gagal; dalam bagian berikutnya kamu akan mulai dari menyiapkan repositori dan struktur proyek yang mendukung alur ini.
Menyiapkan Repositori dan Struktur Project untuk CI/CD
Langkah pertama, siapkan struktur folder yang rapi agar pipeline mudah dikonfigurasi dan dirawat. Contoh pola umumnya berikut.
|
1 2 3 4 5 6 7 8 9 |
├── src/ ├── tests/ ├── docs/ ├── Dockerfile ├── README.md ├── .gitignore └── .github/ └── workflows/ └── ci-cd.yml |
Folder src/ untuk kode aplikasi, tests/ untuk unit test, dan .github/workflows/ untuk file YAML GitHub Actions.
Jika kamu m Node.js, buat package.json minimal seperti berikut.
|
1 2 3 4 5 |
{ "scripts": { "test": "jest" } } |
Untuk Python, kamu bisa gunakan pytest pada requirements.txt, lalu jalankan pytest dalam pipeline. Untuk Java, pastikan proyek memakai Maven atau Gradle dengan perintah mvn test atau gradle test.
Terapkan branch strategy sederhana: main untuk produksi, develop untuk integrasi. Tambahkan README.md yang menjelaskan cara build, menjalankan test, dan alur deploy. Gunakan .gitignore sesuai bahasa, misalnya pola resmi dari GitHub: gitignore templates, agar file build dan secret tidak ikut ter-commit.
Dalam GitHub, buka tab Settings, lanjut ke Secrets and variables, dan buka bagian Actions. Tambahkan repository secrets, seperti DOCKERHUB_TOKEN, DATABASE_URL, atau kredensial cloud. Manfaatkan GITHUB_TOKEN bawaan untuk operasi ke repo, dan jangan pernah menyimpan password langsung dalam workflow atau source code.
Membangun Workflow GitHub Actions Langkah Demi Langkah
Sekarang kamu sudah punya repositori yang rapi, saatnya menulis file workflow CI/CD pertama. Struktur dasar YAML pada GitHub Actions selalu berisi name, on, dan jobs. Dalam jobs kamu mendefinisikan runs-on untuk memilih runner (misalnya ubuntu-latest) dan daftar steps. Setiap step bisa memakai actions dari marketplace atau menjalankan perintah shell lewat run.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
name: CI Pipeline on: push: branches: [ "main" ] pull_request: jobs: build-test: runs-on: ubuntu-latest strategy: matrix: node-version: [18, 20] steps: - name: Checkout code uses: actions/checkout@v4 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: ${{ matrix.node-version }} cache: "npm" - name: Install dependencies run: npm ci - name: Run tests run: npm test -- --ci --reporters=jest-junit - name: Upload test report if: always() uses: actions/upload-artifact@v4 with: name: test-report-${{ matrix.node-version }} path: junit.xml deploy: needs: build-test runs-on: ubuntu-latest if: github.ref == 'refs/heads/main' && github.event_name == 'push' steps: - name: Checkout code uses: actions/checkout@v4 - name: Deploy run: | echo "Running deploy script..." ./scripts/deploy.sh |
Actions seperti actions/checkout dan actions/setup-node adalah paket siap pakai dari marketplace, sedangkan run: npm ci atau run: ./scripts/deploy.sh menjalankan perintah langsung dalam runner.
Matrix build pada bagian strategy membuat job berjalan paralel untuk beberapa versi Node.js sehingga kamu tahu aplikasi aman di berbagai lingkungan. Cache dependencies pada setup-node menghemat waktu karena paket tidak selalu diunduh ulang.
Jika workflow gagal, kamu bisa buka tab Actions, lihat log per step, lalu tambahkan perintah, seperti npm test –verbose atau echo pada run untuk menambah konteks saat debugging.
Testing, Deployment Otomatis, dan Monitoring Pipeline
Setelah workflow dasar siap, kamu bisa menambah job testing dan code scanning. Mulai dari job unit test dengan matrix strategy agar kode diuji dalam beberapa versi runtime, misalnya berikut.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
jobs: test: runs-on: ubuntu-latest strategy: matrix: node-version: [18, 20] steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: ${{ matrix.node-version }} - run: npm ci - run: npm test |
Tambahkan job terpisah untuk integration test dan code scanning (misalnya CodeQL atau Dependabot) agar kegagalan lebih mudah dilacak dan eksekusi lebih efisien.
Untuk deployment, gunakan environment seperti staging dan production dengan protection rules. Contoh sederhana deployment ke container registry setelah semua tes lulus.
|
1 2 3 4 5 6 7 8 9 |
deploy: needs: [test] environment: staging runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: docker build -t ghcr.io/org/app:${{ github.sha }} . - run: echo $CR_PAT | docker login ghcr.io -u $GITHUB_ACTOR --password-stdin - run: docker push ghcr.io/org/app:${{ github.sha }} |
Kamu bisa menambahkan manual approval untuk promosi dari staging ke production serta langkah rollback yang hanya mengganti tag rilis ke versi stabil sebelumnya.
Terakhir, hubungkan notifikasi ke Slack atau email dengan actions pihak ketiga dan kirim status tiap deployment. Pantau metrik dasar seperti build duration, failure rate, dan frekuensi deployment, lalu gunakan data itu untuk menghapus langkah yang lambat, memecah job besar, atau menambah caching.
Saat terjadi kegagalan, biasakan melihat log per job, bandingkan dengan run yang sukses, lalu perbaiki secara bertahap agar pipeline makin stabil.
Penutup
Setelah mengikuti struktur ini, kamu akan punya gambaran jelas dan file contoh untuk pipeline CI/CD dalam GitHub Actions: repositori siap, workflow YAML dasar, testing otomatis, dan deployment. Fokus pada automasi kecil dulu, ukur hasil, lalu tingkatkan. Praktik berkelanjutan akan membuat pipeline semakin andal dan sesuai kebutuhan tim.
