गेरिट कोड की समीक्षा: चित्रों के साथ एक त्वरित गाइड

रेड एंड ब्लू चेयर गेरिट रिटवेल्ड (1918) द्वारा

बुश के पास C / C ++ प्रोग्रामर विभाग है। विभाग काफी छोटा है, और इसलिए इसके कर्मचारी आमतौर पर अलग-अलग परियोजनाओं पर काम करते हैं, जो केवल असाधारण मामलों में अंतर करते हैं।

इस स्थिति के नकारात्मक परिणामों में से एक बस कारक है , जो एक को जाता है। इसे और अन्य समस्याओं को हल करने के लिए, प्रयोगात्मक रूप से एक कोड समीक्षा प्रणाली (Eng। कोड समीक्षा) शुरू करने का निर्णय लिया गया था: एक डेवलपर को दूसरे के लिए ऑडिटर के रूप में नियुक्त करें और इस तरह उसे कोड से परिचित कराएं, और उसी समय उत्तरार्द्ध की गुणवत्ता में सुधार करें।

कोड संशोधन प्रणाली के लिए बुनियादी आवश्यकताओं का गठन किया गया था:

• स्थानीय स्थापना;
• स्थापना और प्रशासन के लिए न्यूनतम प्रयास;
• अधिकतम प्रयोज्य;
• परियोजनाओं तक पहुंच का भेदभाव;
• समर्थन प्राप्त करें
• नि: शुल्क (इस परियोजना की प्रयोगात्मक स्थिति के कारण)।

कई विकल्पों पर विचार करने के बाद ( Rietveld , ReviewBoard , Gerrit ), हमें यह प्रतीत हुआ कि जेरिट को स्थापित करना और काम के लिए तैयार करना सबसे आसान है। इसलिए, हमने इस प्रणाली के उपयोग पर एक छोटा गाइड तैयार करने का निर्णय लिया।

इतिहास का दौरा

जैसा कि अक्सर खुले स्रोत की दुनिया में होता है, गेरिट एक अन्य परियोजना के लिए पैच के एक सेट के रूप में दिखाई दिए। मूल लक्ष्य पाइथन लेखक गुइडो वैन रोसुम (डच: गुइडो वैन रोसुम ) द्वारा पायथन में लिखे गए कोड रिविजन सिस्टम, रिटवल्ड में एसीएल समर्थन को जोड़ना था। इस तथ्य के कारण कि गुइडो रीइटवेल्ड कोड को जटिल नहीं करना चाहते थे, बाद का एक कांटा फेरिट नाम के तहत दिखाई दिया।

गेरिट को बाद में पायथन से जावा में फिर से लिखा गया और इस तरह पूरी तरह से स्वतंत्र परियोजना बन गई। वर्तमान में, Gerrit ईबे, Sony, Couchbase, MediaWiki, Rockbox, और Qt जैसी कंपनियों और परियोजनाओं का उपयोग करता है, लेकिन सबसे प्रसिद्ध Gerrit उपयोगकर्ता शायद एक Android विकास परियोजना है जिसके लिए गेरिट और लिखा गया था।

वैसे, यहां आप परियोजना के नाम का स्पष्टीकरण पा सकते हैं: http://en.wikipedia.org/wiki/Gerrit_Rietveld ।

कार्य सिद्धांत

गेरिट विकास इस प्रकार है:

• गेरिट में एक रिपॉजिटरी बनाई गई है;
• डेवलपर Gerrit से रिपॉजिटरी को क्लोन करता है (या किसी मौजूदा प्रोजेक्ट में git रिमोट जोड़ता है);
• गिट पुश का उपयोग करके , डेवलपर रिपॉजिटरी की एक विशेष शाखा में कोड को संशोधित करने के लिए परिवर्तन भेजता है;
• गेरिट प्रत्येक परिवर्तन रिकॉर्ड के लिए एक अलग "टिकट" बनाता है, जिस पर ऑडिटर टिप्पणी कर सकता है, लागू कर सकता है या अस्वीकार कर सकता है।

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

स्थापना और सेटअप

गेरिट वितरण को WAR संग्रह के रूप में वितरित किया जाता है, इसलिए इसे स्थापित करना काफी सरल दिखता है: एक डेटाबेस बनाएं (MySQL, PostgreSQL और एम्बेडेड H2 समर्थित हैं), उपयोगकर्ता को सिस्टम में जोड़ें, साइट को इनिशियलाइज़ करें और वेब सर्वर को कॉन्फ़िगर करें। सगाई परंपरागत रूप से nginx का उपयोग करती है, इसलिए हमने इसे कॉन्फ़िगर किया है। Nginx.conf में, यह कुछ इस तरह दिखता है:

server { listen 80; server_name gerrit; rewrite ^(.*) https://$server_name$1 permanent; } server { listen 443; server_name gerrit; add_header Strict-Transport-Security max-age=15768000; ssl on; ssl_certificate /local/nginx/conf/cert/gerrit.crt; ssl_certificate_key /local/nginx/conf/cert/gerrit.key; ssl_session_timeout 5m; ssl_session_cache shared:SSL:1m; ssl_protocols TLSv1; ssl_ciphers HIGH:!ADH; ssl_prefer_server_ciphers on; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header Host $host; auth_basic "Restricted"; auth_basic_user_file htpasswd; } } 

इंस्टॉलेशन में डॉक्यूमेंटेशन का विस्तार से वर्णन किया गया है , इसलिए हम विवरण में नहीं जाते हैं, इसके बजाय हम सीधे गेरिट वेब इंटरफेस के विवरण पर जाएंगे।

यह पहला जेरिट पृष्ठ प्रारंभिक स्थापना के ठीक बाद जैसा दिखता है:



यह कहने का समय है कि गेरिट वर्तमान में किसी भी स्थानीय प्राधिकरण का समर्थन नहीं करते हैं। OpenID, HTTP बेसिक / डाइजेस्ट ऑथेंटिकेशन एंड कंप्यूटर एसोसिएट्स साइटमाइंडर (एक वाणिज्यिक "सिंगल साइन-ऑन" समाधान), और उस सभी के लिए समर्थन है। बाहरी प्राधिकरण का उपयोग करने का निर्णय खुली भागीदारी वाली परियोजनाओं के लिए काफी तर्कसंगत है, लेकिन हमारे मामले में HTTP प्रामाणिक एकमात्र संभव विकल्प है, बावजूद इसके संदिग्ध सुविधा के बावजूद।

गेरिट से शुरुआत की

एसएसएच के लिए ई-मेल और एक सार्वजनिक कुंजी जोड़कर सिस्टम में पंजीकरण करने के बाद, आप काम कर सकते हैं।

सबसे पहले आपको जेरिट में एक नई परियोजना बनाने की आवश्यकता है। दुर्भाग्य से, वेब इंटरफ़ेस के माध्यम से ऐसा करने का कोई तरीका नहीं है। लेख लिखने की प्रक्रिया में, गेरिट 2.3 जारी किया गया था, जिसमें यह चूक तय हो गई थी और आखिरकार, आप सीधे वेब इंटरफ़ेस से एक नया रिपॉजिटरी बना सकते हैं: Admin \ Projects \ Create नई परियोजना:



प्रोजेक्ट निर्माण फॉर्म में, आप तुरंत चुन सकते हैं कि कौन से अधिकार विरासत में मिले - यह विशिष्ट अधिकारों के साथ प्रोजेक्ट बनाते समय उपयोगी है। डिफ़ॉल्ट रूप से, सामान्य अधिकार ( ऑल-प्रोजेक्ट ) विरासत में मिले हैं।

आप अतिरिक्त परियोजना सेटिंग्स भी निर्दिष्ट कर सकते हैं:



कंसोल पर जाएं और सीधे Git के साथ काम करने के लिए:

 $ git clone ssh://gerrit:29418/test_project.git Cloning into test_project... warning: remote HEAD refers to nonexistent ref, unable to checkout. 

चेतावनी को नजरअंदाज किया जा सकता है, यह काफी उचित है (रिपॉजिटरी में कोई संशोधन नहीं है), लेकिन हमारे लिए यह पूरी तरह से बेकार है। 29418 के अजीब बंदरगाह पर आश्चर्यचकित न हों - गेरिट का अपना एसएसएच सर्वर है और जीआईटी (जावा में जेटिट) का अपना कार्यान्वयन है।

पहली फ़ाइल और कोड का पहला संशोधन बनाएँ:

 $ cd test_project $ echo “test” > README $ git add README $ git commit README -m “first commit” [master (root-commit) b1f69cf] first commit 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 README 

सभी परियोजनाओं के लिए डिफ़ॉल्ट अधिकार कोड संशोधन प्रणाली को दरकिनार करते हुए सर्वर में बदलाव करने की अनुमति नहीं देते हैं, इसलिए इस स्तर पर कमांड `गिट पुश ऑरिजनल मास्टर` निम्न त्रुटि के साथ समाप्त होगा:

 $ git push origin master Counting objects: 3, done. Writing objects: 100% (3/3), 224 bytes, done. Total 3 (delta 0), reused 0 (delta 0) To ssh://gerrit:29418/test_project.git ! [remote rejected] master -> master (can not create new references) error: failed to push some refs to 'ssh://gerrit:29418/test_project.git' 

और यह सही है, क्योंकि हमारा लक्ष्य यह सुनिश्चित करना है कि ऑडिटर हमेशा कोड की समीक्षा और अनुमोदन करता है। इसलिए, आपको निम्नानुसार सर्वर में परिवर्तन भेजने की आवश्यकता है:

 $ git push origin HEAD:refs/for/master Counting objects: 3, done. Writing objects: 100% (3/3), 224 bytes, done. Total 3 (delta 0), reused 0 (delta 0) remote: remote: New Changes: remote: https://gerrit/337 remote: To ssh://gerrit:29418/test_project.git * [new branch] HEAD -> refs/for/master 

यह ध्यान दिया जाना चाहिए कि कमांड सिंटैक्स, इसे हल्के ढंग से रखने के लिए, सबसे सुविधाजनक नहीं है। हालाँकि, यह आसानी से निम्नलिखित सेटिंग के साथ तय किया गया है:

 $ git config branch.master.merge refs/for/master 

अब परिवर्तन को सर्वर पर सफलतापूर्वक भेज दिया गया था, लेकिन यह अभी रिपॉजिटरी को नहीं मिला। इसके बजाय, सर्वर पर पहचानकर्ता 337 के साथ एक परिवर्तन किया गया था, जिसे गेरिट वेब इंटरफेस के माध्यम से देखा और अनुमोदित किया जा सकता है (गेरिट आउटपुट में लिंक पर ध्यान दें):



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

स्वाभाविक रूप से, आप प्रत्येक परिवर्तन में टिप्पणियां जोड़ सकते हैं, यह समीक्षा पृष्ठ पर किया जाता है - चलो इस पर चलते हैं।



यहां आप सीधे परिवर्तन आकलन प्रपत्र देख सकते हैं। कृपया ध्यान दें कि इस चित्र में 5 (-2 / -1 / 0 / + 1 / + 2) में से केवल 3 (-1 / 0 / + 1) संभावित रेटिंग हैं। यह इसलिए हुआ क्योंकि हमारे परीक्षण उपयोगकर्ता फिलिप जे। फ्राई के पास इस परियोजना पर एक वोट नहीं है।

रेटिंग -1 / + 1 में एक अनुशंसात्मक स्थिति है, वे परिवर्तन की स्वीकृति या अस्वीकृति को प्रभावित नहीं करते हैं, इसलिए, डिफ़ॉल्ट रूप से, सभी पंजीकृत उपयोगकर्ताओं को उन्हें डालने का अधिकार है। निर्णायक -2 और +2 की रेटिंग हैं (नहीं, -1 / + 1 को संक्षेप में प्रस्तुत नहीं किया गया है, लेकिन यह स्वचालित स्क्रिप्ट का उपयोग करके किया जा सकता है) - +2 की कोई भी रेटिंग आपको परिवर्तन को लागू करने की अनुमति देती है, -2 की कोई भी रेटिंग परिवर्तन को रोक देती है और जब तक इसे लागू नहीं किया जा सकता है। इसका निष्कासन (किसी संख्या +2 की उपस्थिति के बावजूद)। प्रलेखन में मतदान प्रणाली का विस्तृत विवरण है।

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



इसके बाद, नए परीक्षण समीक्षकों के समूह को इस परियोजना में परिवर्तनों को स्वीकार करने या अस्वीकार करने का अधिकार दिया जाना चाहिए। प्रोजेक्ट टैब में, हमारी परियोजना, एक्सेस टैब चुनें, फिर संपादन बटन पर क्लिक करें:



इस पृष्ठ पर आप अधिकारों और उनके मापदंडों को बदल सकते हैं। हमारे मामले में, हम टेस्ट समीक्षकों को -2 से +2 तक रेटिंग ( लेबल कोड-समीक्षा ) देने का अधिकार देते हैं, और यह अधिकार परियोजना की सभी शाखाओं तक फैला हुआ है। उसी समय, हम उसी समूह को परिवर्तन लागू करने का अधिकार देंगे ( सबमिट करें )। नए विशेषाधिकार जोड़ने के बाद, हम परिवर्तन पृष्ठ पर लौटते हैं। अब यह अधिक विकल्प प्रदर्शित करता है:



जैसा कि आप देख सकते हैं, सबसे पहले, हमारे उपयोगकर्ता के पास अब परिवर्तन का कोई भी मूल्यांकन देने का अवसर है, जिसमें निर्णायक +2 और -2 भी शामिल है । और दूसरी बात, प्रकाशित करें और सबमिट करें बटन दिखाई दिया है, जो हमारे उपयोगकर्ता को परिवर्तन को लागू करने की अनुमति देता है।

विशेषाधिकार प्रणाली

गेरिट में एक जटिल विशेषाधिकार प्रणाली है। प्रत्येक विशेषाधिकार उपयोगकर्ताओं के एक समूह (या समूहों) को दिया जा सकता है, और एक ही समय में अपनी कार्रवाई की त्रिज्या को रिपॉजिटरी की एक विशेष शाखा के ढांचे में सीमित कर देता है। उसी समय, व्यवस्थापक नए विशेषाधिकार बना सकते हैं ( प्रलेखन कॉपीराइट की जाँच के साथ एक उदाहरण प्रदान करता है)।

डिफ़ॉल्ट रूप से उपलब्ध विशेषाधिकार की सूची:
* लेबल सत्यापित - जाँच के रूप में परिवर्तन को चिह्नित करने की क्षमता।
इस श्रेणी को विशेष रूप से एंड्रॉइड प्रोजेक्ट के लिए जोड़ा गया था और इसका मतलब है कि परिवर्तन परियोजना की असेंबली को नहीं तोड़ता है और परीक्षण पास करता है। यह श्रेणी हमारे लिए उपयोगी नहीं थी, इसे कैसे निकालना है यह प्रलेखन में वर्णित है ।
* लेबल कोड की समीक्षा - उपलब्ध रेटिंग की सीमा (-2 से +2) निर्दिष्ट करने की क्षमता के साथ कोड का सीधे संशोधन।
* संदर्भ बनाएं - रिपॉजिटरी में लिंक, शाखाएं और टैग बनाने की क्षमता।
* फोर्ज लेखक / फोर्ज कमिटर / फोर्ज सर्वर - अन्य लोगों से "नकली" परिवर्तन करने की क्षमता। Gerrit को आमतौर पर लेखक के ईमेल पते को पंजीकृत पतों में से एक से मेल खाने की आवश्यकता होती है, लेकिन इसे इस विशेषाधिकार के साथ दरकिनार किया जा सकता है। आमतौर पर इसकी आवश्यकता केवल मौजूदा भंडार को जेरिट में आयात करने के समय होती है।
* मालिक - इस परियोजना के लिए विशेषाधिकारों को जारी करने / बदलने, परियोजना विवरण बदलने, रिपॉजिटरी में शाखाओं को हटाने और बनाने (केवल वेब इंटरफ़ेस के माध्यम से) का अधिकार देता है।
* पुश - रिपॉजिटरी में परिवर्तन (इंजी। कमिट ) लिखने का अधिकार। Refs / * में प्रतिबद्ध विशेषाधिकार कोड संशोधन प्रणाली को दरकिनार करते हुए, रिपॉजिटरी में सीधे परिवर्तन जोड़ने का अधिकार देता है।
* पुश मर्ज कमिट - पुश के अतिरिक्त जो उपयोगकर्ता को शाखाओं को मर्ज करने की अनुमति देता है।
* पुश एनोटेट टैग - पुश के अलावा, इस बार आपको रिपॉजिटरी में टैग जोड़ने की अनुमति देता है।
* पढ़ें : रिपॉजिटरी में कोड पढ़ने का अधिकार, सिस्टम में बदलाव और उन पर टिप्पणी; डिफ़ॉल्ट रूप से, यह उन सभी उपयोगकर्ताओं को अनुमति दी जाती है जो सिस्टम में पंजीकृत हैं।
* सबमिट करें - रिपॉजिटरी में परिवर्तन लागू करने का अधिकार।

हमारे लक्ष्यों के आधार पर, हमने अपनी परियोजनाओं के लिए निम्नलिखित इष्टतम विन्यास का चयन किया है:



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

एक निष्कर्ष के बजाय

गेरिट ने इस लेख के लेखक पर एक मिश्रित मिश्रित छाप छोड़ी।

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

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

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

एंटोन डोवगल, डेवलपर
badoo कंपनी