विकसकांसाठी सर्वोत्तम DevOps पद्धती. अँटोन बॉयको (२०१७)

अहवाल काही DevOps पद्धतींबद्दल बोलेल, परंतु विकसकाच्या दृष्टिकोनातून. सामान्यतः, DevOps मध्ये सामील झालेल्या सर्व अभियंत्यांकडे आधीच अनेक वर्षांचा प्रशासकीय अनुभव असतो. परंतु याचा अर्थ येथे विकासकाला स्थान नाही, असे नाही. बर्याचदा नाही, विकासक "दिवसातील पुढील तातडीने गंभीर बग" निराकरण करण्यात व्यस्त असतात आणि त्यांच्याकडे DevOps फील्डकडे द्रुतपणे पाहण्यासाठी देखील वेळ नसतो. लेखकाच्या समजुतीनुसार, DevOps हे प्रथमतः सामान्य ज्ञान आहे. दुसरे म्हणजे, ही अधिक प्रभावी होण्याची संधी आहे. तुम्ही डेव्हलपर असाल, तुम्हाला अक्कल असेल आणि तुम्हाला संघ खेळाडू म्हणून अधिक प्रभावी व्हायचे असेल, तर हा अहवाल तुमच्यासाठी आहे.

मला माझी ओळख करून द्या, मी पूर्णपणे कबूल करतो की खोलीत असे लोक आहेत जे मला ओळखत नाहीत. माझे नाव अँटोन बॉयको आहे, मी मायक्रोसॉफ्ट अझूर एमव्हीपी आहे. MVP म्हणजे काय? हे मॉडेल-व्ह्यू-प्रेझेंटर आहे. मॉडेल-व्ह्यू-प्रेझेंटर अगदी मीच आहे.

याशिवाय, मी सध्या सिक्लम येथे सोल्यूशन आर्किटेक्टचे पद सांभाळत आहे. आणि नुकतेच मी स्वतःला इतके सुंदर डोमेन विकत घेतले आणि मी माझे ईमेल अद्यतनित केले, जे मी सहसा सादरीकरणांमध्ये दर्शवितो. तुम्ही मला येथे लिहू शकता: me [dog] byokoant.pro. तुम्ही मला प्रश्नांसह ईमेल करू शकता. मी सहसा त्यांना उत्तर देतो. फक्त एक गोष्ट अशी आहे की मला ईमेलद्वारे दोन विषयांशी संबंधित प्रश्न प्राप्त करायला आवडणार नाही: राजकारण आणि धर्म. इतर सर्व गोष्टींबद्दल तुम्ही मला ईमेलद्वारे लिहू शकता. थोडा वेळ जाईल, मी उत्तर देईन.

स्वतःबद्दल काही शब्द:

• मी आता या क्षेत्रात 10 वर्षे आहे.
• मी मायक्रोसॉफ्टमध्ये काम केले.
• मी युक्रेनियन Azure समुदायाचा संस्थापक आहे, ज्याची स्थापना आम्ही 2014 मध्ये केली होती. आणि आमच्याकडे ते अजूनही आहे आणि ते विकसित करत आहोत.
• आम्‍ही युक्रेनमध्‍ये आयोजित करत असलेल्‍या अझर कॉन्फरन्‍सच्‍या संस्‍थापकाचाही मी जनक आहे.
• मी कीवमध्ये ग्लोबल अॅझ्युर बूटकॅम्प आयोजित करण्यात देखील मदत करतो.
• मी म्हटल्याप्रमाणे, मी Microsoft Azure MVP आहे.
• मी अनेकदा परिषदांमध्ये बोलतो. मला परिषदांमध्ये बोलणे खरोखर आवडते. गेल्या वर्षभरात मी सुमारे 40 वेळा कामगिरी करू शकलो. जर तुम्ही युक्रेन, बेलारूस, पोलंड, बल्गेरिया, स्वीडन, डेन्मार्क, नेदरलँड्स, स्पेनमधून जात असाल किंवा युरोपमधील दुसरा देश द्या किंवा घ्याल, तर हे शक्य आहे की जेव्हा तुम्ही एखाद्या परिषदेला गेलात ज्याच्या प्रवाहात क्लाउड थीम असेल, तुम्ही मला स्पीकर्सच्या यादीत पाहू शकता.
• मी देखील स्टार ट्रेकचा चाहता आहे.

अजेंड्याबद्दल थोडे बोलूया. आमचा अजेंडा अगदी सोपा आहे:

• DevOps काय आहे याबद्दल आम्ही बोलू. हे का महत्त्वाचे आहे ते बोलूया. पूर्वी, DevOps हा एक कीवर्ड होता जो तुम्ही तुमच्या रेझ्युमेवर लिहिला होता आणि लगेच +$500 पगार मिळाला होता. आता तुम्हाला तुमच्या पगारात +500 डॉलर मिळविण्यासाठी तुमच्या रेझ्युमेमध्ये ब्लॉकचेन लिहावे लागेल.
• आणि मग, हे काय आहे याबद्दल आपल्याला थोडेसे समजल्यावर, आपण DevOps पद्धती काय आहेत याबद्दल बोलू. परंतु सर्वसाधारणपणे DevOps च्या संदर्भात इतके नाही, परंतु विकासकांना स्वारस्य असलेल्या DevOps पद्धतींबद्दल. ते तुमच्यासाठी स्वारस्य का असू शकतात ते मी तुम्हाला सांगेन. तुम्ही हे अजिबात का करावे आणि ते तुम्हाला कमी वेदना अनुभवण्यास कशी मदत करू शकते हे मी तुम्हाला सांगेन.

एक पारंपारिक चित्र जे बरेच लोक दाखवतात. अनेक प्रकल्पांमध्ये असेच घडते. आमच्या सॉफ्टवेअरला सपोर्ट करणारे डेव्हलपमेंट आणि ऑपरेशन्स विभाग असतात तेव्हा हे घडते. आणि हे विभाग एकमेकांशी संवाद साधत नाहीत.

कदाचित, जर तुम्हाला DevOps आणि ऑपरेशन विभागांमध्ये ते इतके स्पष्टपणे जाणवू शकले नसेल, तर तुम्ही Dev आणि QA विभागांशी साधर्म्य काढू शकता. असे लोक आहेत जे सॉफ्टवेअर विकसित करतात आणि QA लोक आहेत जे विकसकांच्या दृष्टिकोनातून वाईट आहेत. उदाहरणार्थ, मी माझा अद्भुत कोड रेपॉजिटरीकडे पाठवतो आणि तिथे काही बदमाश बसला आहे जो मला हा कोड परत करतो आणि म्हणतो की तुमचा कोड खराब आहे.

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

ही भिंत आहे जी DevOps संस्कृती नष्ट करण्यासाठी डिझाइन केलेली आहे, म्हणजे. लोकांना एकमेकांशी संवाद साधण्याची सक्ती करा आणि प्रकल्पातील भिन्न लोक काय करतात आणि त्यांचे कार्य का महत्त्वाचे आहे हे किमान समजून घ्या.

आणि जेव्हा आम्ही DevOps बद्दल बोलतो, तेव्हा कोणीतरी तुम्हाला सांगेल की DevOps म्हणजे जेव्हा प्रोजेक्टमध्ये सतत एकत्रीकरण होते; कोणीतरी म्हणेल की जर प्रकल्प "कोड म्हणून पायाभूत सुविधा" सराव लागू करत असेल तर DevOps आहे; कोणी म्हणेल की DevOps ची पहिली पायरी म्हणजे वैशिष्ट्य शाखा, वैशिष्ट्य ध्वज.

मूलत:, हे सर्व त्याच्या स्वत: च्या मार्गाने खरे आहे. पण या केवळ आपल्याकडील अंतिम पद्धती आहेत. या पद्धतींकडे जाण्यापूर्वी, मी ही स्लाइड पाहण्याचा सल्ला देतो, जी तुमच्या प्रकल्पामध्ये, तुमच्या कंपनीमध्ये Dev-Ops पद्धती लागू करण्याचे 3 टप्पे दाखवते.

या स्लाइडमध्ये दुसरे अनधिकृत नाव देखील आहे. DevOps चे 3 Musketeers काय आहेत हे शोधण्यासाठी तुम्ही ऑनलाइन शोधू शकता. हे शक्य आहे की आपल्याला हा लेख सापडेल. 3 मस्केटियर्स का? खाली असे म्हटले आहे: लोक, प्रक्रिया आणि उत्पादने, म्हणजे. PPP - पोर्थोस, पोर्थोस आणि पोर्थोस. येथे DevOps चे 3 मस्केटियर आहेत. हा लेख अधिक तपशीलवार वर्णन करतो की हे महत्वाचे का आहे आणि त्यात काय समाविष्ट आहे.

जेव्हा तुम्ही DevOps संस्कृती लागू करणे सुरू करता, तेव्हा ते खालील क्रमाने लागू केले जाणे अत्यंत महत्त्वाचे असते.

सुरुवातीला तुम्हाला लोकांशी बोलण्याची गरज आहे. आणि तुम्हाला ते काय आहे आणि त्यांना त्यातून काही फायदे कसे मिळू शकतात हे समजावून सांगण्याची गरज आहे.

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

आम्ही लोकांबद्दल बोलू, आम्ही दररोज विकासकांना काय करायचे आहे याबद्दल बोलू. त्यांना सर्वात जास्त काय हवे आहे? त्यांना काही नवीन कोड लिहायचे आहेत, नवीन फ्रेमवर्क वापरायचे आहेत, नवीन वैशिष्ट्ये तयार करायची आहेत. विकासकांना किमान काय हवे आहे? जुन्या दोषांचे निराकरण करा. मला आशा आहे की तुम्ही माझ्याशी सहमत आहात. विकासकांना हेच हवे आहे. त्यांना नवीन वैशिष्ट्ये लिहायची आहेत, त्यांना बगचे निराकरण करायचे नाही.

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

QA ला सर्वात जास्त काय हवे आहे? ते सभागृहात आहेत की नाही माहीत नाही. मला QA हवा आहे हे सांगणे माझ्यासाठी कठीण आहे, कारण मी कधीही एक नव्हतो. आणि मुलांसाठी कोणताही गुन्हा नाही, असे म्हटले जाईल की मला आशा आहे की मी कधीही करणार नाही. पण मी त्यांचे कार्य निरर्थक आणि निरुपयोगी मानतो या कारणासाठी नाही तर हे कार्य कुशलतेने करू शकणारी व्यक्ती मी स्वत:ला मानत नाही, म्हणून मी ते करण्याचा प्रयत्नही करणार नाही. परंतु मला जे समजले त्यावरून, QA ला सर्वात जास्त आवडत नाही ते म्हणजे सकाळी काम करणे, सतत काही प्रकारच्या रीग्रेशन चाचण्या करणे, 3 स्प्रिंट्सपूर्वी त्यांनी विकसकांना सांगितलेल्या त्याच बग्सवर पाऊल टाकणे आणि म्हणणे: “तुम्ही कधी , महाशय डी 'आर्टगनन, हा दोष दूर करा.' आणि महाशय डी'अर्टगनन त्याला उत्तर देतात: "होय, होय, होय, मी आधीच ते निश्चित केले आहे." आणि हे कसे घडते की मी एक बग निश्चित केला आणि वाटेत 5 केले.

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

आणि जेव्हा तुम्ही लोकांना समजावून सांगता की ते समान समस्यांचे निराकरण करण्याच्या उद्देशाने आहेत, तेव्हा तुम्ही प्रक्रियांना औपचारिक करण्यासाठी पुढे जाऊ शकता. ते खूप महत्वाचे आहे. का? कारण जेव्हा आम्ही "औपचारिकीकरण" म्हणतो तेव्हा तुमच्या प्रक्रिया रुमालावर कुठेतरी कशा होतात याचे वर्णन करणे तुमच्यासाठी महत्त्वाचे असते. तुम्हाला हे समजून घेणे आवश्यक आहे की तुम्ही, उदाहरणार्थ, QA वातावरणात किंवा उत्पादन वातावरणात तैनात केल्यास, ते नेहमी या क्रमाने घडते; या टप्प्यांवर आम्ही चालवतो, उदाहरणार्थ, स्वयंचलित युनिट चाचण्या आणि UI चाचण्या. तैनातीनंतर, तैनाती चांगली झाली की खराब झाली हे आम्ही तपासतो. परंतु तुमच्याकडे आधीच क्रियांची एक स्पष्ट सूची आहे ज्यांची पुनरावृत्ती करणे आवश्यक आहे जेव्हा तुम्ही उत्पादनासाठी तैनात करता.

आणि जेव्हा तुमच्या प्रक्रिया औपचारिक केल्या जातात, तेव्हाच तुम्ही उत्पादने निवडण्यास सुरुवात करता जी तुम्हाला या प्रक्रिया स्वयंचलित करण्यात मदत करतील.

दुर्दैवाने, मी बर्‍याचदा हे उलटे होताना पाहतो. कोणीतरी “DevOps” हा शब्द ऐकताच, ते लगेच जेनकिन्स स्थापित करण्याचा सल्ला देतात, कारण त्यांचा विश्वास आहे की त्यांनी जेनकिन्स स्थापित केल्यावर त्यांच्याकडे DevOps असतील. त्यांनी जेनकिन्स स्थापित केले, जेनकिन्स वेबसाइटवरील “कसे करावे” लेख वाचले, या कसे करायचे या लेखांमध्ये प्रक्रिया भरण्याचा प्रयत्न केला, आणि नंतर लोकांकडे आले आणि लोकांना वाकवले, असे सांगितले की पुस्तकात असे म्हटले आहे की आपल्याला हे असे करणे आवश्यक आहे, म्हणून आम्ही ते अशा प्रकारे करतो.

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

सर्वसाधारणपणे DevOps पद्धतींबद्दल बोलूया. ते काय आहेत? काय फरक आहे? त्यांना कसे वापरायचे? ते महत्त्वाचे का आहेत?

तुम्ही कदाचित ऐकलेल्या पहिल्या सरावाला कंटिन्युअस इंटिग्रेशन म्हणतात. कदाचित प्रकल्पातील एखाद्याला सतत एकात्मता (CI) आहे.

सर्वात मोठी समस्या ही आहे की बहुतेकदा जेव्हा मी एखाद्या व्यक्तीला विचारतो: "तुमच्याकडे प्रकल्पावर CI आहे का?" आणि तो म्हणतो: “होय,” मग जेव्हा मी विचारतो तो काय करतो, तेव्हा तो मला संपूर्ण ऑटोमेशन प्रक्रियेचे वर्णन करतो. हे पूर्णपणे सत्य नाही.

किंबहुना, CI चा सराव हा फक्त एकच कोड बेसमध्ये भिन्न लोक लिहित असलेल्या कोडला एकत्रित करण्याच्या उद्देशाने आहे. इतकंच.

CI सोबत, मार्गात सहसा इतर पद्धती असतात - जसे की सतत तैनाती, प्रकाशन व्यवस्थापन, परंतु आम्ही त्याबद्दल नंतर बोलू.

सीआय स्वतः आम्हाला सांगते की भिन्न लोक कोड लिहितात आणि हा कोड सतत एकाच कोड बेसमध्ये समाकलित केला गेला पाहिजे.

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

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

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

प्रथम, ते आपल्याला वितरणास गती देण्यास अनुमती देते. हे तुम्हाला डिलिव्हरीचा वेग वाढवण्याची परवानगी कशी देते? जेव्हा आम्ही आमच्या कोड बेसमध्ये काही नवीन बदल करतो, तेव्हा आम्ही लगेच या कोडसह काहीतरी करण्याचा प्रयत्न करू शकतो. गुरुवार येईपर्यंत आम्ही वाट पाहत नाही कारण गुरुवारी आम्ही ते QA पर्यावरणाला सोडतो, आम्ही ते इथे आणि इथेच करतो.

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

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

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

जर आमच्याकडे सतत एकात्मतेचा सराव असेल, तर मी माझा कोड लिहिल्याबरोबरच हे आम्हाला आत्ता आणि आत्ता अनेक स्वयंचलित साधनांसह ते तपासण्याची परवानगी देते. हे मला पूर्ण चित्र देऊ शकत नाही, परंतु असे असले तरी, ते कमीतकमी काही धोके दूर करेल. आणि जर काही संभाव्य बग असेल तर मला त्याबद्दल आत्ताच कळेल, म्हणजे अक्षरशः काही मिनिटांत. मला 3 महिने मागे जाण्याची गरज नाही. मला फक्त 2 मिनिटे मागे जावे लागतील. एका चांगल्या कॉफी मशिनला 2 मिनिटांत कॉफी तयार करायलाही वेळ मिळणार नाही, त्यामुळे ते खूपच छान आहे.

याचे मूल्य आहे की प्रत्येक प्रकल्पावर वेळोवेळी पुनरावृत्ती केली जाऊ शकते, म्हणजे. फक्त तुम्ही सेट केलेले नाही. तुम्ही दोन्ही सराव स्वतःच पुनरावृत्ती करू शकता आणि तुम्ही प्रकल्पात केलेल्या प्रत्येक नवीन बदलासाठी CI स्वतःच पुनरावृत्ती होईल. हे तुम्हाला संसाधने ऑप्टिमाइझ करण्याची अनुमती देते कारण तुमचा कार्यसंघ अधिक कार्यक्षमतेने कार्य करतो. तुम्ही 3 महिन्यांपूर्वी ज्या कोडसह काम केले होते त्या कोडमधून तुम्हाला बग येईल अशी परिस्थिती आता तुमच्याकडे असणार नाही. जेव्हा तुम्ही बसून पहिले दोन तास नंतर काय झाले ते समजून घेण्याचा प्रयत्न करता आणि तुम्ही काहीतरी दुरुस्त करण्यास सुरुवात करण्यापूर्वी संदर्भाच्या सारामध्ये जाल तेव्हा तुम्हाला यापुढे संदर्भ स्विचिंग होणार नाही.

या प्रथेचे यश किंवा अपयश आपण कसे मोजू शकतो? आम्ही CI प्रकल्पावर काय अंमलबजावणी केली आहे याची तुम्ही बिग बॉसला तक्रार केल्यास, तो ब्ला ब्ला ब्ला ऐकतो. आम्ही ते अंमलात आणले, ठीक आहे, पण का, ते आमच्यासाठी काय आणले, आम्ही ते कसे मोजतो, आम्ही ते किती योग्य किंवा चुकीच्या पद्धतीने राबवत आहोत?

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

आमच्याकडे आणखी एक सराव आहे ऑटोमेशन चाचणी सराव, जो बहुतेक वेळा CI सरावासह येतो. ते हातात हात घालून जातात.

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

आमच्याकडे एकत्रीकरण चाचण्या देखील आहेत ज्या आम्हाला हे समजू देतात की भिन्न मॉड्यूल एकमेकांशी कसे एकत्रित होतात. ते देखील चांगले आहे.

आमच्याकडे UI ऑटोमेशन चाचण्या असू शकतात ज्या आम्हाला हे तपासण्याची परवानगी देतात की UI सह कार्य ग्राहकाने सेट केलेल्या काही विशिष्ट आवश्यकता पूर्ण करते इ.

तुम्ही चालवलेल्या विशिष्ट चाचण्या तुम्ही किती वेळा चालवता यावर परिणाम होऊ शकतो. युनिट चाचण्या सहसा लहान आणि लहान लिहिल्या जातात. आणि ते नियमितपणे लाँच केले जाऊ शकतात.

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

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

आणि आम्ही त्यांना सांगितले की जर तुम्हाला अधिक उत्पादनक्षम व्हायचे असेल, तर तुमच्यासाठी स्वयंचलित चाचणी पद्धती लागू करणे अर्थपूर्ण आहे, कारण हेच तुम्हाला येथे, आत्ता त्रास देत आहे.

सतत तैनातीचा सराव करा. छान, तुम्ही बांधकाम पूर्ण केले आहे. हे आधीच चांगले आहे. तुमचा कोड संकलित झाला आहे. आता हे बिल्ड काही वातावरणात उपयोजित करणे चांगले होईल. चला विकासकांसाठी वातावरणात म्हणूया.

ते महत्त्वाचे का आहे? प्रथम, तुम्ही तैनाती प्रक्रियेतच किती यशस्वी आहात ते पाहू शकता. मला असे प्रकल्प भेटले आहेत, जेव्हा मी विचारले: “तुम्ही ऍप्लिकेशनची नवीन आवृत्ती कशी उपयोजित कराल?”, मुले मला सांगतात: “आम्ही ते एकत्र करतो आणि झिप आर्काइव्हमध्ये पॅक करतो. आम्ही ते प्रशासकाला मेलद्वारे पाठवतो. प्रशासक हे संग्रहण डाउनलोड आणि विस्तृत करतो. आणि संपूर्ण ऑफिस सर्व्हर नवीन आवृत्ती उचलेल अशी प्रार्थना करू लागते.”

चला सोप्या गोष्टीपासून सुरुवात करूया. उदाहरणार्थ, ते संग्रहणात CSS टाकायला विसरले किंवा java-script फाइल नावात हॅशटॅग बदलायला विसरले. आणि जेव्हा आम्ही सर्व्हरला विनंती करतो, तेव्हा ब्राउझरला वाटते की त्याच्याकडे ही जावा-स्क्रिप्ट फाइल आधीपासूनच आहे आणि ती डाउनलोड न करण्याचा निर्णय घेतो. आणि एक जुनी आवृत्ती होती, काहीतरी गहाळ होते. सर्वसाधारणपणे, अनेक समस्या असू शकतात. म्हणून, सतत उपयोजनाचा सराव तुम्हाला किमान एक स्वच्छ संदर्भ प्रतिमा घेतल्यास आणि पूर्णपणे स्वच्छ नवीन वातावरणात अपलोड केल्यास काय होईल याची चाचणी घेण्यास अनुमती देते. हे कुठे जाते ते तुम्ही पाहू शकता.

तसेच, जेव्हा तुम्ही एकमेकांमध्ये कोड समाकलित करता, उदा. कमांड दरम्यान, हे तुम्हाला ते UI वर कसे दिसते हे देखील पाहण्यास अनुमती देते.

व्हॅनिला जावा-स्क्रिप्टचा भरपूर वापर केला जातो तेव्हा उद्भवणाऱ्या समस्यांपैकी एक म्हणजे दोन विकसकांनी विंडो ऑब्जेक्टमध्ये एकाच नावाचे व्हेरिएबल अविचारीपणे घोषित केले. आणि मग, आपल्या नशिबावर अवलंबून. ज्याची जावा-स्क्रिप्ट फाइल दुसऱ्यांदा बाहेर काढली जाते ती दुसऱ्याचे बदल ओव्हरराइट करेल. हे देखील खूप रोमांचक आहे. तुम्ही आत या: एक गोष्ट एका व्यक्तीसाठी काम करते, दुसरी गोष्ट दुसऱ्यासाठी काम करत नाही. आणि जेव्हा हे सर्व उत्पादनात येते तेव्हा ते "अद्भुत" असते.

आमच्याकडे असलेला पुढील सराव म्हणजे ऑटोमॅटिक रिस्टोअरचा सराव, म्हणजे ऍप्लिकेशनच्या मागील आवृत्तीवर परत जाणे.

विकसकांसाठी हे महत्त्वाचे का आहे? अजूनही असे लोक आहेत ज्यांना 90 च्या दशकातील दूरची आठवण आहे, जेव्हा संगणक मोठे होते आणि प्रोग्राम लहान होते. आणि वेब डेव्हलपमेंटचा एकमेव मार्ग PHP द्वारे होता. असे नाही की PHP ही वाईट भाषा आहे, जरी ती आहे.

पण समस्या वेगळी होती. जेव्हा आम्ही आमच्या php साइटची नवीन आवृत्ती उपयोजित केली, तेव्हा आम्ही ती कशी उपयोजित केली? बर्याचदा आम्ही फार मॅनेजर किंवा दुसरे काहीतरी उघडले. आणि या फाईल्स FTP वर अपलोड केल्या. आणि आम्हाला अचानक लक्षात आले की आमच्याकडे काही लहान, लहान बग आहेत, उदाहरणार्थ, आम्ही एक अर्धविराम ठेवण्यास विसरलो किंवा डेटाबेससाठी पासवर्ड बदलण्यास विसरलो आणि डेटाबेससाठी एक पासवर्ड आहे, जो स्थानिक होस्टवर आहे. आणि आम्ही FTP शी त्वरीत कनेक्ट होण्याचे ठरवतो आणि तिथेच फाइल्स संपादित करतो. ही फक्त आग आहे! 90 च्या दशकात हेच लोकप्रिय होते.

पण, जर तुम्ही कॅलेंडर बघितले नसेल, तर 90 चे दशक जवळपास 30 वर्षांपूर्वीचे होते. आता सर्व काही थोडे वेगळे घडत आहे. आणि जेव्हा ते तुम्हाला सांगतात तेव्हा शोकांतिकेच्या प्रमाणाची कल्पना करण्याचा प्रयत्न करा: “आम्ही उत्पादनासाठी तैनात केले, परंतु तेथे काहीतरी चूक झाली. हा तुमचा FTP लॉगिन आणि पासवर्ड आहे, प्रोडक्शनशी कनेक्ट करा आणि तिथे त्वरीत त्याचे निराकरण करा.” आपण चक नॉरिस असल्यास, हे कार्य करेल. जर तसे नसेल, तर तुम्ही जोखीम घ्याल की तुम्ही एक बग दुरुस्त केल्यास, तुम्ही आणखी 10 कराल. म्हणूनच मागील आवृत्तीवर परत येण्याचा हा सराव तुम्हाला बरेच काही साध्य करण्यास अनुमती देतो.

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

आता आधीच्या दोन पद्धती एकत्र करण्याचा प्रयत्न करूया. आम्हाला रिलीझ मॅनेजमेंट नावाचे तिसरे मिळेल.

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

याशिवाय आणखी एक दुःख आहे. जेव्हा तुम्ही तयार करता, अगदी त्याच मशीनवर, तुम्ही तेच स्त्रोत तयार कराल, तरीही तुम्हाला खात्री नाही की हे मशीन त्याच स्थितीत आहे जसे ते शेवटच्या बिल्डच्या वेळी होते.

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

म्हणून, रिलीझ मॅनेजमेंट प्रॅक्टिस आर्टिफॅक्ट रिपॉझिटरी किंवा गॅलरी किंवा लायब्ररी नावाचे अतिरिक्त अॅब्स्ट्रॅक्शन सादर करण्याचे सुचवते. तुम्हाला हवं ते म्हणता येईल.

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

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

याव्यतिरिक्त, जेव्हा आमच्याकडे अशी गॅलरी असते, तेव्हा आम्ही मागील आवृत्तीवर रोलबॅक करण्याबद्दल बोललो तेव्हा आम्ही शेवटच्या स्लाइडवर संबोधित केलेल्या जोखमींचे निराकरण करण्यात आम्हाला मदत करते. जर तुम्ही चुकून काहीतरी चुकीचे उपयोजित केले असेल, तर तुम्ही या गॅलरीमधून कधीही इतर कोणतीही मागील आवृत्ती घेऊ शकता आणि ती या वातावरणात त्याच प्रकारे अनडिप्लॉय करू शकता. काही चूक झाल्यास हे तुम्हाला सहजपणे मागील आवृत्तीवर परत येण्याची अनुमती देते.

आणखी एक उत्तम सराव आहे. तुम्ही आणि मी सर्वजण समजतो की जेव्हा आम्ही आमचे ॲप्लिकेशन मागील आवृत्तीवर परत आणतो, तेव्हा याचा अर्थ असा होऊ शकतो की आम्हाला मागील आवृत्तीच्या पायाभूत सुविधांची देखील आवश्यकता आहे.

जेव्हा आपण व्हर्च्युअल इन्फ्रास्ट्रक्चरबद्दल बोलतो, तेव्हा अनेकांना असे वाटते की हे असे काहीतरी आहे जे प्रशासकांनी सेट केले आहे. आणि जर तुम्हाला नवीन सर्व्हरची आवश्यकता असेल ज्यावर तुम्हाला तुमच्या ऍप्लिकेशनच्या नवीन आवृत्तीची चाचणी घ्यायची असेल, तर तुम्ही अॅडमिन किंवा डेव्हॉप्सना तिकीट लिहावे. डेव्हॉप्सना यासाठी 3 आठवडे लागतील. आणि 3 आठवड्यांनंतर ते तुम्हाला सांगतील की आम्ही तुमच्यासाठी एक कोर, दोन गीगाबाइट्स रॅम आणि डॉटनेटशिवाय विंडोज सर्व्हरसह व्हर्च्युअल मशीन स्थापित केले आहे. तुम्ही म्हणता: "पण मला डॉटनेट हवे होते." ते: "ठीक आहे, तीन आठवड्यांनी परत या."

कल्पना अशी आहे की संहिता पद्धती म्हणून पायाभूत सुविधांचा वापर करून, तुम्ही तुमच्या व्हर्च्युअल इन्फ्रास्ट्रक्चरला फक्त दुसरे संसाधन मानू शकता.

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

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

पुढील सराव, जी अस्तित्वात आहे आणि महत्त्वाची देखील आहे, परंतु ज्याचा वापर फार कमी लोक करतात, तो म्हणजे ऍप्लिकेशन परफॉर्मन्स मॉनिटरिंग.

मला ऍप्लिकेशन परफॉर्मन्स मॉनिटरिंगबद्दल फक्त एक गोष्ट सांगायची होती. या सराव मध्ये सर्वात महत्वाचे काय आहे? अॅप्लिकेशन परफॉर्मन्स मॉनिटरिंग हे अपार्टमेंटच्या दुरुस्तीसारखेच आहे. ही अंतिम अवस्था नाही, ती एक प्रक्रिया आहे. आपण ते नियमितपणे करणे आवश्यक आहे.

चांगल्या प्रकारे, जवळजवळ प्रत्येक बिल्डवर ऍप्लिकेशन परफॉर्मन्स मॉनिटरिंग करणे चांगले होईल, जरी तुम्ही समजता, हे नेहमीच शक्य नसते. परंतु, कमीतकमी, प्रत्येक प्रकाशनासाठी ते पूर्ण करणे आवश्यक आहे.

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

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

आमच्याकडे पुढील सराव आहे कॉन्फिगरेशन व्यवस्थापन सराव. हे गांभीर्याने घेणारे फार कमी आहेत. पण माझ्यावर विश्वास ठेवा, ही खरं तर खूप गंभीर गोष्ट आहे.

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

आणि मी म्हणतो: “मित्रांनो, ठीक आहे, तुम्ही तुमचे उत्पादन वातावरण फायरवॉलने बंद केले आहे, परंतु तुमच्याकडे उत्पादन डेटाबेसचे लॉगिन आणि पासवर्ड अगदी सोर्स कंट्रोलमध्ये आहे आणि कोणताही डेव्हलपर तो वाचू शकतो ही एक मोठी सुरक्षितता धोका आहे. . आणि कोडच्या दृष्टिकोनातून तुमचा अर्ज कितीही सुरक्षित असला तरीही, जर तुम्ही तो स्त्रोत नियंत्रणात सोडलात, तर तुम्ही कुठेही ऑडिट पास करणार नाही.” तेच मी बोलतोय.

कॉन्फिगरेशन व्यवस्थापन. आमच्याकडे वेगवेगळ्या वातावरणात भिन्न कॉन्फिगरेशन असू शकतात. उदाहरणार्थ, आमच्याकडे QA, डेमो, उत्पादन वातावरण इत्यादीसाठी डेटाबेससाठी भिन्न लॉगिन आणि पासवर्ड असू शकतात.

हे कॉन्फिगरेशन स्वयंचलित देखील असू शकते. ते नेहमी अनुप्रयोगापासून वेगळे असावे. का? तुम्ही एकदाच अॅप्लिकेशन तयार केल्यामुळे, आणि त्यानंतर तुम्ही अशा आणि अशा IP किंवा अशा आणि अशा IP द्वारे SQL सर्व्हरशी कनेक्ट झालात की नाही याची पर्वा ऍप्लिकेशनला होत नाही, ते समान कार्य केले पाहिजे. म्हणूनच, जर अचानक तुमच्यापैकी कोणीतरी कोडमधील कनेक्शन स्ट्रिंग हार्डकोड करत असेल, तर लक्षात ठेवा की मी तुम्हाला शोधून काढेन आणि तुम्ही माझ्यासोबत त्याच प्रोजेक्टवर आढळल्यास तुम्हाला शिक्षा करीन. हे नेहमी वेगळ्या कॉन्फिगरेशनमध्ये ठेवले जाते, उदाहरणार्थ, web.config मध्ये.

आणि हे कॉन्फिगरेशन आधीच स्वतंत्रपणे व्यवस्थापित केले गेले आहे, म्हणजे अगदी हा क्षण आहे जेव्हा विकासक आणि प्रशासक एकाच खोलीत येऊन बसू शकतात. आणि विकसक म्हणू शकतो: “पाहा, माझ्या अर्जाच्या बायनरी येथे आहेत. ते काम करतात. अनुप्रयोगाला कार्य करण्यासाठी डेटाबेस आवश्यक आहे. येथे बायनरीजच्या पुढे एक फाइल आहे. या फाइलमध्ये, हे फील्ड लॉगिनसाठी जबाबदार आहे, हे पासवर्डसाठी आहे, हे आयपीसाठी आहे. ते कुठेही तैनात करा." आणि ते प्रशासकासाठी सोपे आणि स्पष्ट आहे. हे कॉन्फिगरेशन व्यवस्थापित करून तो खरोखर कुठेही तैनात करू शकतो.

आणि शेवटचा सराव ज्याबद्दल मी बोलू इच्छितो ती एक सराव आहे जी ढगांशी खूप संबंधित आहे. आणि आपण क्लाउडमध्ये काम केल्यास ते जास्तीत जास्त प्रभाव आणते. हे आपल्या वातावरणाचे स्वयंचलित काढणे आहे.

मला माहित आहे की या परिषदेत मी काम करत असलेल्या संघांमधून बरेच लोक आहेत. आणि मी काम करत असलेल्या सर्व संघांसह, आम्ही हा सराव वापरतो.

का? अर्थात, प्रत्येक विकसकाकडे 24/7 काम करणारी व्हर्च्युअल मशीन असल्यास ते चांगले होईल. परंतु कदाचित ही आपल्यासाठी बातमी आहे, कदाचित आपण लक्ष दिले नाही, परंतु विकसक स्वतः 24/7 कार्य करत नाही. डेव्हलपर सहसा दिवसाचे 8 तास काम करतो. जरी तो लवकर कामावर आला तरी, त्याच्याकडे एक मोठा लंच असतो ज्या दरम्यान तो जिमला जातो. डेव्हलपर खरोखर ही संसाधने वापरतो तेव्हा दिवसाचे 12 तास असू द्या. आमच्या कायद्यानुसार, आमच्याकडे आठवड्यातील 5 पैकी 7 दिवस कामाचे दिवस मानले जातात.

त्यानुसार, आठवड्याच्या दिवशी हे मशीन 24 तास काम करू नये, परंतु केवळ 12 तास काम करू नये आणि आठवड्याच्या शेवटी हे मशीन अजिबात काम करू नये. असे दिसते की सर्वकाही अगदी सोपे आहे, परंतु येथे काय सांगणे महत्त्वाचे आहे? या मूलभूत शेड्यूलवर या सोप्या सरावाची अंमलबजावणी करून, ते तुम्हाला या वातावरणाची देखभाल करण्याची किंमत 70% ने कमी करण्यास अनुमती देते, म्हणजे तुम्ही तुमच्या dev, QA, डेमो, पर्यावरणाची किंमत घेतली आणि त्यास 3 ने विभाजित केले.

उरलेल्या पैशांचे करायचे काय, हा प्रश्न आहे. उदाहरणार्थ, विकसकांनी रीशार्पर विकत घेतले नाही तर ते विकत घेतले पाहिजेत. किंवा कॉकटेल पार्टी करा. जर तुमच्याकडे पूर्वी एक वातावरण असेल ज्यामध्ये dev आणि QA दोघेही चरत होते आणि तेच आहे, आता तुम्ही 3 भिन्न बनवू शकता जे वेगळे केले जातील आणि लोक एकमेकांमध्ये हस्तक्षेप करणार नाहीत.

सतत कार्यप्रदर्शन मोजमाप असलेल्या स्लाइडच्या संदर्भात, आमच्याकडे प्रकल्पातील डेटाबेसमध्ये 1 रेकॉर्ड असल्यास, दोन महिन्यांनंतर एक दशलक्ष असल्यास आम्ही कामगिरीची तुलना कशी करू शकतो? कामगिरी मोजण्याचा मुद्दा का आणि काय आहे हे कसे समजून घ्यावे?

हा एक चांगला प्रश्न आहे, कारण आपण नेहमी समान संसाधनांवर कार्यप्रदर्शन मोजले पाहिजे. म्हणजेच, तुम्ही नवीन कोड आणता, तुम्ही नवीन कोडवर कार्यप्रदर्शन मोजता. उदाहरणार्थ, तुम्हाला भिन्न कार्यप्रदर्शन परिस्थितीची चाचणी घेण्याची आवश्यकता आहे, समजा तुम्हाला अनुप्रयोग हलक्या लोडवर कसे कार्य करते हे तपासायचे आहे, जेथे 1 वापरकर्ते आहेत आणि डेटाबेस आकार 000 गीगाबाइट आहे. तुम्ही ते मोजले आणि आकडे मिळाले. पुढे आपण दुसरी परिस्थिती घेऊ. उदाहरणार्थ, 5 वापरकर्ते, डेटाबेस आकार 5 टेराबाइट. आम्ही निकाल प्राप्त केले आणि ते लक्षात ठेवले.

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

आम्ही विशेष चाचणी वातावरणात कामगिरी मोजण्याबद्दल बोलत आहोत का? म्हणजेच हे उत्पादन नाही का?

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

समजले धन्यवाद!

कोणतेही प्रश्न नसल्यास, मला वाटते की आम्ही पूर्ण करू शकतो. धन्यवाद!

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