Apa Itu CI/CD? Continuous Integration dan Delivery Dijelaskan

CI/CD adalah cara mengirimkan perangkat lunak di mana setiap perubahan kode otomatis dibangun, diuji, dan, jika lolos, disiapkan untuk rilis atau langsung dirilis. CI (continuous integration) berarti perubahan sering digabungkan dan diperiksa oleh tes otomatis setiap kali. CD (continuous delivery atau deployment) berarti perubahan yang lolos dikemas dan didorong ke pengguna dengan sedikit atau tanpa pekerjaan manual.

Tujuannya sederhana: menangkap kesalahan beberapa menit setelah dibuat, bukan berminggu-minggu kemudian ketika pelanggan yang menemukannya.

Mengapa CI/CD penting saat membangun dengan AI

AI builder mengubah kode dengan cepat. Satu prompt bisa menyentuh sepuluh file. Kecepatan itu bagus, sampai satu perubahan pada halaman checkout diam-diam merusak halaman login, dan tidak ada yang sadar sampai seorang pengguna mengirimimu email.

CI/CD adalah jaring pengaman untuk situasi persis seperti ini. Alih-alih berharap setiap perubahan baik-baik saja, pipeline menjalankan pemeriksaan yang sama setiap kali:

• Apakah aplikasi masih bisa dibangun tanpa error?
• Apakah tes otomatis masih lolos?
• Apakah kode mengikuti aturan project (tipe, format, pemeriksaan keamanan)?

Jika ada pemeriksaan yang gagal, perubahan dihentikan sebelum mencapai pengguna. Semakin cepat kode kamu berubah, semakin berharga pemeriksaan yang tidak pernah lelah atau melewatkan langkah.

Analogi sehari-hari

Bayangkan sebuah toko roti yang setiap pagi menjual roti ke banyak toko.

• Tanpa CI/CD, setiap tukang roti bereksperimen dengan resepnya sendiri selama seminggu, lalu semuanya digabung pada Jumat malam dan semua berharap rotinya tetap mengembang. Ketika tidak, tidak ada yang tahu perubahan siapa penyebabnya.
• Dengan CI, setiap perubahan resep kecil langsung dipanggang sebagai roti uji dan diperiksa: rasa, berat, bentuk. Perubahan yang buruk tertangkap pada hari yang sama, dan kamu tahu persis yang mana.
• Dengan CD, roti yang lolos inspeksi langsung masuk ke mobil pengiriman, dikemas dan diberi label dengan cara yang sama setiap kali, alih-alih seseorang mengemas kotak dengan tangan jam 5 pagi.

Inspeksi itu tidak membuat tukang roti menjadi lebih baik. Ia membuat kesalahan mereka menjadi murah.

Cara kerja pipeline CI/CD

Sebuah pipeline adalah daftar langkah yang dijalankan otomatis oleh layanan CI/CD ketika sesuatu terjadi, biasanya ketika seseorang mendorong kode ke repository seperti GitHub. Pipeline tipikal terlihat seperti ini:

Setiap langkah berjalan di mesin yang bersih, bukan di laptop seseorang, sehingga alasan "di komputer saya jalan" tidak lagi berlaku. Jika satu langkah gagal, pipeline berhenti dan memberi tahu siapa pun yang membuat perubahan itu.

Langkah-langkah itu didefinisikan dalam file konfigurasi yang ada bersama kode. Di GitHub Actions, misalnya, berupa file YAML di folder .github/workflows repository.

Continuous delivery vs continuous deployment

Kata "CD" itu ambigu, dan orang memakainya dengan dua cara:

Continuous deployment hanya bekerja baik jika tesnya bagus. Jika tesmu tidak mencakup checkout, continuous deployment akan dengan senang hati merilis checkout yang rusak.

Contoh nyata: aplikasi booking dengan pipeline

Anggaplah kamu punya aplikasi booking salon, dan kodenya ada di repository GitHub. Kamu meminta AI builder untuk "menambahkan diskon 10% untuk customer baru".

1. Perubahan didorong ke branch baru dan pull request dibuka.
2. Pipeline dimulai. Ia memasang paket dan membangun aplikasi; ini lolos.
3. Ia menjalankan tes. Satu tes, "customer yang kembali membayar harga penuh", gagal: diskon diterapkan kepada semua orang.
4. Pull request menampilkan tanda silang merah. Perubahan tidak bisa digabungkan.
5. Kamu meminta AI memperbaikinya. Ia mendorong koreksi; pipeline berjalan lagi dan semuanya lolos.
6. Perubahan digabungkan. Pipeline men-deploy-nya ke lingkungan staging, tempat kamu mencoba satu booking uji.
7. Kamu menyetujui, dan aplikasi di-deploy ke produksi.

Tanpa pipeline, langkah 3 akan terjadi di dompet para pelanggan.

Istilah penting

Kesalahpahaman umum

• "CI/CD berarti aplikasi saya sudah diuji." Pipeline hanya menjalankan tes yang kamu miliki. Jika tidak ada tes, CI hanya membuktikan aplikasi bisa dibangun, tidak lebih. Minta AI menulis tes untuk alur yang paling penting.
• "CI/CD hanya untuk perusahaan besar." Alat hosted seperti GitHub Actions membutuhkan file konfigurasi singkat untuk disiapkan, dan tim kecil memakainya setiap saat. Yang membutuhkan usaha adalah tesnya, bukan alatnya.
• "Deployment otomatis berarti tidak ada yang memeriksa apa pun." Pipeline yang baik menambah pemeriksaan, bukan menguranginya. Banyak tim tetap mempertahankan langkah persetujuan manusia sebelum produksi.
• "Jika pipeline hijau, aplikasinya pasti berfungsi." Itu berarti pemeriksaan otomatis lolos. Kamu tetap sebaiknya mencoba perubahannya sendiri, idealnya di preview atau di staging.
• "CI/CD menggantikan backup." Tidak. Migrasi database yang buruk yang lolos tes tetap bisa merusak data nyata. Simpan backup dan cara untuk rollback.

Yang bisa kamu tanyakan ke AI builder

• "Tulis tes otomatis untuk sign-up, login, dan checkout, lalu tunjukkan cara menjalankannya."
• "Siapkan workflow GitHub Actions yang memasang dependensi, membangun aplikasi, dan menjalankan tes di setiap pull request."
• "Tambahkan pemeriksaan tipe dan linter ke pipeline, dan buat agar gagal ketika ada error."
• "Jelaskan dengan bahasa sederhana apa yang dilakukan setiap langkah pipeline."
• "Apa yang terjadi jika deploy gagal di tengah jalan? Bagaimana cara rollback?"
• "Pastikan tidak ada secret yang ditulis langsung di repository atau dicetak di log pipeline."

Jika aplikasimu memakai API key, pipeline juga membutuhkannya, disimpan sebagai secret terenkripsi di alat CI, tidak pernah di file konfigurasi. Lihat environment variable dan secret.

CI/CD dan Mythex

Mythex tidak menjalankan pipeline CI untukmu, tetapi ia memenuhi beberapa kebutuhan yang sama dengan caranya sendiri:

• Checkpoint. Setelah setiap giliran agent yang berhasil, Mythex menyimpan checkpoint git, dan Kembali ke titik ini memundurkan project jika ada perubahan yang salah. Lihat Chat.
• App Testing. Ketik /test dan agent akan mengklik preview live-mu seperti pengguna dan melaporkan alur yang rusak, berguna sebelum setiap publikasi. Lihat App Testing.
• Publikasi adalah langkah yang disengaja. Perubahan muncul di preview privat terlebih dahulu; aplikasi publikmu hanya diperbarui ketika kamu mempublikasikan lagi. Lebih dekat ke continuous delivery daripada continuous deployment.
• Sinkronisasi GitHub (Pro). Sinkronkan project ke repository GitHub dan kamu bisa menambahkan workflow GitHub Actions sendiri untuk menjalankan tes di setiap push. Lihat GitHub dan ekspor.

Untuk daftar hal yang perlu diuji secara manual sebelum rilis, lihat cara menguji aplikasi sebelum diluncurkan, dan untuk bekerja dengan version control, lihat cara memakai Git dengan aplikasi buatan AI.

Pertanyaan