Pengembangan Perangkat Lunak dengan Devin: Integrasi, Pengujian, dan CI/CD (Bagian 3)

Selamat datang kembali! Di akhir tutorial kedua, kita memiliki playground fp-ts bertema pastel, backend NestJS + PostgreSQL, dan pelacakan progres UUID anonim.

Anda dapat mengakses semua tutorial dalam seri Devin di sini:

1. Penyiapan dan Pull Request Pertama (Bagian 1)
2. Mengirimkan Vertical Slice dengan Devin (Bagian 2)
3. Integrasi, Pengujian, dan CI/CD (Bagian 3) 
4. Keamanan, Deployment, Pemeliharaan (Bagian 4)

Apa yang telah kita lakukan sejauh ini bagus untuk bekerja sendiri, tetapi saatnya melihat seberapa baik Devin terintegrasi dengan alur kerja tim. Di tutorial ketiga ini, kita akan melihat:

• Integrasi: Devin akan membuka tiket Jira, mengerjakannya, dan menyiarkan setiap status PR langsung ke Slack.
• Gerbang kualitas: Kita akan menambahkan unit test Jest untuk API, alur end-to-end Playwright untuk UI, dan menegakkan cakupan 90%.
• CI/CD: GitHub Actions akan melakukan lint, pemeriksaan tipe, menjalankan semua pengujian, dan melampirkan laporan Playwright ke pull request sebelum apa pun dapat di-merge.

Belum ada autentikasi dan deployment produksi, itu akan dilakukan di Bagian 4!

Menyiapkan Integrasi Slack di Devin

Menghubungkan Devin ke komunikasi dan alur tiket Anda sepenuhnya manual dan dilakukan melalui antarmuka Devin.

Anda dapat terhubung ke Slack dari tab integrasi di pengaturan Devin, atau memasang aplikasi “Devin AI” dari Direktori Aplikasi Slack.

Aplikasi ini masih menampilkan “Belum disetujui oleh Slack” di dialog OAuth. Cognition mengatakan tinjauan keamanan mereka sedang berlangsung, dan fungsionalitas tidak terpengaruh.

Lalu pilih saluran:

Anda dapat mengobrol dengan Devin hanya dengan menyebutnya:

Dan itu memulai sesi yang dapat Anda akses di UI:

Secara default, Anda akan diberi tahu tentang pembaruan PR di saluran pilihan Anda, tetapi ada beberapa pengaturan notifikasi berbeda yang dapat Anda atur di parameter setiap sesi.

Menyiapkan Integrasi Jira di Devin

Untuk berintegrasi dengan Jira, Anda perlu membuat pengguna bot khusus (misalnya, devin-bot@…) dan menautkan kredensial tersebut di Devin → Team ▸ Integrations ▸ Jira.

Dari akun pribadi Anda, Anda kemudian dapat membuat tiket baru dan menambahkan label devin.

Devin memposting komentar analisis dengan garis besar rencana dan prompt “Mulai sesi?” Ketik “yes” untuk membiarkannya menulis kode atau hapus label untuk menjaga tiket tetap dikerjakan manusia saja.

Catatan: Devin tidak akan otomatis memindahkan kartu di papan Anda. Anda atau PM Anda masih harus menyeretnya ke In Progress atau Done. Itu menjaga kendali alur kerja tetap di tangan manusia.

Membiarkan Devin Bekerja Dari Tiket Jira

Setelah Slack dan Jira terhubung, saya mencoba eksperimen “agen-sebagai-rekan tim” yang sesungguhnya dan melemparkan tiket nyata ke Devin untuk melihat apakah ia dapat mengimplementasikannya tanpa banyak arahan.

Alur kerja yang saya gunakan

Berikut alur kerja saya:

1. Membuat tiket di proyek JIRA yang baru dibuat dan menulis kriteria penerimaan yang jelas.
2. Menambahkan label devin, yang menjadi isyarat bagi Devin untuk menganalisis.
3. Devin berkomentar dengan rencana langkah demi langkah, estimasi kepercayaan diri, dan bertanya, “Mulai sesi?”

4. Saya menjawab " Yes”. Tiket menampilkan “Session started,” dan memberikan tautan web IDE. Saat PR masuk, Devin memposting “Merged ✅” kembali ke Slack, dan saya memindahkan kartu di papan. Tidak ada biaya ACU sampai saya menjawab “Yes.”

Lima tiket nyata, lima hasil yang sangat berbeda

Berikut ringkasan yang terjadi untuk lima tiket nyata:

Hal-hal yang terasa acak

Inilah hal-hal yang perlu ditingkatkan:

• Judul PR: Saya menentukan pola penamaan di setiap prompt, tetapi Devin menciptakan format baru setiap kali.
• Kesetiaan basis data: Pada satu tiket, ia bermigrasi ke Postgres, dan pada tiket lain, ia diam-diam memperkenalkan kembali SQLite.
• Perkiraan ACU: Komentar analisis mengklaim tiket sandpack akan memakan waktu 1,5 ACU, kenyataannya dua sesi dan 5 ACU.
• Kepercayaan vs eksekusi: Tiket dengan kepercayaan rendah dieksekusi dalam 3 menit, dan sempurna. Yang dengan kepercayaan tinggi memakan waktu 45 menit dengan banyak coba-coba.

Devin di Jira menjanjikan: dua tiket ditutup sempurna, satu dengan sedikit dorongan, dan bahkan kasus terburuk hanya menghabiskan waktu, bukan rollback. Namun konsistensinya belum ada, jadi penentuan ruang lingkup yang ketat dan batasan eksplisit adalah sahabat Anda.

Tambahkan Pengujian Otomatis dengan Jest dan Playwright

Dengan obrolan dan tiket yang mengalir, langkah berikutnya adalah memastikan kode yang rusak tidak bisa lolos. Saya meminta dua hal pada Devin: unit test backend dan tes end-to-end Playwright yang meniru pembelajar mengedit latihan di browser.

Unit test backend: mengejutkan mudah

Saya meminta Devin untuk suite tes Jest yang mencakup resolver GraphQL, lapisan layanan, dan model Prisma. Saat saya meminta estimasi ACU, ia menjawab 20 ACU!!

Saya pikir itu pasti kesalahan dan tetap menjalankan tugasnya. Biayanya 1,1 ACU, dan ini dengan mudah menjadi tugas yang dieksekusi paling baik sejauh ini.

Playwright e2e: dinding merah, dinding hijau

Yang ini sedikit lebih mahal dan memakan 2,3 ACU.

Alur yang direkam: buka /learn/option-01 → edit kode → tunggu ✓ → muat ulang halaman → ✓ tetap ada.

Pada percobaan pertama, sekitar 70% asersi gagal. Ada banyak glitch pengubahan ukuran, jumlah dasbor yang usang, dan bahkan jalur bahagia pun flakey.

Terlepas dari perintah “Abaikan tes yang gagal, kita akan perbaiki nanti” di prompt saya, Devin terus menambal kode hingga suite sebagian besar menjadi hijau (berguna, tetapi bukan yang saya minta).

Kita masih memiliki beberapa tes yang gagal karena ada cukup banyak bug di sistem. Tapi itu tidak masalah, nanti kita rapikan agar semua tes ini hijau.

Tambahkan Pipeline GitHub Actions Satu Klik

Dengan unit test dan tes end-to-end yang sudah ada, langkah terakhir adalah memastikan setiap pull request menjalankan pemeriksaan tersebut secara otomatis. Saya meminta Devin untuk workflow dasar, tanpa artefak, tanpa gerbang cakupan, hanya lint → pemeriksaan tipe → tes.

Devin menghadirkan pipeline yang mengejutkan rapi dalam sekali coba, tanpa perlu dorongan lanjutan:

• Tanpa drift konfigurasi: Devin menggunakan kembali skrip npm yang sudah ada, jadi tidak ada tooling baru untuk dipelajari.
• Semuanya paralel: Lint, pemeriksaan tipe, dan dua suite tes berjalan berdampingan, sehingga seluruh workflow selesai dalam ~4 menit di runner gratis GitHub.
• Triage yang jelas: Jika ESLint gagal tetapi pengujian lolos, job ringkasan tetap melaporkan kesalahan lint; Anda tidak pernah melakukan merge kode yang “sebagian merah”.

Devin mendorong workflow, menunggu pemeriksaan selesai di GitHub, dan barulah memutuskan tugasnya selesai. Saya harus bilang, 0,4 ACU untuk pipeline yang sepenuhnya berfungsi sulit ditandingi. YAML jelas adalah tempat bahagia Devin.

Dengan workflow ini di-merge, setiap PR harus lolos lint, kompilasi, dan kedua suite tes sebelum siapa pun menekan tombol hijau!

Wiki Dalam Produk Devin

Devin hadir dengan “Wiki” bawaan yang dapat hidup berdampingan dengan kode Anda. Ini adalah basis pengetahuan ringan yang dihasilkan otomatis yang dapat dibaca dan ditulis oleh agen saat bekerja. Setelah menghubungkan Slack, Jira, dan CI, Wiki ini adalah tempat yang baik untuk catatan arsitektural. Layak dilihat!

Sejauh yang saya tahu, ini tidak dapat diedit secara manual, dan Anda harus mengandalkan Devin untuk menjaga Wiki tetap mutakhir.

Cuplikan Biaya & Waktu dan Refleksi

Setelah semua integrasi, pengujian, dan pipeline aktif, saya menghitung tagihan dan waktu:

Jadi, sekitar 2 jam upaya manusia untuk mendorong tiket, tes, dan CI. Ini lebih cepat daripada yang akan saya lakukan sendiri, tentu saja.

Namun pada titik ini, saya merasa terbelah. Masih ada banyak bug, dan jika saya menulis seluruh codebase sendiri, saya mungkin bisa memperbaiki masalah lebih cepat daripada Devin membakar kredit.

Tetapi Devin menulis sebagian besar aplikasi, jadi agen sebenarnya “mengetahui” strukturnya lebih baik daripada saya. Meski begitu, ia kesulitan mengganti nilai hardcoded dengan yang dinamis, meninggalkan ujung longgar di kode di setiap file, dan memang butuh saya duduk di depan laptop untuk mengawasi semua tindakannya.

Saya juga merasa prosesnya agak membuat frustrasi dan bukan dengan cara yang sama seperti saat mengejar bug yang tidak bisa saya pahami. Ada perbedaan besar (setidaknya bagi saya) antara frustrasi karena kode tidak bekerja dan frustrasi karena agen AI tidak bisa mengikuti beberapa instruksi dasar. Yang terakhir benar-benar membuat kesal.

Saya pikir Devin bisa sangat membantu jika digunakan dengan baik, tetapi seperti setiap agen AI di luar sana, ia tidak bisa menggantikan seorang insinyur perangkat lunak. Tidak apa-apa menggunakannya untuk beberapa tugas, tetapi saya tidak pikir cocok atau berkelanjutan untuk digunakan pada setiap tiket.

Selanjutnya apa?

Kita sudah terhubung ke Slack dan Jira, tes hijau, dan gerbang CI memblokir setiap PR yang ceroboh. Namun untuk peluncuran produksi nyata, kita masih kekurangan empat pilar:

1. Autentikasi: hubungkan kredensial NextAuth → cookie JWT → GqlAuthGuard di NestJS sehingga progres ditautkan ke pengguna asli.
2. Penguatan keamanan: Pelacakan error Sentry di runtime web dan API.
3. Continuous deployment: Pipeline Vercel (web) yang membuat URL pratinjau di setiap branch dan mempromosikan ke prod saat branch utama menjadi hijau.

Itulah agenda untuk Bagian 4, tahap akhir di mana kita mencari tahu apakah Devin dapat mengamankan, mendeploy, dan mengasuh aplikasi dengan hampir tanpa intervensi manusia. Kunci basis data Anda ke Postgres (lagi!), batasi ACU tersebut, dan sampai jumpa di bab terakhir.

Jika Anda siap melanjutkan, klik item daftar terakhir di bawah untuk menuju tutorial keempat:

1. Penyiapan dan Pull Request Pertama (Bagian 1)
2. Mengirimkan Vertical Slice dengan Devin (Bagian 2) 
3. Integrasi, Pengujian, dan CI/CD (Bagian 3) 
4. Keamanan, Deployment, Pemeliharaan (Bagian 4)