Pengembangan Perangkat Lunak dengan Devin: Keamanan, Deployment, Pemeliharaan (Bagian 4)

Selamat datang kembali! Kita hampir sampai: Slack berbunyi, Jira punya tiket, pengujian hijau, dan CI memblokir setiap PR yang ceroboh. Bagian empat adalah dorongan terakhir di mana kita akan mengubah playground fp-ts menjadi sesuatu yang secara teori bisa kita tunjukkan ke publik.

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)

Berikut rencana untuk tutorial keempat ini:

• Auth: Tidak ada lagi UUID anonim; kita akan menambahkan kredensial NextAuth, cookie JWT, dan GqlAuthGuard sehingga progres terikat ke pengguna nyata.
• Pantauan produksi: Satu baris kode Sentry di web app, satu di API Nest, dan setiap pengecualian mendarat di dashboard.
• Deploy sekali klik: Front-end tayang di Vercel dengan URL pratinjau pada setiap PR. (API akan tetap lokal untuk saat ini, kita akan memalsukan produksi dengan Docker.)

Kita juga akan merefleksikan pair programming dengan Devin dan melihat di mana ia unggul dan di mana manusia masih harus merapikan hal-hal sebelum repositori dilihat dunia. Siap untuk etape terakhir?

Dari UUID Anonim ke Pengguna Nyata

Apa yang saya minta Devin lakukan

Singkatnya, saya meminta Devin menyingkirkan alur UUID anonim dan memberikan saya tumpukan auth yang nyata:

• Penyedia kredensial NextAuth v6 di apps/web
• NestJS AuthModule dengan hashing Argon2 dan cookie JWT
• Migrasi Prisma yang menambahkan tabel User dan mengubah Progress.sessionId → userId (non-null)
• Menyalin baris progres UUID yang ada ke pengguna placeholder agar pelajar tetap menyimpan lencana mereka
• Jangan mengganti Postgres dengan SQLite

Hasil yang kembali (sebagian besar bagus)

Berikut ringkasan hasilnya:

Migrasi SQLite lagi

Tebak apa yang saya lihat muncul lagi di kotak pemikiran kecil Devin.

Berhasil bermigrasi dari PostgreSQL ke SQLite untuk pengembangan lokal 🥳

Persis seperti yang saya katakan jangan dilakukan. Skema Prisma ditulis ulang untuk SQLite, dan connection string serta tipe diubah (dari TIMESTAMP menjadi DATETIME). Saya menangkapnya di tengah sesi:

1. Menjeda sesi.
2. git checkout main apps/api/prisma/schema.prisma (mengembalikan skema Postgres).
3. Menghapus file dev.db baru.
4. npm run prisma:migrate --workspace=apps/api untuk menerapkan ulang migrasi Postgres.
5. Melanjutkan Devin; ia mendeteksi revert dan melanjutkan tanpa keluhan.

Kerusakan: 0,8 ACU dan sekitar sepuluh menit.

Daftar perubahan breaking untuk rekan tim

Saya sangat menghargai instruksi yang Devin cantumkan di PR. Di sini ia memberi tahu kami untuk:

# 1  Install new deps
npm install --workspaces

# 2  Run the Postgres migration
npm run prisma:migrate --workspace=apps/api

# 3  Restart everything
npm run dev:api   &   npm run dev:web

Snapshot arsitektur

Di wiki, saya menemukan diagram bermanfaat tentang sistem auth baru kami:

Dengan pengguna nyata yang sudah tersedia dan database kembali mantap di Postgres, akhirnya kita siap melacak progres pelajar yang sesungguhnya, mengirim build pratinjau ke Vercel, dan menangkap error runtime dengan Sentry.

Front-End di Vercel, Tautan Pratinjau pada Setiap PR

Dengan login yang aman, tonggak berikutnya yang jelas adalah menampilkan sesuatu yang bisa diklik ke publik. Kami memutuskan untuk men-deploy hanya front-end Next.js untuk saat ini. API dan Postgres akan tetap di mesin lokal saya sampai kami memilih host yang sesuai anggaran.

Menghubungkan akun secara manual (0 ACU)

Menghubungkan Devin ke akun Vercel pribadi saya melalui integrasi native belum memungkinkan. Jadi saya melakukannya secara manual, lewat dashboard Vercel:

1. Masuk ke Vercel dan klik “New Project → Import Git Repository”.
2. Memilih repo fp-ts-exercises, membiarkan perintah build sebagai npm run build --workspace apps/web, lalu klik Deploy.
3. Menyalin VERCEL_PROJECT_ID dan VERCEL_TOKEN yang dihasilkan ke GitHub Secrets.

Biarkan Devin memperbarui workflow CI (0,4 ACU)

Mengikuti prompt saya, Devin menambahkan satu job di bagian bawah workflow yang ada dan satu langkah shell kecil yang melakukan curl ke URL yang dihasilkan ke Slack:

- name: Deploy to Vercel
  if: ${{ success() && github.event_name == 'pull_request' }}
  run: npx vercel deploy --prod --token ${{ secrets.VERCEL_TOKEN }}
  env:
    VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
    VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}

Hasil

Push cabang → CI hijau → notifikasi Slack:

✅ Preview ready: https://fp-ts-exercises-git-my-branch.vercel.app

Membuka tautan tersebut menampilkan playground kami, alur auth lengkap, dan dashboard pelajar. Belum diperlukan penyesuaian environment di sisi Vercel, karena front-end berbicara ke API lokal saya melalui http://localhost:4000.

Menelusuri Sistem Secrets Devin

Sebelum integrasi dengan Sentry, saya meninjau sistem secrets milik Devin untuk memutuskan apakah saya akan menggunakannya. Devin menyediakan brankas “Secrets” bawaan agar Anda bisa memberikan agen kunci API, URL DB, atau token OAuth tanpa memasukkannya ke Git dan tanpa mengeksposnya di chat. Anggap saja sebagai padanan ringan dari GitHub Actions secrets atau Environment Variables Vercel, tetapi dalam cakupan workspace cloud milik Devin sendiri.

Menambahkan secret

Berikut langkah-langkah yang perlu Anda ikuti untuk menambahkan secret:

1. Buka Team → Secrets di dashboard Devin.
2. Klik “Add Secret” dan masukkan nama (SENTRY_DSN_WEB) serta nilainya.
3. Devin mengonfirmasi penyimpanan; kunci kini tersedia sebagai $.SENTRY_DSN_WEB.

Menggunakan secret dalam sebuah tugas

Tugas: perbarui inisialisasi Sentry API; Setel DSN ke $SECRET.SENTRY_DSN_API

Devin mengganti nilainya saat menulis main.ts. Di tab shell, Anda akan melihat DSN literal, tetapi log chat menyamarkannya.

Kelebihan dan kekurangan

Kelebihan:

• Tidak ada risiko bocornya kunci ke PR atau log Timelapse.
• Secrets berskala organisasi berfungsi lintas sesi: unggah sekali, digunakan berkali-kali.
• Biaya kredit nol untuk menyimpan atau mengambil.

Kekurangan:

• Kunci tidak tersedia secara lokal kecuali Anda menyalinnya ke .env. Pengujian di luar Devin memerlukan penyiapan manual.
• Tidak ada cakupan per lingkungan (mis., “hanya di produksi”). Semua sesi mendapatkan semua secrets.

Kapan menggunakannya

Saya merasa lebih mudah menggunakan brankas Devin ketika Devin sendiri yang membutuhkan kunci (mis., push ke Vercel, mengakses registry privat, atau memasang Sentry saat build). Saya akan tetap menggunakan .env / GitHub Actions secrets untuk segala hal yang juga berjalan di shell dev lokal Anda atau runner CI.

Integrasi Devin dengan Sentry

Berikut prompt yang saya gunakan: Tambahkan Sentry ke kedua app sehingga setiap pengecualian muncul di dashboard saya. Gunakan variabel environment di .env. Jangan ada perubahan perilaku lain.”

Pekerjaan Devin (0,6 ACU, satu sesi)

Berikut ringkasan hasilnya:

Langkah manual saya

Berikut langkah yang saya ambil:

1. Menyalin DSN dari proyek Sentry saya ke .env.
2. Merestart kedua server dev.
3. Mengakses http://localhost:4000/graphql dengan query yang sengaja buruk untuk memeriksa apakah berfungsi. Sebuah isu muncul di Sentry dalam hitungan detik.

Mengapa saya melewatkan fitur secrets Devin

Ini alasan saya melewatkan fitur secrets Devin:

• Model mental lebih sederhana: file .env yang sama di mana-mana.
• Lebih mudah menjalankan build pratinjau di Vercel (variabel env tersebut sudah disetel di sana).
• Tidak ada pemborosan ACU untuk operasi secret-store.

Refleksi: Di Mana Devin Unggul dan Di Mana Ia Tersandung

Empat bagian tutorial lalu, repo ini hanyalah tumpukan latihan fp-ts berdebu—sekarang, repo ini memiliki:

• Codebase termodernisasi: Dependensi terbaru, konfigurasi TS ketat, aturan lint & Prettier (Bagian 1).
• Playground berbasis browser: Next.js 14 + editor Sandpack dengan umpan balik Vitest langsung (Bagian 2).
• Backend NestJS + Postgres: API GraphQL, migrasi Prisma, pelacakan progres anonim → JWT (Bagian 2 & 4).
• Pipeline hijau: Workflow CI yang lint, cek tipe, menjalankan Jest & Playwright, dan memblokir setiap PR gagal (Bagian 3).
• Integrasi tim: Notifikasi status Slack, analisis label Jira, dan URL pratinjau pada setiap branch (Bagian 3).
• Observabilitas produksi: Sentry terpasang di web dan API, menangkap setiap pengecualian (Bagian 4).
• Deploy pratinjau: Vercel memutar URL yang bisa dibagikan untuk setiap pull request (Bagian 4).

Kami menghabiskan sekitar ≈ 70 ACU total (~$157 pada paket Core) dan sekitar dua hari kerja untuk tinjauan langsung.

Apa yang Devin lakukan dengan sangat baik

Berikut area di mana menurut saya Devin sangat bagus:

Di mana manusia masih mengungguli agen

Berikut area di mana menurut saya Devin masih perlu peningkatan:

Pendapat saya

Dokumentasi Devin sendiri tidak pernah menjanjikan pembuat produk. Mereka menguraikan area unggulan yang jauh lebih sempit, dan jika dipikir ulang, saya seharusnya tetap berada di dalamnya. Halaman resmi “Apa kekuatan Devin?” mencantumkan empat penggunaan utama:

Dokumentasi menyebut pengembangan fitur yang mencakup UI, API, dan alur data sebagai “eksperimental”. Ini digambarkan sebagai tugas besar, terbuka, di mana agen mungkin “memerlukan peninjauan dan iterasi manusia yang signifikan.” Inilah yang persis kami lihat ketika Sandpack meng-hardcode tes atau ketika dashboard terlihat bagus tetapi sebenarnya tidak menghitung data.

Jadi, sebagai aturan praktis:

Gunakan Devin untuk apa pun yang bisa diotomatisasi oleh developer senior dengan skrip, dan tetap pegang kendali untuk tugas yang membutuhkan kepekaan produk.

Kesimpulan

Kita telah mencapai akhir dari tutorial empat bagian:

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)

Berikut beberapa langkah lanjutan yang bisa kita ambil dari sini:

1. Meng-host API agar build pratinjau (dan pengguna di masa depan) mengakses backend nyata.
2. Memastikan fungsi inti berjalan dan memperbaiki 30 bug yang saya tahu ada di sana
3. Memoles UI
4. Menambahkan lebih banyak konten dan latihan
5. Rilis untuk digunakan orang!

Jika Anda mengikuti jalur yang sama, ingat: Anda bisa membiarkan agen menuang beton, tetapi Anda tetap harus merancang rumahnya. Selamat ngoding!