तुम्ही गिट कमांड शिकलात पण सतत इंटिग्रेशन (CI) प्रत्यक्षात कसे कार्य करते याची कल्पना करायची आहे? किंवा कदाचित आपण आपल्या दैनंदिन क्रियाकलापांना अनुकूल करू इच्छिता? हा कोर्स तुम्हाला GitHub रेपॉजिटरी वापरून सतत एकत्रीकरणात व्यावहारिक कौशल्ये देईल. हा कोर्स विझार्ड बनवण्याचा हेतू नाही ज्यावर तुम्ही फक्त क्लिक करू शकता; त्याउलट, तुम्ही त्याच कृती कराल ज्या लोक प्रत्यक्षात कामावर करतात, त्याच प्रकारे ते करतात. तुम्ही गुंतलेल्या पायऱ्यांमधून जाताना मी सिद्धांत स्पष्ट करेन.

आम्ही काय करू?

जसजसे आम्ही प्रगती करू, तसतसे आम्ही ठराविक CI चरणांची यादी तयार करू, ही यादी लक्षात ठेवण्याचा एक उत्तम मार्ग आहे. दुस-या शब्दात सांगायचे तर, आम्ही सतत एकीकरण करताना, सतत एकत्रीकरण करत असताना विकासक करत असलेल्या क्रियांची सूची तयार करू. आमची CI प्रक्रिया वास्तविकतेच्या जवळ आणण्यासाठी आम्ही चाचण्यांचा एक सोपा संच देखील वापरू.

हा GIF योजनाबद्धपणे तुमच्या रेपॉजिटरीमध्ये कमिट दाखवतो जेव्हा तुम्ही कोर्समध्ये प्रगती करता. जसे आपण पाहू शकता, येथे काहीही क्लिष्ट नाही आणि फक्त सर्वात आवश्यक आहे.

तुम्ही खालील मानक सीआय परिस्थितींमधून जाल:

• वैशिष्ट्यावर कार्य करा;
• गुणवत्ता सुनिश्चित करण्यासाठी स्वयंचलित चाचण्यांचा अर्ज;
• प्राधान्य कार्याची अंमलबजावणी;
• शाखा विलीन करताना संघर्ष निराकरण (विरोध विलीन करा);
• उत्पादन वातावरणात त्रुटी येते.

काय शिकणार?

तुम्ही खालील प्रश्नांची उत्तरे देण्यास सक्षम असाल:

• सतत एकत्रीकरण (CI) म्हणजे काय?
• CI मध्ये कोणत्या प्रकारच्या स्वयंचलित चाचण्या वापरल्या जातात आणि त्या कोणत्या कृती ट्रिगर केल्या जातात?
• पुल विनंत्या काय आहेत आणि त्यांची कधी गरज आहे?
• टेस्ट ड्रायव्हन डेव्हलपमेंट (टीडीडी) म्हणजे काय आणि ते सीआयशी कसे संबंधित आहे?
• मी बदल विलीन करावे किंवा पुन्हा बेस करावे?
• रोल बॅक किंवा पुढील आवृत्तीत निराकरण?

सुरुवातीला मी "पुल विनंत्या" सारख्या गोष्टी सर्वत्र अनुवादित केल्या, परंतु परिणामी मजकूरातील वेडेपणा कमी करण्यासाठी मी काही ठिकाणी इंग्रजीमध्ये वाक्ये परत करण्याचा निर्णय घेतला. मी कधीकधी "प्रोग्रामर सर्जिक" वापरतो जसे की अद्भुत क्रियापद "कमिट" जेथे लोक प्रत्यक्षात कामावर वापरतात.

सतत एकीकरण म्हणजे काय?

सतत एकात्मता, किंवा CI, एक तांत्रिक सराव आहे ज्यामध्ये प्रत्येक कार्यसंघ सदस्य दिवसातून किमान एकदा त्यांचा कोड एका सामान्य भांडारात समाकलित करतो आणि परिणामी कोड किमान त्रुटींशिवाय तयार केला गेला पाहिजे.

या पदाबद्दल मतमतांतरे आहेत

वादाचा मुद्दा म्हणजे एकत्रीकरणाची वारंवारता. काहींनी असा युक्तिवाद केला की दिवसातून एकदाच कोड विलीन करणे प्रत्यक्षात सतत समाकलित करण्यासाठी पुरेसे नाही. एका संघाचे उदाहरण दिले आहे जिथे प्रत्येकजण सकाळी ताजे कोड घेतो आणि संध्याकाळी एकदा तो एकत्रित करतो. हा एक वाजवी आक्षेप असला तरी, सामान्यतः असे मानले जाते की दिवसातून एकदाची व्याख्या वाजवीपणे व्यावहारिक, विशिष्ट आणि विविध आकारांच्या संघांसाठी योग्य आहे.

आणखी एक आक्षेप असा आहे की C++ ही यापुढे विकासात वापरली जाणारी एकमेव भाषा नाही आणि प्रमाणीकरणाचा मार्ग म्हणून त्रुटी-मुक्त असेंब्ली आवश्यक आहे. चाचण्यांचा काही संच (उदाहरणार्थ, स्थानिक पातळीवर चालवल्या जाणार्‍या युनिट चाचण्या) देखील यशस्वीरित्या पूर्ण होणे आवश्यक आहे. या क्षणी, समुदाय ही एक आवश्यकता बनवण्याच्या दिशेने वाटचाल करत आहे आणि भविष्यात "बिल्ड + युनिट चाचण्या" कदाचित सामान्य सराव बनतील, जर ती आधीच नसेल.

सतत एकात्मता पासून वेगळे सतत वितरण (कंटिन्युअस डिलिव्हरी, सीडी) यामध्ये प्रत्येक एकत्रीकरण चक्रानंतर रिलीझ उमेदवाराची आवश्यकता नसते.

आम्ही संपूर्ण कोर्समध्ये वापरणार असलेल्या चरणांची यादी

1. नवीनतम कोड खेचा. पासून एक शाखा तयार करा master. कामाला लागा, काम सुरु करा.
2. तुमच्या नवीन शाखेत कमिट तयार करा. स्थानिक पातळीवर तयार करा आणि चाचणी करा. पास? पुढील चरणावर जा. अपयशी? त्रुटी किंवा चाचण्या दुरुस्त करा आणि पुन्हा प्रयत्न करा.
3. तुमच्या रिमोट रिपॉझिटरी किंवा रिमोट ब्रँचवर पुश करा.
4. एक पुल विनंती तयार करा. बदलांची चर्चा करा, चर्चा सुरू असताना आणखी कमिट जोडा. फीचर शाखेवर चाचण्या पास करा.
5. मास्टरकडून मर्ज/रिबेस कमिट. विलीनीकरणाच्या निकालावर चाचण्या पास करा.
6. वैशिष्ट्य शाखेपासून उत्पादनापर्यंत तैनात करा.
7. काही कालावधीसाठी उत्पादनात सर्वकाही चांगले असल्यास, मास्टरमध्ये बदल विलीन करा.

️ तयारी

तुमच्याकडे योग्य सॉफ्टवेअर असल्याची खात्री करा

हा कोर्स घेण्यासाठी तुम्हाला आवश्यक असेल Node.js и गिट क्लायंट.

तुम्ही कोणताही Git क्लायंट वापरू शकता, पण मी फक्त कमांड लाइनसाठी कमांड देईन.

तुमच्याकडे कमांड लाइनला सपोर्ट करणारा गिट क्लायंट इन्स्टॉल केलेला असल्याची खात्री करा

तुमच्याकडे कमांड लाइनला सपोर्ट करणारा गिट क्लायंट नसल्यास, तुम्ही इन्स्टॉलेशन सूचना शोधू शकता येथे.

भांडार तयार करा

तुम्हाला वैयक्तिक प्रत तयार करावी लागेल (काटा) कोर्ससाठी कोडसह टेम्पलेट भांडार GitHub वर. या वैयक्तिक प्रत कॉल करण्यास सहमती द्या अभ्यासक्रम भांडार.

झाले? तुम्ही डीफॉल्ट सेटिंग्ज बदलल्या नसल्यास, तुमच्या कोर्स रिपॉझिटरीला बहुधा कॉल केला जाईल continuous-integration-team-scenarios-students, ते तुमच्या GitHub खात्यामध्ये स्थित आहे आणि URL असे दिसते

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

मी फक्त या पत्त्यावर कॉल करेन <URL репозитория>.

कोन कंस सारखे <тут> याचा अर्थ असा होईल की आपण अशा अभिव्यक्तीला योग्य मूल्यासह पुनर्स्थित करणे आवश्यक आहे.

याची खात्री करा GitHub क्रिया या अभ्यासक्रमाच्या भांडारासाठी समाविष्ट आहे. ते सक्षम केलेले नसल्यास, कृपया पृष्ठाच्या मध्यभागी असलेल्या मोठ्या बटणावर क्लिक करून त्यांना सक्षम करा, जे तुम्ही GitHub इंटरफेसमधील क्रियांवर क्लिक करून मिळवू शकता.

GitHub क्रिया सक्षम नसल्यास तुम्ही माझ्या सूचनांचे पालन करून कोर्स पूर्ण करू शकणार नाही.

आम्ही येथे तयार करत असलेल्या सूचीची सद्य स्थिती पाहण्यासाठी तुम्ही मार्कडाउन रेंडर करण्याची गिटहबची क्षमता नेहमी वापरू शकता

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

उत्तरांबद्दल

हा कोर्स पूर्ण करण्याचा सर्वोत्तम मार्ग म्हणजे तो स्वतः करणे, तुम्हाला काही अडचणी येऊ शकतात.

तुम्हाला काय करावे हे समजत नाही आणि पुढे चालू ठेवता येत नाही असे वाटत असल्यास, तुम्ही थ्रेड पाहू शकता solution, जे तुमच्या स्टार्ट रिपॉजिटरीमध्ये आहे.
कृपया विलीन करू नका solution в master कोर्स दरम्यान. Git ने आम्हाला दिलेल्या सर्व क्षमतांचा वापर करून तुम्ही काय करावे हे शोधण्यासाठी किंवा लेखकाच्या कोडची तुलना करण्यासाठी तुम्ही या शाखेचा वापर करू शकता. तुम्ही पूर्णपणे हरवल्यास, तुम्ही तुमची शाखा पूर्णपणे बदलू शकता master एका शाखेवर solution आणि नंतर तुमची कार्यरत निर्देशिका तुम्हाला आवश्यक असलेल्या कोर्स स्टेपवर रीसेट करा.

तुम्हाला खरोखर गरज असेल तरच हे वापरा

तुमचा कोड द्या

git add .
git commit -m "Backing up my work"

या आज्ञा

• नाव बदला master в master-backup;
• नाव बदला solution в master;
• नवीन शाखेत चेकआउट करा master आणि कार्यरत निर्देशिकेची सामग्री पुन्हा लिहा;
• भविष्यात तुम्हाला "सोल्यूशन" शाखेची गरज भासल्यास "मास्टर" (जे "सोल्यूशन" असायचे) कडून "सोल्यूशन" शाखा तयार करा.

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

या चरणांनंतर आपण वापरू शकता git log master आपल्याला कोणत्या वचनबद्धतेची आवश्यकता आहे हे शोधण्यासाठी.
तुम्ही तुमची कार्यरत निर्देशिका या कमिटवर याप्रमाणे रीसेट करू शकता:

git reset --hard <the SHA you need>

जर तुम्ही निकालावर खूश असाल, तर तुम्हाला तुमची रिपॉजिटरी आवृत्ती रिमोट रिपॉजिटरीमध्ये प्रकाशित करावी लागेल. तुम्ही हे करता तेव्हा रिमोट शाखा स्पष्टपणे नमूद करण्यास विसरू नका.

git push --force origin master

कृपया लक्षात ठेवा की आम्ही वापरतो git push --force. तुम्हाला हे बर्‍याचदा करायचे असण्याची शक्यता नाही, परंतु आमच्याकडे येथे एका रेपॉजिटरी वापरकर्त्यासह एक अतिशय विशिष्ट परिस्थिती आहे ज्याला, शिवाय, तो काय करत आहे हे समजते.

काम सुरू करत आहे

चला आमच्या सीआय चरणांची सूची संकलित करण्यास प्रारंभ करूया. सामान्यत: तुम्ही रिमोट रिपॉजिटरीमधून कोडची नवीनतम आवृत्ती तपासून ही पायरी सुरू कराल, परंतु आमच्याकडे अद्याप स्थानिक भांडार नाही, म्हणून आम्ही त्याऐवजी रिमोटवरून क्लोन करतो.

️ कार्य: स्थानिक भांडार अद्यतनित करा, येथून एक शाखा तयार करा master, कामाला लागा, काम सुरु करा

1. पासून कोर्स रेपॉजिटरी क्लोन करा <URL репозитория>.
2. चालवा npm install कोर्स रेपॉजिटरी निर्देशिकेत; आम्हाला जेस्ट स्थापित करण्यासाठी त्याची आवश्यकता आहे, जी आम्ही चाचण्या चालवण्यासाठी वापरतो.
3. एक शाखा तयार करा आणि त्याला नाव द्या feature. या थ्रेडवर स्विच करा.

4. यामध्ये चाचणी कोड जोडा ci.test.js मला असे करण्यास सांगणाऱ्या टिप्पण्यांदरम्यान.

   it('1. pull latest code', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. add commits', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. push to the remote branch with the same name', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. create a pull request and continue working', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. फाइलमध्ये पहिल्या 4 चरणांसह मजकूर जोडा ci.md.

   1. Pull in the latest code. Create a branch from `master`. Start working.    
   2. Create commits on your new branch. Build and test locally.  
   Pass? Go to the next step. Fail? Fix errors or tests and try again.  
   3. Push to your remote repository or remote branch.  
   4. Create a pull request. Discuss the changes, add more commits  
   as discussion continues. Make tests pass on the feature branch.  

   टीम्स

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

नवीन शाखेत कमिट तयार करा, स्थानिक पातळीवर तयार करा आणि चाचणी करा

आम्ही कमिट करण्यापूर्वी रन करण्यासाठी चाचण्या सेट करणार आहोत आणि नंतर कोड कमिट करणार आहोत.

चाचण्या आपोआप चालतात तेव्हा सामान्य परिस्थिती

• स्थानिक पातळीवर:
  • सतत किंवा योग्य कोड बदलांच्या प्रतिसादात;
  • जतन करण्यावर (व्याख्यात किंवा JIT-संकलित भाषांसाठी);
  • असेंब्ली दरम्यान (जेव्हा संकलन आवश्यक असते);
  • वचनबद्धतेवर;
  • सामायिक भांडारात प्रकाशित करताना.

• बिल्ड सर्व्हर किंवा बिल्ड वातावरणावर:
  • जेव्हा कोड वैयक्तिक शाखेत/रेपॉजिटरीमध्ये प्रकाशित केला जातो.
  • या धाग्यातील कोडची चाचणी घेतली जात आहे.
  • विलीनीकरणाचा संभाव्य परिणाम तपासला जातो (सहसा master).
  • सतत एकीकरण टप्पा/सतत वितरण पाइपलाइन म्हणून

सामान्यतः, चाचणी संच जितक्या वेगाने धावेल तितक्या वेळा तुम्ही ते चालवू शकता. एक सामान्य स्टेज वितरण यासारखे दिसू शकते.

• जलद युनिट चाचण्या - बिल्ड दरम्यान, CI पाइपलाइनमध्ये
• स्लो युनिट चाचण्या, जलद घटक आणि एकत्रीकरण चाचण्या - कमिटवर, CI पाइपलाइनमध्ये
• धीमे घटक आणि एकत्रीकरण चाचण्या - CI पाइपलाइनमध्ये
• सुरक्षा चाचणी, लोड चाचणी आणि इतर वेळखाऊ किंवा महागड्या चाचण्या - CI/CD पाइपलाइनमध्ये, परंतु केवळ बिल्डच्या ठराविक मोड/स्टेज/पाइपलाइनमध्ये, उदाहरणार्थ, रिलीझ उमेदवार तयार करताना किंवा मॅन्युअली चालवताना.

️कार्य

मी कमांड वापरून प्रथम मॅन्युअली चाचण्या चालवण्याचा सल्ला देतो npm test. त्यानंतर, कमिटवर आमच्या चाचण्या चालविण्यासाठी एक गिट हुक जोडू. एक कॅच आहे: Git हुक रेपॉजिटरीचा भाग मानला जात नाही आणि म्हणून उर्वरित अभ्यासक्रम सामग्रीसह GitHub वरून क्लोन केले जाऊ शकत नाही. हुक स्थापित करण्यासाठी आपल्याला चालवावे लागेल install_hook.sh किंवा फाइल कॉपी करा repo/hooks/pre-commit स्थानिक निर्देशिकेत .git/hooks/.
तुम्ही वचनबद्ध केल्यावर, तुम्हाला दिसेल की चाचण्या चालवल्या जातात आणि ते काही कीवर्ड सूचीमध्ये उपस्थित आहेत की नाही हे तपासतात.

1. कमांड चालवून चाचण्या मॅन्युअली चालवा npm test तुमच्या कोर्स रेपॉजिटरी फोल्डरमध्ये. चाचण्या पूर्ण झाल्याची खात्री करा.
2. चालवून कमिट हुक (प्री-कमिट हुक) सेट करा install_hook.sh.
3. तुमचे बदल तुमच्या स्थानिक भांडारात करा.
4. कमिट करण्यापूर्वी चाचण्या केल्या गेल्या आहेत याची खात्री करा.

या चरणांचे अनुसरण केल्यानंतर तुमचे भांडार असे दिसले पाहिजे.

टीम्स

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.  

दूरस्थ भांडार किंवा दूरस्थ शाखेत कोड प्रकाशित करा

एकदा त्यांनी स्थानिक पातळीवर काम केल्यावर, विकासक सामान्यत: त्यांचा कोड सार्वजनिकरीत्या उपलब्ध करून देतात जेणेकरुन ते अखेरीस लोकांसह एकत्रित केले जाऊ शकतात. GitHub सह, हे सामान्यत: एकतर रिपॉजिटरी (वैयक्तिक काटा) किंवा वैयक्तिक शाखेत काम प्रकाशित करून साध्य केले जाते.

• फॉर्क्ससह, विकसक रिमोट शेअर्ड रिपॉजिटरी क्लोन करतो, त्याची वैयक्तिक रिमोट प्रत तयार करतो, ज्याला फोर्क देखील म्हणतात. ते नंतर स्थानिक पातळीवर काम करण्यासाठी या वैयक्तिक भांडाराचे क्लोन करते. जेव्हा काम पूर्ण होते आणि कमिट केले जातात, तेव्हा तो त्यांना त्याच्या काट्यामध्ये ढकलतो, जिथे ते इतरांसाठी उपलब्ध असतात आणि सामान्य भांडारात एकत्रित केले जाऊ शकतात. हा दृष्टीकोन सामान्यतः GitHub वरील मुक्त स्त्रोत प्रकल्पांमध्ये वापरला जातो. हे माझ्या प्रगत अभ्यासक्रमात देखील वापरले जाते [टीम वर्क आणि सीआय विथ गिट] (http://devops.redpill.solutions/).
• दुसरा दृष्टीकोन म्हणजे फक्त एक रिमोट रेपॉजिटरी वापरणे आणि फक्त शाखा मोजणे master सामायिक भांडार "संरक्षित". या परिस्थितीमध्ये, वैयक्तिक विकसक त्यांचा कोड रिमोट रिपॉझिटरीच्या शाखांमध्ये प्रकाशित करतात जेणेकरून इतरांना हा कोड पाहता येईल, सर्वकाही व्यवस्थित असल्यास, ते विलीन करा master सामायिक भांडार.

या विशिष्ट कोर्समध्ये, आम्ही शाखा वापरणारा कार्यप्रवाह वापरणार आहोत.

चला आमचा कोड प्रकाशित करूया.

️कार्य

• तुमच्‍या कार्यरत शाखेच्‍या नावाने रिमोट शाखेत बदल प्रकाशित करा

टीम्स

git push --set-upstream origin feature

एक पुल विनंती तयार करा

शीर्षकासह एक पुल विनंती तयार करा चरणांचे पुनरावलोकन... स्थापित करा feature जसे की "हेड शाखा" आणि master जसे की "बेस ब्रँच".

आपण स्थापित केल्याची खात्री करा master त्याच्या मध्ये रेपॉजिटरी फोर्क करा "बेस ब्रँच" म्हणून, मी कोर्स मटेरिअल रिपॉजिटरीमधील बदलांच्या विनंत्यांना प्रतिसाद देणार नाही.

GitHub लिंगोमध्ये, "बेस ब्रँच" ही शाखा आहे ज्यावर तुम्ही तुमचे काम बेस करता आणि "हेड ब्रँच" ही प्रस्तावित बदल असलेली शाखा आहे.

बदलांची चर्चा करा, चर्चा सुरू असताना नवीन कमिट जोडा

पुल विनंती (PR)

पुल विनंती (PR) चर्चा आणि दस्तऐवज कोड तसेच आचार संहितेचे पुनरावलोकन करण्याचा एक मार्ग आहे. एकूणच कोडमध्ये वैयक्तिक बदल समाकलित करण्याच्या सामान्य पद्धतीनुसार पुल विनंत्यांचे नाव दिले जाते. सामान्यतः, एखादी व्यक्ती प्रोजेक्टच्या रिमोट ऑफिशियल रिपॉझिटरी क्लोन करते आणि कोडवर स्थानिक पातळीवर काम करते. यानंतर, तो कोड त्याच्या वैयक्तिक रिमोट रिपॉजिटरीमध्ये ठेवतो आणि अधिकृत भांडारासाठी जबाबदार असलेल्यांना उचलण्यास सांगतो(खेचणे) त्याचा कोड त्यांच्या स्थानिक भांडारांमध्ये, जेथे ते पुनरावलोकन करतात आणि शक्यतो समाकलित करतात(जा) त्याचा. ही संकल्पना इतर नावांनी देखील ओळखली जाते, उदाहरणार्थ, विलीन करण्याची विनंती.

तुम्हाला खरोखर GitHub किंवा तत्सम प्लॅटफॉर्मचे पुल विनंती वैशिष्ट्य वापरण्याची गरज नाही. डेव्हलपमेंट टीम समोरासमोर संवाद, व्हॉईस कॉल किंवा ईमेल यासह संप्रेषणाच्या इतर पद्धती वापरू शकतात, परंतु मंच-शैलीतील पुल विनंत्या वापरण्याची अनेक कारणे आहेत. त्यापैकी काही येथे आहेत:

• विशिष्ट कोड बदलांशी संबंधित चर्चा आयोजित;
• ऑटोटेस्टर्स आणि समवयस्क दोघांकडून काम-प्रगतीबद्दल अभिप्राय पाहण्याची जागा म्हणून;
• कोड पुनरावलोकनांचे औपचारिकीकरण;
• जेणेकरून नंतर तुम्हाला या किंवा त्या कोडच्या तुकड्यामागील कारणे आणि विचार शोधता येतील.

सामान्यत: जेव्हा तुम्हाला एखाद्या गोष्टीवर चर्चा करायची किंवा फीडबॅक मिळवायचा असतो तेव्हा तुम्ही पुल विनंती तयार करता. उदाहरणार्थ, तुम्ही एकापेक्षा जास्त मार्गांनी अंमलात आणल्या जाऊ शकणार्‍या वैशिष्ट्यावर काम करत असल्यास, तुम्ही तुमच्या कल्पना शेअर करण्यासाठी आणि तुमच्या सहयोगकर्त्यांसोबत तुमच्या योजनांवर चर्चा करण्यासाठी कोडची पहिली ओळ लिहिण्यापूर्वी पुल विनंती तयार करू शकता. काम सोपे असल्यास, जेव्हा काहीतरी आधीच केले गेले असेल, वचनबद्ध असेल आणि चर्चा केली जाऊ शकते तेव्हा पुल विनंती उघडली जाईल. काही परिस्थितींमध्ये, तुम्ही केवळ गुणवत्ता नियंत्रण कारणांसाठी PR उघडू शकता: स्वयंचलित चाचण्या चालवण्यासाठी किंवा कोड पुनरावलोकने सुरू करण्यासाठी. तुम्ही काहीही ठरवा, तुमच्या पुल विनंतीमध्ये तुम्हाला ज्यांची मान्यता हवी आहे त्यांचा @उल्लेख करायला विसरू नका.

सामान्यतः, पीआर तयार करताना, आपण खालील गोष्टी करा.

• तुम्‍ही काय बदलण्‍याचा प्रस्‍ताव केला आहे आणि कुठे ते सूचित करा.
• बदलांचा उद्देश स्पष्ट करणारे वर्णन लिहा. तुम्हाला हवे असेल:
  • कोडमधून स्पष्ट नसलेली कोणतीही महत्त्वाची किंवा संदर्भ समजून घेण्यासाठी उपयुक्त काहीतरी जोडा, जसे की संबंधित #बग्स आणि कमिट नंबर;
  • तुम्हाला ज्यांच्यासोबत काम सुरू करायचे आहे त्याचा @उल्लेख करा किंवा तुम्ही नंतर टिप्पण्यांमध्ये त्यांचा @उल्लेख करू शकता;
  • सहकार्यांना काहीतरी मदत करण्यास सांगा किंवा काहीतरी विशिष्ट तपासा.

एकदा तुम्ही PR उघडल्यानंतर, अशा प्रकरणांमध्ये चालवण्यासाठी कॉन्फिगर केलेल्या चाचण्या अंमलात आणल्या जातात. आमच्या बाबतीत, आम्ही स्थानिक पातळीवर चालवलेल्या चाचण्यांचा हा समान संच असेल, परंतु वास्तविक प्रकल्पामध्ये अतिरिक्त चाचण्या आणि तपासण्या असू शकतात.

कृपया चाचण्या पूर्ण होईपर्यंत प्रतीक्षा करा. तुम्ही GitHub इंटरफेसमध्ये PR चर्चेच्या तळाशी चाचण्यांची स्थिती पाहू शकता. चाचण्या पूर्ण झाल्यावर सुरू ठेवा.

️ CI चरणांच्या सूचीच्या यादृच्छिकतेबद्दल एक टीप जोडा

या कोर्समध्ये वापरलेली यादी अनियंत्रित आणि व्यक्तिनिष्ठ आहे, आपण याबद्दल एक टीप जोडली पाहिजे.

️ कार्य: या टिप्पणीसाठी पुल विनंती तयार करा

1. शाखेत जा master.
2. नावाची शाखा तयार करा bugfix.
3. फाईलच्या शेवटी टीप मजकूर जोडा ci.md.

   > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
   when code is deployed straight from feature branches. This list is just an interpretation  
   that I use in my [DevOps courses](http://redpill.solutions).  
   The official tutorial is [here](https://guides.github.com/introduction/flow/).

4. बदल वचनबद्ध करा.
5. धागा प्रकाशित करा bugfix दूरस्थ भांडारात.
6. नावाची पुल विनंती तयार करा एक टिप्पणी जोडत आहे एक प्रमुख शाखा सह bugfix आणि बेस शाखाmaster.

आपण स्थापित केल्याची खात्री करा master त्याच्या मध्ये रेपॉजिटरी फोर्क करा "बेस ब्रँच" म्हणून, मी कोर्स मटेरिअल रिपॉजिटरीमधील बदलांच्या विनंत्यांना प्रतिसाद देणार नाही.

तुमचे भांडार असे दिसले पाहिजे.

टीम्स

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

पुल विनंती "टिप्पणी जोडणे" मंजूर करा

️कार्य

1. एक पुल विनंती तयार करा.
2. "मर्ज पुल विनंती" वर क्लिक करा.
3. "मर्जची पुष्टी करा" वर क्लिक करा.
4. "शाखा हटवा" वर क्लिक करा, आम्हाला यापुढे त्याची आवश्यकता नाही.

हे विलीनीकरणानंतरच्या कमिटचे आकृती आहे.

️ काम करत रहा आणि चाचण्या जोडत रहा

पुल विनंतीवर सहयोग केल्याने अनेकदा अतिरिक्त काम होते. हा सहसा कोड पुनरावलोकन किंवा चर्चेचा परिणाम असतो, परंतु आमच्या कोर्समध्ये आम्ही आमच्या सीआय चरणांच्या सूचीमध्ये नवीन आयटम जोडून याचे मॉडेल करणार आहोत.

सतत एकत्रीकरणामध्ये सामान्यत: काही चाचणी कव्हरेज समाविष्ट असते. चाचणी कव्हरेज आवश्यकता भिन्न असतात आणि सामान्यत: "योगदान मार्गदर्शक तत्त्वे" सारख्या दस्तऐवजात आढळतात. आम्ही ते सोपे ठेवू आणि आमच्या चेकलिस्टमधील प्रत्येक ओळीसाठी एक चाचणी जोडू.

असाइनमेंट चालवताना, प्रथम चाचण्या करण्याचा प्रयत्न करा. आपण योग्यरित्या स्थापित केल्यास pre-commit हुक आधी, नवीन जोडलेली चाचणी चालविली जाईल, अयशस्वी होईल आणि काहीही वचनबद्ध होणार नाही. लक्षात घ्या की अशा प्रकारे आम्हाला कळते की आमच्या चाचण्या प्रत्यक्षात काहीतरी चाचणी करत आहेत. विशेष म्हणजे, जर आम्ही चाचण्यांपूर्वी कोडसह सुरुवात केली, तर चाचण्या उत्तीर्ण केल्याचा अर्थ असा होऊ शकतो की कोड अपेक्षेप्रमाणे काम करत आहे किंवा चाचण्या प्रत्यक्षात काहीही तपासत नाहीत. शिवाय, जर आम्ही पहिल्या ठिकाणी चाचण्या लिहिल्या नसत्या तर, आम्ही कदाचित त्याबद्दल पूर्णपणे विसरलो असतो, कारण कशामुळे आम्हाला त्याची आठवण झाली नसती.

चाचणी चालित विकास (TDD)

TDD कोड करण्यापूर्वी चाचण्या लिहिण्याची शिफारस करते. TDD वापरून एक सामान्य कार्यप्रवाह असे दिसते.

1. एक चाचणी जोडा.
2. सर्व चाचण्या चालवा आणि नवीन चाचणी अयशस्वी झाल्याची खात्री करा.
3. कोड लिहा.
4. चाचण्या चालवा, सर्व चाचण्या उत्तीर्ण झाल्याची खात्री करा.
5. तुमचा कोड रिफॅक्टर करा.
6. पुन्हा करा.

कारण अयशस्वी झालेल्या चाचण्यांचे परिणाम सामान्यतः लाल रंगात दाखवले जातात आणि जे उत्तीर्ण झाले ते सहसा हिरव्या रंगात दाखवले जातात, सायकलला लाल-हिरवा-रिफॅक्टर असेही म्हणतात.

️कार्य

प्रथम, चाचण्या करण्याचा प्रयत्न करा आणि त्यांना अयशस्वी होऊ द्या, नंतर CI चरण सूचीचा मजकूर जोडा आणि कमिट करा. तुम्हाला दिसेल की चाचण्या उत्तीर्ण होत आहेत ("हिरव्या").
नंतर रिमोट रिपॉझिटरीमध्ये नवीन कोड प्रकाशित करा आणि पुल विनंती चर्चेच्या तळाशी GitHub इंटरफेसमध्ये चालणाऱ्या चाचण्या आणि PR स्थिती अपडेट पहा.

1. शाखेत जा feature.

2. मध्ये या चाचण्या जोडा ci.test.js शेवटच्या कॉल नंतर it (...);.

   it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Deploy from the feature branch to production.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. If everything is good in production for some period of time, merge changes to master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. चाचण्या करण्याचा प्रयत्न करा. तर pre-commit हुक स्थापित केले आहे, कमिट प्रयत्न अयशस्वी होईल.
4. नंतर हा मजकूर जोडा ci.md.

   5. Merge/rebase commits from master. Make tests pass on the merge result.  
   6. Deploy from the feature branch with a sneaky bug to production.
   7. If everything is good in production for some period of time, merge changes to master. 

5. स्थानिक पातळीवर बदल करा आणि वचनबद्ध करा.
6. शाखेत बदल पोस्ट करा feature.

आपल्याकडे आता असे काहीतरी असावे

टीम्स

# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

संघर्ष विलीन करा

विनंती बदला वर जा चरणांचे पुनरावलोकन.

जरी आम्ही काहीही चुकीचे केले नाही आणि आमच्या कोडच्या चाचण्या उत्तीर्ण झाल्या, तरीही आम्ही शाखा विलीन करू शकत नाही feature и master. कारण दुसरा धागा bugfix सह विलीन केले होते master आम्ही या PR वर काम करत असताना.
त्यामुळे दुर्गम शाखा अशी परिस्थिती निर्माण होते master आम्ही ज्यावर शाखा आधारित आहे त्यापेक्षा नवीन आवृत्ती आहे feature. यामुळे आपण फक्त हेड रिवाइंड करू शकत नाही master धाग्याच्या शेवटी feature. या परिस्थितीत, आम्हाला एकतर विलीन करणे किंवा कमिट लागू करणे आवश्यक आहे feature रिबेस master. कोणतेही मतभेद नसल्यास GitHub प्रत्यक्षात स्वयंचलित विलीनीकरण करू शकते. अरेरे, आमच्या परिस्थितीत, दोन्ही शाखांमध्ये फाइलमध्ये प्रतिस्पर्धी बदल आहेत ci.md. ही परिस्थिती विलीनीकरण संघर्ष म्हणून ओळखली जाते आणि आम्हाला ती व्यक्तिचलितपणे सोडवणे आवश्यक आहे.

विलीन करा किंवा रिबेस करा

जा

• अतिरिक्त मर्ज कमिट तयार करते आणि कामाचा इतिहास जतन करते.
  • शाखांचे मूळ टाइमस्टॅम्प आणि लेखकांसह मूळ कमिट जतन करते.
  • बदल विनंती चर्चेमध्ये कमिट आणि लिंक्सचे SHA सेव्ह करते.
• एक-वेळ संघर्ष निराकरण आवश्यक आहे.
• कथा नॉन-लाइनर बनवते.
  • मोठ्या संख्येने शाखांमुळे (आयडीई केबलची आठवण करून देणारी) कथा वाचणे कठीण होऊ शकते.
  • स्वयंचलित डीबगिंग अधिक कठीण करते, उदा. git bisect कमी उपयुक्त - ते केवळ विलीनीकरण कमिट शोधेल.

रीबेस

• बेस ब्रँचच्या वरच्या वर्तमान शाखेतून एकामागून एक रिप्ले कमिट केले जातात.
  • नवीन SHA सह नवीन कमिट तयार केले जातात, ज्यामुळे GitHub मधील कमिट मूळ पुल विनंत्यांशी जुळतात, परंतु संबंधित टिप्पण्यांशी जुळत नाहीत.
  • कमिट्स पुन्हा एकत्रित केल्या जाऊ शकतात आणि प्रक्रियेत सुधारित केल्या जाऊ शकतात किंवा एकामध्ये विलीन केल्या जाऊ शकतात.
• अनेक विवादांचे निराकरण करावे लागेल.
• तुम्हाला एक रेखीय कथा ठेवण्याची अनुमती देते.
  • कोणतीही वाजवी कारणास्तव कथा फार लांब नसल्यामुळे ती वाचायला सोपी असू शकते.
  • स्वयंचलित डीबगिंग आणि समस्यानिवारण थोडे सोपे आहे: ते शक्य करते git bisect, स्वयंचलित रोलबॅक अधिक स्पष्ट आणि अधिक अंदाज लावू शकतात.
• ध्वजासह स्थलांतरित कमिटांसह शाखा प्रकाशित करणे आवश्यक आहे --force जेव्हा पुल विनंत्यांसह वापरले जाते.

सामान्यतः, जेव्हा त्यांना बदल विलीन करण्याची आवश्यकता असते तेव्हा संघ नेहमी समान धोरण वापरण्यास सहमत असतात. हे एक "शुद्ध" विलीनीकरण किंवा शीर्षस्थानी "शुद्ध" कमिट असू शकते, किंवा दरम्यान काहीतरी, जसे की परस्परसंवादीपणे शीर्षस्थानी कमिट करणे(git rebase -i) सार्वजनिक भांडारात प्रकाशित न केलेल्या शाखांसाठी स्थानिक पातळीवर, परंतु "सार्वजनिक" शाखांसाठी विलीनीकरण.

येथे आपण merge वापरू.

️कार्य

1. कोड स्थानिक शाखेत असल्याची खात्री करा master रिमोट रिपॉजिटरीमधून अद्यतनित.
2. शाखेत जा feature.
3. शाखेत विलीनीकरण सुरू करा master. मध्ये स्पर्धात्मक बदलांमुळे विलीनीकरण संघर्ष ci.md.
4. संघर्षाचे निराकरण करा जेणेकरून आमची CI चरणांची यादी आणि त्याबद्दलची एक टीप मजकूरात राहतील.
5. दूरस्थ शाखेत मर्ज कमिट प्रकाशित करा feature.
6. GitHub UI मध्ये पुल विनंतीची स्थिती तपासा आणि विलीनीकरणाचे निराकरण होईपर्यंत प्रतीक्षा करा.

टीम्स

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

चांगले काम!

तुमची यादी पूर्ण झाली आहे आणि आता तुम्हाला पुल विनंती मंजूर करणे आवश्यक आहे master.

️ कार्य: पुल विनंती "चरण पुनरावलोकन" मंजूर करा

1. एक पुल विनंती उघडा.
2. "मर्ज पुल विनंती" वर क्लिक करा.
3. "मर्जची पुष्टी करा" वर क्लिक करा.
4. "शाखा हटवा" वर क्लिक करा कारण आम्हाला यापुढे त्याची आवश्यकता नाही.

या क्षणी हे आपले भांडार आहे

उत्पादन त्रुटी

असे म्हटले जाते की "चाचणीचा उपयोग त्रुटींची उपस्थिती दर्शविण्यासाठी केला जाऊ शकतो, परंतु त्यांची अनुपस्थिती दर्शविण्यासाठी कधीही." जरी आमच्या चाचण्या झाल्या आणि त्यांनी आम्हाला कोणतीही त्रुटी दाखवली नाही, तरीही एक कपटी बग उत्पादनात आला.

अशा परिस्थितीत, आम्हाला काळजी घेणे आवश्यक आहे:

• उत्पादनात काय उपयोजित आहे;
• थ्रेडमधील कोड master त्रुटीसह, ज्यामधून विकासक नवीन कार्य सुरू करू शकतात.

मी परत रोल करावे किंवा पुढील आवृत्तीत त्याचे निराकरण करावे?

रोल बॅक करणे ही एक ज्ञात चांगली पूर्वीची आवृत्ती उत्पादनात उपयोजित करण्याची आणि त्रुटी असलेल्या कमिट परत करण्याची प्रक्रिया आहे. "फिक्सिंग फॉरवर्ड" हे फिक्समध्ये जोडलेले आहे master आणि शक्य तितक्या लवकर नवीन आवृत्ती तैनात करत आहे. कोड उत्पादनात उपयोजित केल्यामुळे API आणि डेटाबेस स्कीमा बदलतात, सतत वितरण आणि चांगल्या चाचणी कव्हरेजसह, रोल बॅक करणे सामान्यत: पुढील आवृत्तीमध्ये निराकरण करण्यापेक्षा अधिक कठीण आणि धोकादायक असते.

मागे फिरणे आमच्या बाबतीत कोणताही धोका पत्करत नसल्यामुळे, आम्ही या मार्गावर जाऊ, कारण ते आम्हाला परवानगी देते

• उत्पादनातील त्रुटी शक्य तितक्या लवकर दुरुस्त करा;
• मध्ये कोड बनवा master नवीन नोकरी सुरू करण्यासाठी लगेच योग्य.

️कार्य

1. शाखेत जा master स्थानिक पातळीवर.
2. रिमोट रिपॉजिटरीमधून स्थानिक भांडार अद्यतनित करा.
3. PR मर्ज कमिट परत करा चरणांचे पुनरावलोकन в master.
4. रिमोट रिपॉझिटरीमध्ये बदल प्रकाशित करा.

मर्ज कमिट रिव्हर्ट केलेल्या रिपॉझिटरीचा हा इतिहास आहे

टीम्स

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ स्व-परीक्षण

याची खात्री करा ci.md मर्ज कमिट परत केल्यावर "स्नीकी बग" मजकूर यापुढे राहणार नाही.

सीआय चरणांची यादी निश्चित करा आणि ती मास्टरकडे परत करा

आम्ही शाखेचे विलीनीकरण पूर्णतः पूर्ववत केले आहे. feature. चांगली बातमी अशी आहे की आता आमच्यात कोणतीही चूक नाही master. वाईट बातमी अशी आहे की आमची सतत एकात्मता चरणांची मौल्यवान यादी देखील निघून गेली आहे. म्हणून, आदर्शपणे, आम्हाला कमिटमध्ये फिक्स लागू करणे आवश्यक आहे feature आणि त्यांना परत करा master निराकरण सोबत.

आम्ही वेगवेगळ्या मार्गांनी समस्येकडे जाऊ शकतो:

• विलीनीकरण पूर्ववत करणारी कमिट परत करा feature с master;
• भूतकाळातील मूव्ह कमिट feature.

भिन्न विकास संघ या प्रकरणात भिन्न दृष्टीकोन वापरतात, परंतु आम्ही उपयुक्त कमिट वेगळ्या शाखेत हलवू आणि या नवीन शाखेसाठी स्वतंत्र पुल विनंती तयार करू.

️कार्य

1. नावाचा धागा तयार करा feature-fix आणि त्यावर स्विच करा.

2. पूर्वीच्या शाखेतून सर्व कमिट स्थलांतरित करा feature नवीन धाग्यावर. स्थलांतर दरम्यान उद्भवलेल्या विलीनीकरण विवादांचे निराकरण करा.

   

3. मध्ये प्रतिगमन चाचणी जोडा ci.test.js:

   it('does not contain the sneaky bug', () => {
   expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
   });

4. त्या अयशस्वी होणार नाहीत याची खात्री करण्यासाठी स्थानिक पातळीवर चाचण्या चालवा.
5. मध्ये "स्नीकी बगसह" मजकूर काढा ci.md.
6. अनुक्रमणिकेमध्ये चाचणी बदल आणि चरण सूचीतील बदल जोडा आणि त्यांना वचनबद्ध करा.
7. रिमोट रिपॉजिटरीमध्ये शाखा प्रकाशित करा.

आपण यासारखे काहीतरी समाप्त केले पाहिजे:

टीम्स

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

एक पुल विनंती तयार करा.

शीर्षकासह एक पुल विनंती तयार करा वैशिष्ट्य निराकरण... स्थापित करा feature-fix जसे की "हेड शाखा" आणि master जसे की "बेस ब्रँच".
कृपया चाचण्या पूर्ण होईपर्यंत प्रतीक्षा करा. तुम्ही PR चर्चेच्या तळाशी चाचण्यांची स्थिती पाहू शकता.

आपण स्थापित केल्याची खात्री करा master त्याच्या मध्ये रेपॉजिटरी फोर्क करा "बेस ब्रँच" म्हणून, मी कोर्स मटेरिअल रिपॉजिटरीमधील बदलांच्या विनंत्यांना प्रतिसाद देणार नाही.

पुल विनंती "वैशिष्ट्य निश्चित करणे" मंजूर करा

दुरुस्तीबद्दल धन्यवाद! कृपया मधील बदल मंजूर करा master पुल विनंती पासून.

️कार्य

1. "मर्ज पुल विनंती" वर क्लिक करा.
2. "मर्जची पुष्टी करा" वर क्लिक करा.
3. "शाखा हटवा" वर क्लिक करा कारण आम्हाला यापुढे त्याची आवश्यकता नाही.

या क्षणी आपल्याकडे हेच असले पाहिजे.

अभिनंदन!

तुम्ही सर्व पायऱ्या पूर्ण केल्या आहेत ज्या लोक सामान्यत: सतत एकत्रीकरणादरम्यान घेतात.

तुम्हाला कोर्समध्ये काही समस्या आढळल्यास किंवा ते कसे सुधारायचे हे माहित असल्यास, कृपया मध्ये एक समस्या तयार करा अभ्यासक्रम सामग्रीसह भांडार. हा अभ्यासक्रम देखील आहे परस्परसंवादी आवृत्ती प्लॅटफॉर्म म्हणून गिटहब लर्निंग लॅब वापरणे.

स्त्रोत: www.habr.com