Ebook Syafi
Koleksi
Admin
← DevOps Dengan AI
Edit Bab
💾 Simpan
Batal
Syarat
Mukadimah
Bab
Penutup
B
I
H2
H3
List
1.
Quote
Code
Link
Img
Table
Edit
Split
Preview
0 perkataan
# Bab 5: CI/CD dengan AI CI/CD adalah tempat kesilapan paling mahal, sebab pipeline yang salah boleh memusnahkan production tanpa amaran. AI sangat membantu untuk menulis pipeline, tetapi ia juga sangat pandai menghasilkan pipeline yang nampak betul tetapi longgar dari segi keselamatan. **Apa yang anda akan belajar:** - Cara minta AI tulis workflow GitHub Actions yang selamat - Perkara yang mesti disemak dalam setiap workflow - Cara nyahpepijat pipeline yang gagal tanpa membuang masa - Aliran kerja PR ke production yang saya guna ## 5.1 Prompt Asas untuk Pipeline ```text Tulis GitHub Actions workflow untuk projek Node.js ini. Keperluan: - Trigger: pull_request dan push ke main - Job: lint, test, build - Node 22, guna cache npm - permissions: contents: read sahaja - concurrency supaya push berturut-turut tidak bertindih - Pin setiap action kepada versi major (contoh: @v4) - Jangan letak sebarang secret dalam fail workflow Terangkan setiap blok dalam satu baris. ``` Empat perkara dalam prompt itu bukan hiasan: - **`permissions`** mengecilkan kuasa token. Tanpa ini, workflow anda boleh menulis ke repo dan mengubah release. - **`concurrency`** mengelak dua deploy berjalan serentak dan saling menimpa. - **Pin versi action.** Action pihak ketiga tanpa pin adalah risiko supply chain. - **Tiada secret dalam fail.** Rujuk `secrets.*` sahaja. ## 5.2 OIDC: Buang Kunci Kekal dari GitHub Amalan lama menyimpan `AWS_ACCESS_KEY_ID` dalam GitHub Secrets. Amalan yang lebih baik ialah OIDC, di mana GitHub mendapat token sementara daripada AWS, dan tiada kunci kekal disimpan di mana-mana. Minta AI bantu, tetapi berhati-hati: bahagian yang paling mudah salah ialah trust policy. Pastikan ia terhad kepada repo dan branch yang betul. ```text Saya mahu GitHub Actions deploy ke AWS tanpa access key kekal. Beri saya: 1. IAM role trust policy untuk OIDC, terhad kepada repo syafi-dev/infratify dan branch main sahaja 2. IAM policy minimum untuk deploy ke S3 dan invalidate CloudFront 3. Blok aws-actions/configure-aws-credentials yang sepadan Jelaskan setiap condition dan kenapa ia perlu. ``` Semak `sub` condition. Kalau ia benarkan semua branch atau semua repo, sesiapa yang boleh buka PR boleh mengakses akaun AWS anda. ## 5.3 Nyahpepijat Pipeline yang Gagal Ini penggunaan AI yang paling jimat masa. Tetapi ada cara betul untuk minta. **Cara salah:** tampal satu baris ralat dan tanya kenapa. **Cara betul:** ```text Pipeline gagal pada step "Run tests". Ini fail workflow penuh:
Ini log penuh dari awal step yang gagal:
Ini perubahan terakhir dalam commit ini:
Sebelum cadang penyelesaian: 1. Senaraikan tiga punca paling mungkin mengikut kebarangkalian 2. Untuk setiap punca, beri bukti dari log yang menyokong atau menafikan 3. Barulah cadang satu pembetulan yang paling kecil ``` Arahan "sebelum cadang penyelesaian" mengubah kualiti jawapan secara ketara. AI berhenti meneka dan mula membaca. ## 5.4 PR Review oleh AI, Kelulusan oleh Manusia AI boleh jadi penyemak pertama yang tidak pernah jemu. Pasang aliran ini: - Setiap PR, minta AI semak diff untuk: credential yang tertinggal, perubahan yang longgar pada firewall atau IAM, tag imej `latest`, dan perubahan yang tak sepadan dengan peraturan dalam `AGENTS.md`. - Hasil semakan AI masuk sebagai komen, bukan sebagai kelulusan. - Manusia yang tekan merge. Satu peraturan tambahan yang penting: **AI tidak dibenarkan meluluskan PR yang ia sendiri tulis.** Kalau tidak, anda sedang menguji kerja sendiri. ## 5.5 Aliran Kerja PR ke Production Ini susunan yang saya guna. Ia perlahan pada pandangan orang yang suka deploy terus, tetapi ia membenarkan saya tidur lena. 1. **PR dibuka.** Lint, test, dan semakan AI berjalan. 2. **Plan dijalankan** untuk perubahan infra dan komen dalam PR. 3. **Manusia semak dan merge** ke `main`. 4. **Deploy ke dev secara automatik.** 5. **Production memerlukan kelulusan.** Guna GitHub Environments dengan required reviewers. Deploy tidak bermula sehingga seseorang tekan setuju. 6. **Smoke test selepas deploy.** Sekurang-kurangnya satu arahan yang sahkan endpoint utama hidup. 7. **Rollback disediakan.** Kalau deploy anda tiada jalan balik, anda tiada CI/CD. Anda ada risiko berjadual. ## 5.6 Commit, Changelog, dan Notifikasi Tiga tugas kecil yang boleh diserahkan sepenuhnya kepada AI tanpa banyak risiko: - **Mesej commit.** Minta AI tukar diff jadi mesej Conventional Commits. Hasilnya lebih konsisten daripada yang ditulis manusia yang penat. - **Changelog.** Hasilkan dari senarai commit antara dua tag. Semak sekali sebelum publish. - **Notifikasi deploy.** Minta AI tulis langkah yang hantar mesej ke Telegram atau Slack selepas deploy berjaya atau gagal. Nyatakan versi dan commit hash, bukan hanya "deploy selesai". Pipeline anda sekarang punya penjaga. Bab seterusnya memberi anda alat untuk bekerja lebih pantas: sepuluh prompt yang boleh anda salin terus. \newpage