डेटा साइंस के लिए वर्ज़न कंट्रोल

डेटा और सॉफ़्टवेयर में आप या आपके सहकर्मी जो भी बदलाव करते हैं, उनका रिकॉर्ड रखना किसी भी प्रोजेक्ट का अहम हिस्सा है, चाहे वह शोध हो, डेटा साइंस हो या सॉफ़्टवेयर इंजीनियरिंग। पूरे प्रोजेक्ट के किसी विशेष संस्करण को संदर्भित या पुनर्प्राप्त कर पाना प्रकाशन से पहले की पुनरुत्पादन क्षमता में मदद करता है, समीक्षक टिप्पणियों का जवाब देते समय, और समीक्षकों, संपादकों और पाठकों को सहायक जानकारी प्रदान करते समय भी।

बदलावों को ट्रैक करने के लिए सबसे अच्छे उपकरण वे वर्ज़न कंट्रोल सिस्टम हैं जो सॉफ़्टवेयर डेवलपमेंट में उपयोग किए जाते हैं, जैसे Git, Mercurial और Subversion। ये यह ट्रैक रखते हैं कि किसी फ़ाइल में क्या बदला गया, कब और किसके द्वारा, और बदलावों को एक केंद्रीय सर्वर के साथ समकालिक करते हैं ताकि कई योगदानकर्ता एक ही फ़ाइल सेट में किए गए बदलावों का प्रबंधन कर सकें।

हालाँकि ये उपकरण बदलावों को ट्रैक करना आसान बनाते हैं, लेकिन इनका सीखना कठिन हो सकता है। इस सीखने की अवस्था को पार करने के लिए दो तरह की सिफारिशें हैं: बदलावों के प्रबंधन के लिए एक व्यवस्थित मैन्युअल तरीका और वर्ज़न कंट्रोल का पूरा उपयोग। आप दूसरे की ओर बढ़ते हुए पहले तरीके का इस्तेमाल कर सकते हैं, या सीधे वर्ज़न कंट्रोल पर काम शुरू कर सकते हैं।

वर्ज़न कंट्रोल के लिए सर्वोत्तम प्रथाएँ

आप अंततः जो भी सिफारिश चुनें, कुछ सामान्य सर्वोत्तम प्रथाएँ हैं जिनका ध्यान रखना चाहिए:

1. मानव द्वारा बनाई गई (लगभग) हर चीज़ का निर्माण होते ही बैकअप लें। इसमें हर प्रकार की स्क्रिप्ट और प्रोग्राम, आपके प्रोजेक्ट पर निर्भर सॉफ़्टवेयर पैकेज, और दस्तावेज़ीकरण शामिल हैं। इस नियम के कुछ अपवाद नीचे चर्चा किए गए हैं।

2. बदलाव छोटे रखें। हर बदलाव इतना बड़ा नहीं होना चाहिए कि बदलावों का ट्रैक रखना बेअसर हो जाए। उदाहरण के लिए, Revise script file जैसा एक ही बदलाव जो कई सौ लाइनों को जोड़ता या बदलता है, संभवतः बहुत बड़ा है, क्योंकि इससे विश्लेषण के अलग-अलग घटकों में हुए बदलावों की अलग-अलग जाँच नहीं हो पाएगी। इसी तरह, बदलावों को बहुत छोटे टुकड़ों में भी नहीं बाँटना चाहिए। सामान्य नियम के तौर पर, एक अच्छे एकल बदलाव का आकार ऐसा संपादन समूह होता है जिसे आप भविष्य में एक कदम में पूर्ववत करना चाहेंगे।

3. बदलाव बार-बार साझा करें। प्रोजेक्ट पर काम कर रहे सभी लोग नियमित रूप से अपने बदलाव साझा करें और दूसरों के बदलाव शामिल करें। व्यक्तिगत शोधकर्ताओं के प्रोजेक्ट रिपॉज़िटरी के संस्करणों को अलग-अलग दिशाओं में न जाने दें, क्योंकि अंतर को मर्ज करने का प्रयास उसके आकार से तेज़ी से बढ़ता है। यह विशेष रूप से नीचे वर्णित मैन्युअल वर्ज़निंग प्रक्रिया के लिए महत्वपूर्ण है, जो एक साथ किए गए, संभवतः परस्पर-विरोधी, बदलावों को मर्ज करने में कोई सहायता नहीं देती।

4. प्रोजेक्ट में किए गए बदलावों को सहेजने और साझा करने के लिए एक चेकलिस्ट बनाएँ, बनाए रखें और उसका उपयोग करें। सूची में स्पष्ट लॉग संदेश लिखना जो किसी भी बदलाव की व्याख्या करें, व्यक्तिगत बदलावों का आकार और सामग्री, कोड के लिए शैली दिशानिर्देश, टू-डू सूचियों को अपडेट करना, और अधूरी या टूटी हुई कोड को कमिट करने पर रोक शामिल होनी चाहिए।

5. प्रत्येक प्रोजेक्ट को शोधकर्ता की कार्य मशीन के बाहर भी परिलक्षित होने वाले किसी फ़ोल्डर में संग्रहीत करें जैसे Dropbox जैसा सिस्टम या GitHub जैसा रिमोट रिपॉज़िटरी। उस फ़ोल्डर को कम से कम दैनिक रूप से सिंक्रोनाइज़ करें। इसमें कुछ मिनट लग सकते हैं, लेकिन जैसे ही लैपटॉप चोरी हो जाए या उसकी हार्ड ड्राइव फेल हो जाए, यह समय वसूला जाता है।

मैन्युअल वर्ज़निंग कैसे अपनाएँ

पहला सुझाया गया तरीका, जिसमें सब कुछ हाथ से किया जाता है, दो अतिरिक्त हिस्से रखता है।

पहला, प्रोजेक्ट के docs सबफ़ोल्डर में CHANGELOG.txt नाम की फ़ाइल जोड़ें, और इस फ़ाइल में उल्टे कालानुक्रमिक क्रम में (यानी, सबसे हाल का पहले) प्रोजेक्ट में हुए बदलावों के दिनांक सहित नोट्स लिखें। यह फ़ाइल लैब नोटबुक के समकक्ष है, और इसमें नीचे दिखाए अनुसार प्रविष्टियाँ होनी चाहिए।

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

दूसरा, जब भी कोई महत्वपूर्ण बदलाव किया गया हो (यानी, जो परिणामों को भौतिक रूप से प्रभावित करता हो), पूरे प्रोजेक्ट की एक प्रति बनाएँ और उसे उस क्षेत्र के भीतर एक सब-फ़ोल्डर में सहेजें जिसका नाम दिनांक को दर्शाता हो और जो सिंक्रोनाइज़ हो रहा है। इस तरीके से प्रोजेक्ट्स कुछ इस तरह व्यवस्थित हो जाते हैं:

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

यहाँ, project_name फ़ोल्डर बाहरी स्टोरेज (जैसे Dropbox) से मैप किया गया है, current वह स्थान है जहाँ काम हो रहा है, और project_name के भीतर अन्य फ़ोल्डर पुराने संस्करण हैं।

मैन्युअल वर्ज़निंग के फायदे और नुकसान

आप अक्सर सुनेंगे, "डेटा सस्ता है, समय महंगा है"। ऊपर बताए गए तरीके की तरह सब कुछ कॉपी करना अपव्ययी लग सकता है, क्योंकि कई फ़ाइलें बदली नहीं होंगी, लेकिन सोचिए: एक टेराबाइट हार्ड ड्राइव का खुदरा मूल्य लगभग $50 है, जिसका मतलब है कि 50 GByte की कीमत $5 से कम है। बशर्ते बड़े डेटा फ़ाइलों को बैकअप क्षेत्र से बाहर रखा जाए (इस पर नीचे और विस्तार से चर्चा की जाएगी), यह तरीका उस समय से भी कम खर्चीला है जो फ़ाइलों को हाथ से चुनकर कॉपी करने में लगेगा।

यह मैन्युअल प्रक्रिया ऊपर उल्लिखित आवश्यकताओं को बिना किसी नए टूल की ज़रूरत के पूरा करती है। हालाँकि, यदि कई शोधकर्ता एक ही प्रोजेक्ट पर काम कर रहे हैं, तो उन्हें समन्वय करना होगा ताकि किसी भी समय किसी विशेष फ़ाइल पर केवल एक ही व्यक्ति काम करे। विशेष रूप से, वे प्रत्येक योगदानकर्ता के लिए एक अलग चेंजलॉग फ़ाइल बनाने और जब भी बैकअप कॉपी बनाई जाए, उन फ़ाइलों को मर्ज करने की इच्छा रख सकते हैं।

वर्ज़न कंट्रोल सिस्टम

ऊपर वर्णित मैन्युअल प्रक्रिया के लिए सबसे अधिक ज़रूरी चीज़ आत्म-अनुशासन है। हमारे दूसरे तरीके का आधार बनने वाले टूल—वही जो हम अपने प्रोजेक्ट्स में इस्तेमाल करते हैं—सिर्फ़ मैन्युअल प्रक्रिया को तेज़ नहीं करते: वे कुछ चरणों को स्वचालित भी करते हैं और कुछ पर अमल कराते हैं, और इस तरह कम आत्म-अनुशासन में अधिक विश्वसनीय नतीजे देते हैं।

आजकल शोध में कौन सा टूल सबसे अधिक इस्तेमाल होता है, यह कहना कठिन है, लेकिन जिसके बारे में सबसे ज़्यादा बात होती है, वह निस्संदेह Git है। इसका बड़ा कारण GitHub है, एक लोकप्रिय होस्टिंग साइट जो Git के माध्यम से सहयोग के लिए तकनीकी ढाँचे को आधुनिक वेब इंटरफ़ेस के साथ जोड़ती है। GitHub सार्वजनिक और ओपन सोर्स प्रोजेक्ट्स के लिए, और शिक्षा व गैर-लाभकारी क्षेत्रों के उपयोगकर्ताओं के लिए मुफ्त है। GitLab एक प्रतिष्ठित विकल्प है जिसे कुछ लोग पसंद करते हैं, क्योंकि GitLab प्लेटफ़ॉर्म स्वयं मुक्त और ओपन सोर्स है। Bitbucket Git और Mercurial दोनों रिपॉज़िटरी के लिए मुफ्त होस्टिंग प्रदान करता है, लेकिन इसके वैज्ञानिक उपयोगकर्ता उतने नहीं हैं।

वर्ज़न कंट्रोल में क्या न रखें

फ़ाइल आकार और प्रारूप

वर्ज़न कंट्रोल सिस्टम के लाभ सभी फ़ाइल प्रकारों पर समान रूप से लागू नहीं होते। विशेष रूप से, फ़ाइल के आकार और प्रारूप पर निर्भर करते हुए ये सिस्टम कम या ज़्यादा फायदेमंद हो सकते हैं।

• पहला, वर्ज़न कंट्रोल सिस्टम में फ़ाइल तुलना सादा टेक्स्ट फ़ाइलों, जैसे सोर्स कोड, के लिए अनुकूलित होती है। आमतौर पर, तथाकथित "डिफ़" देख पाना वर्ज़न कंट्रोल की बड़ी खूबियों में से एक है। दुर्भाग्य से, Microsoft Office फ़ाइलें (जैसे Word द्वारा उपयोग की जाने वाली .docx फ़ाइलें) या अन्य बाइनरी फ़ाइलें, उदाहरण के लिए PDF, वर्ज़न कंट्रोल सिस्टम में संग्रहीत तो की जा सकती हैं, लेकिन एक संस्करण से अगले संस्करण तक के विशिष्ट बदलावों की पहचान करना संभव नहीं होता। इसी तरह सारणीबद्ध डेटा, जैसे CSV फ़ाइलें, भी ऐसे सिस्टम में रखी जा सकती हैं, लेकिन पंक्तियों या स्तंभों के क्रम को बदलने से एक बड़ा बदलाव दिखेगा, भले ही डेटा स्वयं न बदला हो।

• दूसरा, कच्चा डेटा नहीं बदलना चाहिए, और इसलिए उसे वर्ज़न ट्रैकिंग की आवश्यकता नहीं होनी चाहिए। यदि आप कच्चे डेटा और सॉफ़्टवेयर से मध्यवर्ती डेटा फ़ाइलें और अन्य परिणाम पुनः बना सकते हैं, तो उन्हें वर्ज़न कंट्रोल में रखना भी आवश्यक नहीं है। हालाँकि, यदि डेटा और परिणाम छोटे हैं, तो सहयोगियों की आसान पहुँच और संस्करणों के बीच तुलना के लिए उन्हें वर्ज़न करना अनुशंसित है।

• तीसरा, आज के वर्ज़न कंट्रोल सिस्टम मेगाबाइट आकार की फ़ाइलों को संभालने के लिए भी डिज़ाइन नहीं किए गए हैं, गीगाबाइट की तो बात ही छोड़िए, इसलिए बड़े डेटा या परिणाम फ़ाइलों को शामिल नहीं करना चाहिए। ("बड़े" के मानदंड के रूप में, GitHub पर किसी एकल फ़ाइल की सीमा 100MB है।) कुछ उभरते हुए हाइब्रिड सिस्टम, जैसे Git LFS, पाठ्य नोट्स को वर्ज़न कंट्रोल में रखते हैं, जबकि बड़े डेटा को रिमोट सर्वर पर संग्रहीत करते हैं, लेकिन ये अभी इतनी परिपक्व नहीं हैं कि हम इन्हें सुझाएँ।

अनजाने में साझा करना

एक अन्य स्थिति जिसमें वर्ज़न कंट्रोल सिस्टम के लाभ वास्तव में आपके पक्ष में नहीं आते, वह है "अनजाने में साझा करना"। ऐसे शोधकर्ता जो कानूनी प्रतिबंधों के अधीन डेटा से काम कर रहे हैं जो साझा करने से रोकते हैं (जैसे चिकित्सीय डेटा), उन्हें सावधान रहना चाहिए कि वे डेटा को सार्वजनिक वर्ज़न कंट्रोल सिस्टम में न रखें। कुछ संस्थान निजी सिस्टम तक पहुँच प्रदान कर सकते हैं, इसलिए अपने आईटी विभाग से जाँच लेना उचित है।

साथ ही, सुनिश्चित करें कि आप सुरक्षा क्रेडेंशियल्स, जैसे पासवर्ड और प्राइवेट की, अनजाने में ऐसे वर्ज़न कंट्रोल सिस्टम में न रखें जहाँ अन्य लोग उन्हें एक्सेस कर सकें।

यदि आप यह सब आज़माना चाहते हैं, तो कृपया Git for Data Science का हमारा निःशुल्क परिचय देखें।

आभार

यह पोस्ट Greg Wilson, Jennifer Bryan, Karen Cranston, Justin Kitzes, Lex Nederbragt, और Tracy K. Teal द्वारा लिखित "Good enough practices in scientific computing" से ली गई है, https://doi.org/10.1371/journal.pcbi.1005510।