Saya agak terlambat membahas tentang Remote Development Environments (juga dikenal sebagai Cloud Development Environments). Alasan utamanya adalah karena saya sudah tidak bekerja di tim pengembangan selama lebih dari enam tahun. Namun, saya sekarang bekerja untuk Loft Labs, dan kami memiliki produk Remote Development Environment:   . Saya ingin memahami proposisi nilai kami karena saya akan berada di   untuk mengoperasikan   . DevPod FOSDEM stan DevPod  Masalahnya  Sebagai mantan pengembang, saya ingat betul kesulitan menyiapkan lingkungan pengembangan setiap pengembang. Di awal karier saya, arsitek harus mengonfigurasi mesin pengembangan saya dengan susah payah, sehingga mirip dengan pengaturannya. Kemudian, saya melakukan hal yang sama untuk anggota tim saya berulang kali. Cakupan kemungkinan perbedaan yang memengaruhi pengembangan hampir tak terbatas: Sistem Operasi, tentu saja, versi   rasa SDK,   , Java Eclipse Temurin vs SapMachine, git hooks, dll. Itu adalah keringat, kerja keras, dan darah pada setiap proyek. dan misalnya  Selama bertahun-tahun, saya melihat beberapa pendekatan menarik untuk mereproduksi lingkungan pengembangan. Awalnya, pendekatan tersebut berasal dari VM, lalu dari kontainer. Saya rasa Vagrant adalah alat pertama yang menarik perhatian saya: Saya menghadiri sebuah ceramah pada tahun 2012 di mana pembicara menyebutkan bahwa ia menggunakannya untuk menyiapkan mesin sebelum sesi pelatihannya.  Arsitektur aplikasi telah berevolusi secara signifikan selama bertahun-tahun, menjadi lebih kompleks dan canggih. Bertahun-tahun yang lalu, kemungkinan besar satu-satunya ketergantungan infrastruktur adalah database SQL. Dalam ekosistem JVM, kita beruntung memiliki JDBC, sebuah API yang dapat bekerja di semua database SQL. Yang perlu Anda lakukan hanyalah menulis SQL standar, dan Anda dapat mengonfigurasi instans database saat runtime. Dengan database tertanam seperti   dan   , Anda tidak memerlukan instans Oracle khusus untuk setiap pengembang. Apache Derby H2  Zaman telah berubah. Bukan hal yang aneh jika aplikasi memerlukan database SQL, database NoSQL, kluster Kafka, dan beberapa layanan aplikasi tambahan. Organisasi yang mengembangkan aplikasi semacam itu sudah menggunakan beberapa teknologi terkait kontainer,   Docker atau Kubernetes, untuk mengelola kompleksitas ini. misalnya  Namun, hal itu tidak menyelesaikan masalah awal: bagaimana Anda menyelaraskan IDE, plugin-pluginnya, SDK(s), git hooks, dan yang lainnya? Anda mungkin sudah bisa menebaknya dari judulnya-Remote Development Environments.  Kontainer Pengembangan  Dalam pendahuluan, saya menyebutkan bahwa RDE disebut Cloud Development Environments. Ide utama di balik RDE adalah menyimpan semua yang Anda bisa di Cloud dan membagikannya dengan semua pengembang. Selain itu, Anda ingin RDE berfungsi di seluruh penyedia Cloud yang paling luas dan IDE yang paling umum digunakan. Ketika kebutuhan seperti itu muncul, inilah saatnya bagi para pelaku industri untuk berkumpul di sekitar sebuah standar. Microsoft memprakarsai standar Development Container untuk plugin pengembangan VS Code Remove mereka untuk tujuan yang tepat ini.  Kontainer pengembangan (atau disingkat kontainer dev) memungkinkan Anda menggunakan kontainer sebagai lingkungan pengembangan berfitur lengkap. Kontainer ini dapat digunakan untuk menjalankan aplikasi, memisahkan alat, pustaka, atau runtime yang diperlukan untuk bekerja dengan basis kode, dan membantu dalam integrasi dan pengujian berkelanjutan. Kontainer dev dapat dijalankan secara lokal atau jarak jauh, di cloud pribadi atau publik, dalam berbagai alat dan editor pendukung.  Spesifikasi Kontainer Pengembangan berupaya menemukan cara untuk memperkaya format yang ada dengan pengaturan, alat, dan konfigurasi khusus pengembangan umum sekaligus menyediakan opsi kontainer tunggal yang disederhanakan dan tidak terorkestrasi – sehingga dapat digunakan sebagai lingkungan pengodean atau untuk integrasi dan pengujian berkelanjutan. Di luar metadata inti spesifikasi, spesifikasi tersebut juga memungkinkan pengembang untuk dengan cepat berbagi dan menggunakan kembali langkah-langkah penyiapan kontainer melalui Fitur dan Templat.  --  Apa itu Kontainer Pengembangan?  Berkas konfigurasinya adalah   . Anda dapat menemukan referensi skema   . Produk VS Code, Visual Studio, dan IntelliJ dapat memanfaatkan berkas   . Di sisi penyedia, GitHub Codespaces, CodeSandbox, dan DevPod mendukungnya. devcontainer.json di sini devcontainer.json  Memperkenalkan DevPod    adalah solusi yang memanfaatkan   . Solusi ini menerapkan tiga properti utama: DevPod devcontainer.json  Sumber Terbuka: Tidak terikat pada vendor. 100% gratis dan sumber terbuka, dibuat oleh pengembang untuk pengembang.  Hanya untuk Klien: Tidak perlu pengaturan di sisi server. Unduh aplikasi desktop atau CLI untuk memulai.  Tanpa opini: Lingkungan pengembangan yang dapat diulang untuk infrastruktur apa pun, IDE apa pun, dan bahasa pemrograman apa pun.  DevPod dirancang agar mudah digunakan dan lugas, sehingga mudah digunakan. Saya memutuskan untuk menulis postingan ini karena saya terkesan dengan produk ini dan ingin menata pikiran saya.  Langkah pertama adalah menginstal DevPod itu sendiri. Saya menggunakan Mac; ada resep Homebrew.   brew install devpod  Setelah terinstal, Anda dapat meluncurkannya dari CLI atau GUI. Saya lebih suka GUI, pada awalnya, untuk membantu memahami opsi yang tersedia.   DevPod menawarkan penyedia: lokasi untuk menjalankan kontainer. Docker adalah pilihan default. Anda dapat menambahkan penyedia tambahan, termasuk Penyedia Cloud dan kluster Kubernetes.   Untuk postingan ini, saya akan tetap menggunakan Docker—saya menggunakan OrbStack. Sekarang, ke intinya. Mari kita masuk ke item menu ruang kerja. Jika Anda sudah membuat ruang kerja, ruang kerja tersebut akan muncul di sini. Karena ini kunjungan pertama kita, kita akan membuatnya. Klik tombol btn:[Buat ruang kerja]. Mari kita coba salah satu contoh mulai cepat,   Rust. IDE pilihan saya adalah IntelliJ IDEA, tetapi Anda dapat memilih milik Anda sendiri. Setelah Anda memilih gambar, IDE, dan penyedia, klik Buat Ruang Kerja.  yaitu  Pada titik ini, DevPod akan mengunduh gambar dan membuka proyek yang berjalan di OrbStack di IntelliJ.   Mulai sekarang, kami dapat dengan senang hati mulai mengerjakan proyek Rust kami, yakin bahwa setiap anggota tim menggunakan versi Rust yang sama.  Perhatikan bahwa saat pertama kali Anda menggunakan pengaturan ini, DevPod juga akan mengunduh klien JetBrains. Namun, ini merupakan penundaan pengunduhan satu kali.   Hal yang sama berlaku untuk kait pra-komit Git, misalnya. Jika Anda lebih suka mengembangkan dalam IDE lain, pilih IDE tersebut pada waktu peluncuran, dan Anda sudah siap. Setelah selesai dengan pekerjaan harian Anda, hentikan kontainer. Jika Anda menjalankannya di Cloud, ini menghemat uang. Pada hari berikutnya, lanjutkan kontainer dan lanjutkan pekerjaan Anda.  Kesimpulan  DevPod adalah alat yang bagus di perangkat Anda yang memungkinkan tim pengembangan Anda berbagi konfigurasi mesin yang sama tanpa kesulitan. Dalam posting blog pengantar ini, saya menunjukkan sebagian kecil dari apa yang dapat Anda lakukan. Saya mendorong Anda untuk memanfaatkan kekuatannya jika dihadapkan dengan lingkungan pengembangan yang heterogen.   Untuk melangkah lebih jauh:   Kontainer Pengembangan   DevPod - Lingkungan Pengembangan Sumber Terbuka Sebagai Kode   Gitpod vs. Codespaces vs. Coder vs. DevPod: Perbandingan 2024

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Audio ini diproduksi dalam bahasa asli cerita!

Pengembangan Jarak Jauh Menjadi Mudah dengan DevPod - Alat Sumber Terbuka dan Gratis

About Author

KOMENTAR

HANG TAG

ARTIKEL INI DISAJIKAN PADA

Related Stories

The Priory Ruins

The Magic Shop

PROMISES FULFILLED.

Return to Pleasure Island

The Priory Ruins

The Magic Shop

PROMISES FULFILLED.

Return to Pleasure Island

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps