Version Control untuk Data Science

Melacak perubahan yang Anda atau kolaborator Anda lakukan pada data dan perangkat lunak adalah bagian krusial dari proyek apa pun, baik itu riset, data science, maupun rekayasa perangkat lunak. Kemampuan untuk merujuk atau mengambil versi tertentu dari seluruh proyek membantu reproduksibilitas bagi Anda menjelang publikasi, saat menanggapi komentar peninjau, dan saat menyediakan informasi pendukung bagi peninjau, editor, serta pembaca.

Alat terbaik untuk melacak perubahan adalah sistem version control yang digunakan dalam pengembangan perangkat lunak, seperti Git, Mercurial, dan Subversion. Alat-alat ini mencatat apa yang diubah dalam sebuah file, kapan, dan oleh siapa, serta menyinkronkan perubahan ke server pusat sehingga banyak kontributor dapat mengelola perubahan pada kumpulan file yang sama.

Meskipun alat ini mempermudah pelacakan perubahan, kurva belajarnya bisa terjal. Untuk mengatasinya, ada dua set rekomendasi: pendekatan manual yang sistematis untuk mengelola perubahan dan version control dalam wujud lengkapnya; Anda bisa menggunakan yang pertama sambil menuju yang kedua, atau langsung terjun ke version control.

Praktik Terbaik untuk Version Control

Apa pun rekomendasi yang akhirnya Anda pilih, ada beberapa praktik terbaik atau rekomendasi umum yang sebaiknya Anda perhatikan:

1. Cadangkan (hampir) semua yang dibuat oleh manusia segera setelah dibuat. Ini mencakup skrip dan program dari segala jenis, paket perangkat lunak yang menjadi dependensi proyek Anda, dan dokumentasi. Beberapa pengecualian terhadap aturan ini dibahas di bawah.

2. Jaga agar perubahan tetap kecil. Setiap perubahan tidak boleh terlalu besar hingga membuat pelacakan perubahan menjadi tidak relevan. Misalnya, satu perubahan seperti Revise script file yang menambah atau mengubah ratusan baris kemungkinan terlalu besar, karena tidak memungkinkan perubahan pada komponen analisis yang berbeda diselidiki secara terpisah. Demikian pula, perubahan tidak boleh dipecah menjadi bagian yang terlalu kecil. Sebagai patokan, ukuran yang baik untuk satu perubahan adalah sekumpulan suntingan yang bisa Anda bayangkan ingin dibatalkan dalam satu langkah pada suatu waktu di masa mendatang.

3. Bagikan perubahan secara berkala. Semua orang yang mengerjakan proyek harus rutin berbagi dan menggabungkan perubahan dari orang lain. Jangan biarkan versi repositori proyek milik tiap peneliti menyimpang satu sama lain, karena upaya untuk menggabungkan perbedaan meningkat lebih cepat daripada ukuran perbedaannya. Ini sangat penting untuk prosedur versi manual yang dijelaskan di bawah, yang tidak menyediakan bantuan untuk menggabungkan perubahan simultan yang mungkin saling bertentangan.

4. Buat, pelihara, dan gunakan daftar periksa untuk menyimpan dan berbagi perubahan pada proyek. Daftar tersebut harus mencakup penulisan pesan log yang menjelaskan perubahan dengan jelas, ukuran dan isi perubahan individual, pedoman gaya untuk kode, pembaruan daftar tugas, serta larangan meng-commit pekerjaan yang setengah jadi atau kode yang rusak.

5. Simpan setiap proyek dalam folder yang dicerminkan dari mesin kerja peneliti menggunakan sistem seperti Dropbox atau repositori jarak jauh seperti GitHub. Sinkronkan folder tersebut setidaknya setiap hari. Ini mungkin memakan beberapa menit, tetapi waktu itu akan terbayar saat laptop dicuri atau hard disk gagal.

Cara Menerapkan Versi Manual

Pendekatan pertama yang disarankan, di mana semuanya dilakukan secara manual, memiliki dua bagian tambahan.

Pertama, tambahkan file bernama CHANGELOG.txt ke subfolder docs proyek, dan buat catatan bertanggal tentang perubahan pada proyek di file ini dalam urutan kronologis terbalik (yaitu yang terbaru di atas). File ini setara dengan buku catatan laboratorium, dan harus berisi entri seperti yang ditunjukkan di bawah.

## 2016-04-08

* Switched to cubic interpolation as default.
* Moved question about family's TB history to end of questionnaire.

## 2016-04-06

* Added option for cubic interpolation.
* Removed question about staph exposure (can be inferred from blood test results).

Kedua, salin seluruh proyek setiap kali terjadi perubahan signifikan (yaitu yang secara material memengaruhi hasil), dan simpan salinan tersebut di subfolder yang namanya mencerminkan tanggal di area yang disinkronkan. Pendekatan ini menghasilkan pengorganisasian proyek seperti ditunjukkan di bawah:

.
|-- project_name
|   -- current
|       -- ...project content as described earlier...
|   -- 2016-03-01
|       -- ...content of 'current' on Mar 1, 2016
|   -- 2016-02-19
|       -- ...content of 'current' on Feb 19, 2016

Di sini, folder project_name dipetakan ke penyimpanan eksternal (seperti Dropbox), current adalah tempat pekerjaan dilakukan, dan folder lain di dalam project_name adalah versi lama.

Kelebihan dan Kekurangan Versi Manual

Anda sering mendengar "Data itu Murah, Waktu itu Mahal". Menyalin semuanya seperti yang disarankan pendekatan di atas mungkin tampak boros, karena banyak file tidak akan berubah, tetapi pertimbangkan: hard disk berkapasitas satu terabita berharga sekitar \$50 di ritel, yang berarti 50 GByte berharga kurang dari $5. Selama file data berukuran besar disimpan di luar area yang dicadangkan (ini akan dibahas lebih lanjut di bawah), pendekatan ini biayanya lebih rendah daripada waktu yang diperlukan untuk memilih file satu per satu untuk disalin.

Prosedur manual ini memenuhi kebutuhan yang diuraikan di atas tanpa memerlukan alat baru. Namun, jika beberapa peneliti mengerjakan proyek yang sama, mereka harus berkoordinasi agar hanya satu orang yang mengerjakan file tertentu pada satu waktu. Secara khusus, mereka mungkin ingin membuat satu file changelog per kontributor, dan menggabungkan file-file tersebut setiap kali salinan cadangan dibuat.

Sistem Version Control

Yang paling dibutuhkan dari proses manual di atas adalah disiplin diri. Alat yang menopang pendekatan kedua kami —yang kami gunakan dalam proyek kami sendiri— tidak hanya mempercepat proses manual: alat ini juga mengotomatiskan beberapa langkah sambil menegakkan langkah lainnya, sehingga membutuhkan lebih sedikit disiplin diri untuk hasil yang lebih andal.

Sulit mengetahui alat mana yang paling banyak digunakan dalam riset saat ini, tetapi yang paling sering dibicarakan tak diragukan lagi adalah Git. Ini sebagian besar karena GitHub, situs hosting populer yang menggabungkan infrastruktur teknis untuk kolaborasi melalui Git dengan antarmuka web modern. GitHub gratis untuk proyek publik dan sumber terbuka serta untuk pengguna di lingkungan akademik dan nirlaba. GitLab adalah alternatif yang dihargai dan disukai sebagian orang, karena platform GitLab itu sendiri gratis dan sumber terbuka. Bitbucket menyediakan hosting gratis untuk repositori Git dan Mercurial, tetapi tidak memiliki sebanyak itu pengguna di komunitas ilmiah.

Apa yang Tidak Perlu Dimasukkan ke Version Control

Ukuran dan Format File

Manfaat sistem version control tidak berlaku sama untuk semua jenis file. Secara khusus, sistem ini bisa lebih atau kurang bermanfaat bergantung pada ukuran dan format file.

• Pertama, perbandingan file dalam sistem version control dioptimalkan untuk file teks biasa, seperti kode sumber. Biasanya, kemampuan untuk melihat "diff" adalah salah satu kenikmatan besar dari version control. Sayangnya, meskipun file Microsoft Office (seperti file .docx yang digunakan Word) atau file biner lainnya, misalnya PDF, dapat disimpan dalam sistem version control, tidak mungkin untuk menelusuri perubahan spesifik dari satu versi ke versi berikutnya. Data berbentuk tabel, seperti file CSV, juga dapat dimasukkan ke dalam sistem semacam itu, tetapi mengubah urutan baris atau kolom akan menimbulkan perubahan besar, meskipun datanya sendiri tidak berubah.

• Kedua, data mentah seharusnya tidak berubah, dan karenanya tidak memerlukan pelacakan versi. Menyimpan file data antara dan hasil lainnya dalam version control juga tidak perlu jika Anda dapat meregenerasinya dari data mentah dan perangkat lunak. Namun, jika data dan hasil berukuran kecil, disarankan untuk mem-versioning-nya demi kemudahan akses oleh kolaborator dan untuk perbandingan lintas versi.

• Ketiga, sistem version control saat ini tidak dirancang untuk menangani file berukuran megabita, apalagi gigabita, sehingga file data atau hasil yang besar sebaiknya tidak disertakan. (Sebagai tolok ukur untuk "besar", batas untuk satu file di GitHub adalah 100MB.) Beberapa sistem hibrida yang mulai bermunculan seperti Git LFS menempatkan catatan tekstual di bawah version control, sementara data besar itu sendiri disimpan di server jarak jauh, tetapi sistem-sistem ini belum cukup matang untuk kami rekomendasikan.

Berbagi secara Tidak Sengaja

Kasus lain di mana manfaat sistem version control tidak benar-benar menguntungkan Anda adalah kasus "berbagi secara tidak sengaja". Peneliti yang menangani data yang tunduk pada pembatasan hukum yang melarang pembagian (seperti data medis) harus berhati-hati untuk tidak menaruh data di sistem version control publik. Beberapa institusi mungkin menyediakan akses ke sistem privat, jadi ada baiknya memeriksa ke departemen TI Anda.

Selain itu, pastikan Anda tidak secara tidak sengaja menempatkan kredensial keamanan, seperti kata sandi dan kunci privat, dalam sistem version control tempat orang lain mungkin dapat mengaksesnya.

Jika Anda ingin mencoba semua ini, silakan lihat pengantar Git untuk Data Science gratis kami.

Ucapan Terima Kasih

Tulisan ini diambil dari "Good enough practices in scientific computing" oleh Greg Wilson, Jennifer Bryan, Karen Cranston, Justin Kitzes, Lex Nederbragt, dan Tracy K. Teal, https://doi.org/10.1371/journal.pcbi.1005510.