Veri Bilimi İçin Sürüm Kontrolü

Veri ve yazılım üzerinde sizin veya iş arkadaşlarınızın yaptığı değişiklikleri takip etmek, ister araştırma, ister veri bilimi, ister yazılım mühendisliği olsun, her projenin kritik bir parçasıdır. Tüm projenin belirli bir sürümüne referans verebilmek veya onu geri çağırabilmek; yayın öncesinde tekrarlanabilirliği artırır, hakem yorumlarına yanıt verirken ve hakemlere, editörlere ve okuyuculara destekleyici bilgi sunarken size yardımcı olur.

Değişiklikleri takip etmek için en iyi araçlar, yazılım geliştirmede kullanılan Git, Mercurial ve Subversion gibi sürüm kontrol sistemleridir. Bu sistemler, bir dosyada neyin, ne zaman ve kim tarafından değiştirildiğini takip eder ve birden fazla kişinin aynı dosya kümesi üzerindeki değişiklikleri yönetebilmesi için bu değişiklikleri merkezi bir sunucuyla eşitler.

Bu araçlar değişiklik takibini kolaylaştırsa da, öğrenme eğrileri dik olabilir. Bu öğrenme eğrisini aşmak için iki öneri seti vardır: değişiklikleri yönetmek için sistematik bir manuel yaklaşım ve sürüm kontrolünü tüm gücüyle kullanmak. İlkini uygularken ikincisine doğru ilerleyebilir veya doğrudan sürüm kontrolüne geçebilirsiniz.

En İyi Uygulamalar: Sürüm Kontrolü

Sonunda hangi öneriyi seçerseniz seçin, dikkate almanız gereken bazı genel en iyi uygulamalar ve öneriler vardır:

1. İnsan eliyle oluşturulan (neredeyse) her şeyi oluşturulur oluşturulmaz yedekleyin. Buna her türden betikler ve programlar, projenizin bağımlı olduğu yazılım paketleri ve dokümantasyon dahildir. Bu kurala birkaç istisna aşağıda tartışılacaktır.

2. Değişiklikleri küçük tutun. Her bir değişiklik, değişiklik takibini anlamsız kılacak kadar büyük olmamalıdır. Örneğin, birkaç yüz satır ekleyen veya değiştiren Revise script file gibi tek bir değişiklik muhtemelen çok büyüktür; çünkü bir analizin farklı bileşenlerindeki değişikliklerin ayrı ayrı incelenmesine izin vermez. Benzer şekilde, değişiklikler de fazla küçük parçalara bölünmemelidir. Kaba bir kural olarak, tek bir değişiklik için iyi bir boyut, ileride tek adımda geri almak isteyebileceğinizi hayal edebileceğiniz düzenlemeler grubudur.

3. Değişiklikleri sık paylaşın. Projede çalışan herkes, düzenli olarak başkalarının yaptığı değişiklikleri paylaşmalı ve içeri almalıdır. Bireysel araştırmacıların depo sürümlerinin birbirinden uzaklaşmasına izin vermeyin; çünkü farklılıkları birleştirmek için gereken çaba, farkın boyutundan daha hızlı artar. Bu, özellikle aşağıda açıklanan manuel sürümleme prosedürü için önemlidir; çünkü bu prosedür, eşzamanlı ve muhtemelen çakışan değişiklikleri birleştirmeye herhangi bir destek sağlamaz.

4. Projeye yapılan değişiklikleri kaydetme ve paylaşma için bir kontrol listesi oluşturun, sürdürün ve kullanın. Liste; yapılan değişiklikleri açıkça açıklayan günlük iletileri yazmayı, bireysel değişikliklerin boyutunu ve içeriğini, kod için stil yönergelerini, yapılacaklar listesini güncellemeyi ve yarım kalmış iş veya bozuk kod gönderimini yasaklamayı içermelidir.

5. Her projeyi, araştırmacının çalışma makinesinin dışında yansıtılan bir klasörde saklayın; Dropbox gibi bir sistem veya GitHub gibi uzak bir depo kullanın. Bu klasörü en az günlük olarak eşitleyin. Birkaç dakikanızı alabilir, ancak bir dizüstü bilgisayar çalındığında veya sabit diski bozulduğunda bu süre fazlasıyla karşılığını verir.

Manuel Sürümlemeye Nasıl Yaklaşılır

Her şeyin el ile yapıldığı ilk önerilen yaklaşımın iki ek parçası vardır.

İlk olarak, projenin docs alt klasörüne CHANGELOG.txt adlı bir dosya ekleyin ve bu dosyada projedeki değişikliklerle ilgili tarihli notları ters kronolojik sırayla (yani en yenisi en üstte) tutun. Bu dosya bir laboratuvar defterinin karşılığıdır ve aşağıda gösterilenlere benzer kayıtlar içermelidir.

## 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).

İkinci olarak, önemli bir değişiklik yapıldığında (yani sonuçları maddi olarak etkileyen bir değişiklik), tüm projeyi kopyalayın ve bu kopyayı, senkronize edilen alanda tarihi yansıtan bir ada sahip bir alt klasöre kaydedin. Bu yaklaşım, projelerin aşağıda gösterildiği gibi düzenlenmesiyle sonuçlanır:

.
|-- 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

Burada, project_name klasörü harici depolamaya (Dropbox gibi) eşlenmiştir; current üzerinde çalışılan yerdir ve project_name içindeki diğer klasörler eski sürümlerdir.

Manuel Sürümlemenin Artıları ve Eksileri

"Veri ucuzdur, zaman pahalıdır" sözünü sık sık duyarsınız. Yukarıdaki yaklaşımın önerdiği gibi her şeyi kopyalamak, birçok dosya değişmediği için israf gibi görünebilir; ancak şunu düşünün: bir terabaytlık sabit disk perakendede yaklaşık \$50 tutar, bu da 50 GB'ın 5 $’dan daha ucuza geldiği anlamına gelir. Büyük veri dosyaları yedeklenen alanın dışında tutulduğu sürece (bu konuya aşağıda daha ayrıntılı değinilecektir), bu yaklaşım, kopyalamak için dosyaları el ile seçmekten daha az zamana mal olur.

Bu manuel prosedür, yeni araçlara ihtiyaç duymadan yukarıda belirtilen gereksinimleri karşılar. Ancak birden fazla araştırmacı aynı projede çalışıyorsa, belirli dosyalar üzerinde aynı anda yalnızca tek bir kişinin çalıştığından emin olmak için koordinasyon gerekecektir. Özellikle, her katkıda bulunan için bir değişiklik günlüğü dosyası oluşturmak ve bir yedek kopya oluşturulduğunda bu dosyaları birleştirmek isteyebilirler.

Sürüm Kontrol Sistemleri

Yukarıda açıklanan manuel sürecin en çok gerektirdiği şey öz disiplindir. İkinci yaklaşımımızın temelini oluşturan araçlar —ki kendi projelerimizde bunları kullanıyoruz— yalnızca manuel süreci hızlandırmakla kalmaz: bazı adımları otomatikleştirirken diğerlerini zorunlu kılarak daha güvenilir sonuçlar için daha az öz disiplin gerektirir.

Günümüzde araştırmada en yaygın kullanılan aracın hangisi olduğunu bilmek zor; ancak en çok konuşulanın tartışmasız Git olduğu söylenebilir. Bunun başlıca nedeni, Git ile işbirliği için teknik altyapıyı modern bir web arayüzüyle birleştiren popüler barındırma sitesi GitHub’dır. GitHub, kamuya açık ve açık kaynak projeler ile akademi ve kâr amacı gütmeyen kuruluşlardaki kullanıcılar için ücretsizdir. GitLab, bazı kişilerin tercih ettiği saygın bir alternatiftir; çünkü GitLab platformunun kendisi ücretsiz ve açık kaynaktır. Bitbucket ise hem Git hem de Mercurial depoları için ücretsiz barındırma sunar; ancak bilimsel kullanıcı sayısı o kadar fazla değildir.

Sürüm Kontrolüne Dahil Edilmemesi Gerekenler

Dosya Boyutları ve Biçimleri

Sürüm kontrol sistemlerinin sağladığı faydalar tüm dosya türlerine eşit derecede uygulanmaz. Özellikle, bu sistemler dosya boyutu ve biçimine bağlı olarak daha az veya daha çok verimli olabilir.

• İlk olarak, sürüm kontrol sistemlerinde dosya karşılaştırması düz metin dosyaları (örneğin kaynak kodu) için optimize edilmiştir. Genellikle, sözde "farkları" görebilmek sürüm kontrolünün en büyük nimetlerinden biridir. Ne yazık ki Microsoft Office dosyaları (Word'ün kullandığı .docx dosyaları gibi) veya diğer ikili dosyalar, örneğin PDF'ler, bir sürüm kontrol sisteminde saklanabilse de, bir sürümden diğerine belirli değişiklikleri tespit etmek mümkün değildir. Benzer şekilde, CSV gibi tablo verileri de böyle bir sisteme konabilir; ancak satır veya sütunların sırasının değiştirilmesi, verinin kendisi değişmemiş olsa bile büyük bir değişiklik gibi görünecektir.

• İkinci olarak, ham veriler değişmemelidir ve dolayısıyla sürüm takibi gerektirmez. Ham verilerden ve yazılımdan yeniden üretilebiliyorsa, ara veri dosyalarını ve diğer sonuçları sürüm kontrolüne almak da gerekli değildir. Ancak veri ve sonuçlar küçükse, işbirlikçiler için erişimi kolaylaştırmak ve sürümler arasında karşılaştırma yapabilmek adına bunların sürümlenmesi önerilir.

• Üçüncü olarak, günümüzün sürüm kontrol sistemleri megabaytlar mertebesindeki dosyaları bile verimli şekilde yönetmek için tasarlanmamıştır; gigabaytlar ise hiç değil. Bu nedenle büyük veri veya sonuç dosyaları dahil edilmemelidir. ("Büyük" için bir kıstas olarak, GitHub’da tek bir dosya için sınır 100 MB’tır.) Git LFS gibi ortaya çıkan hibrit sistemler, metinsel notları sürüm kontrolüne alırken büyük verinin kendisini uzak bir sunucuda saklar; ancak bunlar henüz öneride bulunacak kadar olgunlaşmış değildir.

İstemsiz Paylaşım

Sürüm kontrol sistemlerinin faydalarının gerçekten lehinize işlemediği bir diğer durum da "istemsiz paylaşım"dır. Paylaşımı yasaklayan yasal kısıtlamalara tabi verilerle (örneğin tıbbi veriler) çalışan araştırmacılar, verileri herkese açık sürüm kontrol sistemlerine koymamaya dikkat etmelidir. Bazı kurumlar özel sistemlere erişim sağlayabilir; bu nedenle BT biriminizle görüşmeye değer.

Ayrıca, başkaları tarafından erişilebilecek bir sürüm kontrol sistemine parolalar ve özel anahtarlar gibi güvenlik kimlik bilgilerini istemeden yerleştirmediğinizden emin olun.

Tüm bunları denemek isterseniz, lütfen Veri Bilimi için Git’e giriş adlı ücretsiz kursumuza göz atın.

Teşekkür

Bu yazı, Greg Wilson, Jennifer Bryan, Karen Cranston, Justin Kitzes, Lex Nederbragt ve Tracy K. Teal tarafından kaleme alınan "Good enough practices in scientific computing" başlıklı çalışmadan alınmıştır, https://doi.org/10.1371/journal.pcbi.1005510.