Cara efektif menjaga proyek masa lalu dengan lingkungan pengembangan kerja mereka?

Saya menemukan bahwa setiap kali saya ingin menjalankan proyek masa lalu, akan butuh waktu lama sebelum saya dapat menemukannya dan sebelum saya memiliki segalanya diatur kembali untuk dapat menjalankannya.

Sebagai contoh, saya memiliki proyek python yang saya buat di Linux, dan itu tergantung pada paket perangkat lunak yang mudah diinstal di Linux, namun saya tidak lagi memiliki VM Linux yang saya gunakan. Dan beberapa proyek saya yang lain bergantung pada variabel lain seperti konfigurasi server web, variabel PATH, SDK, IDE, versi OS, perangkat, dll.

Apakah seseorang memiliki cara yang efektif untuk menangani masalah ini? Sampai sekarang saya hanya mementingkan diri sendiri dengan menjaga kode sumber didukung namun sulit membangun kembali lingkungan pengembangan kerja dan juga sulit untuk menjaga lingkungan pengembangan kerja sekitar juga .

Apa yang telah saya lakukan di masa lalu adalah mengubah mesin pengembangan fisik menjadi VM, atau jika sudah menjadi VM, pertahankan untuk penggunaan di masa mendatang. Ini tidak seefisien yang saya inginkan untuk penggunaan ruang disk, tetapi ruang itu murah. Selain itu, proses ini jauh lebih murah daripada waktu untuk mengkonfigurasi ulang lingkungan di masa depan jika diperlukan.

Metodologi favorit saya saat ini adalah mempertahankan skrip yang menginstal SEMUA dependensi yang diperlukan untuk proyek, mengunduh sumber, dan menghubungkan semuanya. Beberapa skrip memiliki dua mode - satu untuk produksi, yang biasanya cukup banyak subset dari mode lain: pengembangan.

Beberapa lingkungan hanya membutuhkan sekitar 5 menit untuk menginstal dengan skrip - dalam hal ini saya menyimpan VM lokal dengan instalasi baru dari OS target yang saya gunakan skrip proyek ketika saya tiba di tempat kerja di pagi hari - dan kemudian melakukan semua pengkodean pekerjaan terkait pada instance VM. Sebelum saya pergi, saya mendorong semua perubahan melalui git ke mesin fisik saya atau repositori pusat kami, dan mengakhiri VM.

Jika lingkungan membutuhkan waktu lebih lama untuk setup (instalasi yang berjalan lama, file besar untuk diunduh, hal seperti itu) Saya melakukan prosedur di atas seminggu sekali.

Keuntungannya adalah sangat mudah untuk digunakan ke mesin baru dan / atau server produksi, semuanya didokumentasikan dalam skrip, dan skrip diverifikasi sangat sering.

Konsep yang Anda gambarkan adalah manajemen konfigurasi. Ini kedengarannya, cara untuk mengidentifikasi, merekam, versi / trek, dan melaporkan suatu lingkungan. Ini sering merupakan tugas yang sangat terkait dengan kontrol versi dan manajemen pembangunan, tetapi cukup berbeda sehingga sering membutuhkan strategi yang terpisah, bahkan jika menggunakan beberapa konsep yang sama dan mekanisme pemrosesan dan penyimpanan yang sama.

Manajemen konfigurasi selain membantu menjaga lingkungan kerja tetap terkendali juga membantu membuat catatan dari berbagai lingkungan kerja di mana perangkat lunak digunakan (pengembangan seperti yang disebutkan, ditambah pengujian / QA, penyebaran ke pelanggan rutin, penempatan ke pelanggan yang memerlukan pertimbangan khusus atau konfigurasi khusus atau membangun properti, dan sebagainya).

Seperti yang saya katakan, seringkali ini adalah tugas yang bertepatan dengan kontrol versi sumber, dan seringkali data manajemen konfigurasi berada di sebelah sumber dalam dokumentasi dan repositori sumber. Tidak harus begitu, tetapi sering kali merupakan masalah kenyamanan.

Otomasi beberapa aspek manajemen konfigurasi sebagian besar telah meningkat dalam beberapa tahun terakhir. Beberapa jawaban dan komentar menyarankan skrip sebagai cara untuk mempromosikan manajemen konfigurasi, dan skrip adalah jawaban yang baik untuk membantu mencapai hasil yang dapat direproduksi, tetapi seringkali skrip yang dibuat sendiri tidak konsisten dan tidak lengkap. Salah satu cara seperti ini telah ditingkatkan adalah melalui penyediaan otomatis. Sistem seperti boneka atau kokimembantu menentukan komponen dan sistem perangkat lunak untuk pengguna atau mesin tertentu atau untuk profil tugas tertentu dan memberikan 'resep' yang memungkinkan pendekatan lepas tangan untuk menyiapkan mesin atau lingkungan yang lengkap. Ini pada dasarnya mengambil konsep repositori distribusi perangkat lunak dan memperluas dan menggeneralisasinya menyediakan tidak hanya paket perangkat lunak yang diperlukan untuk suatu sistem, tetapi juga profil konfigurasi khusus untuk setiap paket sehingga siap digunakan dengan cara yang sesuai dengan Anda situasi.

Vagrant mengambil ini dalam arah yang sedikit berbeda dan menyediakan cara untuk dengan cepat memutar definisi mesin virtual, sehingga VM dapat memiliki perangkat lunak dan perangkat keras virtualnya disediakan secara otomatis, dan dapat membuktikan menjadi cara yang nyaman untuk mereproduksi representasi tertentu dari perangkat keras lingkungan yang digunakan oleh pengguna perangkat lunak Anda.

Setiap sistem (dan variasi) memerlukan sedikit pengaturan, tetapi memiliki nilai yang jelas jika Anda menemukan tugas memuat ulang dan mengonfigurasi ulang menjadi tugas bersama.

Docker akan menjadi pilihan yang bagus. Anda dapat menggunakan dockerfile untuk bertindak sebagai manifes untuk VM yang Anda inginkan. Anda tidak perlu menyimpan gambar apa pun, itu akan mengunduh yang diperlukan. Selain itu, dapat menggunakan gambar Anda sendiri, sehingga Anda bisa membuat gambar dasar Anda sendiri dan kemudian menambahkan komponen yang dibutuhkan oleh lingkungan.

Menggunakan buruh pelabuhan ini juga dapat meningkatkan bagian lain dari alur kerja Anda:

• Lingkungan yang dibuat dapat diletakkan di CVS yang sama dari proyek Anda, yang memberi Anda lingkungan versi (rapi!)
• Buruh pelabuhan dapat digunakan untuk menyediakan lingkungan hidup, menurunkan sakit kepala meluncurkan proyek Anda dalam produksi.
• Jika orang lain mulai bekerja dengan Anda, yang mereka butuhkan adalah dockerfile untuk memuat pengaturan lingkungan yang sangat besar itu.

Jadi ide-ide di sini tentang menggunakan VM hanya sebagian benar, saya tahu bahwa HDD semakin besar dan besar tetapi itu bukan alasan untuk menggunakan semua ruang yang Anda miliki. Juga, ketika lingkungan VM membutuhkan lebih banyak ruang HDD secara internal, ini bisa sedikit rumit dan kemungkinan Anda harus membangunnya kembali. Meskipun ukuran file mungkin tidak menjadi masalah, kecepatan internet masih menjadi penghambat ketika Anda perlu mengirim lebih dari 5Go pada koneksi DSL normal.

Sebagian besar sistem (bahasa, runtime atau sistem operasi) memiliki beberapa cara standar untuk menginstal perangkat lunak dan konfigurasi, jadi cobalah untuk menggunakannya. Seperti:

• Maven atau Gradle untuk Java
• CPAN untuk Perl
• rpm untuk RedHat / Fedora
• dpkg / apt-get untuk Linux
• Paket MSI untuk Windows

Kemudian buat instruksi instalasi yang menjelaskan dengan tepat apa yang perlu diinstal / langkah-langkah apa yang diperlukan:

• Berikan instruksi singkat tentang apa yang Anda anggap diinstal (basis OS, runtime basis seperti Java / Perl / Python ...)
• Tulis skrip pendek yang melakukan instalasi yang diperlukan (idealnya hanya satu invokasi alat seperti Maven)
• Uji ini pada instalasi baru (seperti pada VM)

Maka Anda harus dapat menciptakan kembali lingkungan, dan yang lain juga harus dapat melakukannya (yang mungkin penting jika itu bukan proyek solo).

Anda mungkin perlu menyimpan paket instalasi yang diperlukan di suatu tempat, atau Anda bisa memasukkan instruksi pengunduhan (kecuali jika sistem melacaknya, seperti apt-get atau Maven). Itu tergantung pada seberapa besar Anda mempercayai penyedia paket - mungkin tidak perlu menyimpan paket inti Debian, tetapi dengan beberapa proyek perangkat lunak kecil gratis, mungkin itu ide yang bagus.

Solusi VM juga akan berfungsi, dan mungkin kurang bekerja dalam jangka pendek (simpan saja VM). Namun, saya merasa solusi ini menawarkan lebih banyak fleksibilitas, misalnya ketika mengubah lingkungan.