నివేదిక కొన్ని DevOps అభ్యాసాల గురించి మాట్లాడుతుంది, కానీ డెవలపర్ కోణం నుండి. సాధారణంగా, DevOpsలో చేరిన ఇంజనీర్లందరూ ఇప్పటికే వారి బెల్ట్‌లో అనేక సంవత్సరాల పరిపాలనా అనుభవం కలిగి ఉన్నారు. కానీ ఇక్కడ డెవలపర్‌కు చోటు లేదని దీని అర్థం కాదు. చాలా తరచుగా, డెవలపర్లు “రోజు యొక్క తదుపరి అత్యవసరమైన బగ్‌ని” పరిష్కరించడంలో బిజీగా ఉన్నారు మరియు వారికి DevOps ఫీల్డ్‌ని త్వరగా పరిశీలించడానికి కూడా సమయం లేదు. రచయిత యొక్క అవగాహనలో, DevOps, ముందుగా, ఇంగితజ్ఞానం. రెండవది, ఇది మరింత ప్రభావవంతంగా ఉండటానికి ఒక అవకాశం. మీరు డెవలపర్ అయితే, ఇంగితజ్ఞానం కలిగి ఉండి, టీమ్ ప్లేయర్‌గా మరింత ప్రభావవంతంగా ఉండాలనుకుంటే, ఈ నివేదిక మీ కోసం.
నన్ను నేను పరిచయం చేసుకోనివ్వండి, గదిలో నాకు తెలియని వ్యక్తులు ఉన్నారని నేను పూర్తిగా అంగీకరిస్తున్నాను. నా పేరు అంటోన్ బోయ్కో, నేను మైక్రోసాఫ్ట్ అజూర్ MVPని. MVP అంటే ఏమిటి? ఇది మోడల్-వ్యూ-ప్రెజెంటర్. మోడల్-వ్యూ-ప్రెజెంటర్ సరిగ్గా నేనే.
అదనంగా, నేను ప్రస్తుతం సిక్లమ్‌లో సొల్యూషన్ ఆర్కిటెక్ట్ హోదాను కలిగి ఉన్నాను. మరియు ఇటీవలే నేను అలాంటి అందమైన డొమైన్‌ను కొనుగోలు చేసాను మరియు నేను సాధారణంగా ప్రెజెంటేషన్‌లలో చూపించే నా ఇమెయిల్‌ను నవీకరించాను. మీరు నాకు ఇక్కడ వ్రాయవచ్చు: me [dog] byokoant.pro. మీరు ప్రశ్నలతో నాకు ఇమెయిల్ చేయవచ్చు. నేను సాధారణంగా వారికి సమాధానం ఇస్తాను. రాజకీయాలు మరియు మతం అనే రెండు అంశాలకు సంబంధించిన ప్రశ్నలను ఇమెయిల్ ద్వారా స్వీకరించడం నాకు ఇష్టం లేదు. మీరు ఇమెయిల్ ద్వారా మిగతా వాటి గురించి నాకు వ్రాయవచ్చు. కొంత సమయం గడిచిపోతుంది, నేను సమాధానం ఇస్తాను.
మీ గురించి కొన్ని మాటలు:
- నేను 10 ఏళ్లుగా ఈ రంగంలో ఉన్నాను.
- నేను మైక్రోసాఫ్ట్‌లో పనిచేశాను.
- మేము 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 మస్కటీర్స్ ఏమిటో తెలుసుకోవడానికి మీరు ఆన్‌లైన్‌లో శోధించవచ్చు. మీరు ఈ కథనాన్ని కనుగొనే అవకాశం ఉంది. ఎందుకు 3 మస్కటీర్స్? దిగువన ఇది ఇలా చెబుతోంది: వ్యక్తులు, ప్రక్రియలు మరియు ఉత్పత్తులు, అనగా. PPP - Porthos, Porthos మరియు Porthos. DevOps యొక్క 3 మస్కటీర్స్ ఇక్కడ ఉన్నాయి. ఈ వ్యాసం ఇది ఎందుకు ముఖ్యమైనది మరియు దాని గురించి మరింత వివరంగా వివరిస్తుంది.
మీరు DevOps సంస్కృతిని అమలు చేయడం ప్రారంభించినప్పుడు, అది క్రింది క్రమంలో అమలు చేయడం చాలా ముఖ్యం.
మొదట్లో మీరు ప్రజలతో మాట్లాడాలి. మరియు అది ఏమిటో మరియు వారు దాని నుండి కొన్ని ప్రయోజనాలను ఎలా పొందవచ్చో మీరు ప్రజలకు వివరించాలి.
మా సమావేశాన్ని డాట్‌నెట్ ఫెస్ట్ అంటారు. నిర్వాహకులు నాకు చెప్పినట్లుగా, మేము ప్రధానంగా డెవలపర్‌ల ప్రేక్షకులను ఇక్కడకు ఆహ్వానించాము, కాబట్టి హాల్‌లోని చాలా మంది వ్యక్తులు అభివృద్ధిలో పాల్గొంటారని నేను ఆశిస్తున్నాను.
మేము వ్యక్తుల గురించి మాట్లాడుతాము, డెవలపర్లు ప్రతిరోజూ ఏమి చేయాలనుకుంటున్నారు అనే దాని గురించి మాట్లాడుతాము. వారికి ఎక్కువగా ఏమి కావాలి? వారు కొన్ని కొత్త కోడ్‌లను వ్రాయాలనుకుంటున్నారు, కొత్త వింతైన ఫ్రేమ్‌వర్క్‌లను ఉపయోగించాలి, కొత్త ఫీచర్లను సృష్టించాలి. డెవలపర్లు కనీసం ఏమి కోరుకుంటున్నారు? పాత బగ్‌లను పరిష్కరించండి. మీరు నాతో ఏకీభవిస్తారని ఆశిస్తున్నాను. డెవలపర్లు కోరుకునేది ఇదే. వారు కొత్త ఫీచర్లను వ్రాయాలనుకుంటున్నారు, వారు బగ్‌లను పరిష్కరించకూడదు.
నిర్దిష్ట డెవలపర్ ఉత్పత్తి చేసే బగ్‌ల సంఖ్య అతని చేతులు ఎంత నిటారుగా ఉన్నాయి మరియు అవి అతని భుజాల నుండి ఎంత పెరుగుతాయి అనే దానిపై ఆధారపడి ఉంటుంది మరియు అతని బట్ పాకెట్స్ నుండి కాదు. అయినప్పటికీ, మనకు పెద్ద ప్రాజెక్ట్ ఉన్నప్పుడు, కొన్నిసార్లు ప్రతిదీ ట్రాక్ చేయడం అసాధ్యం, కాబట్టి మరింత స్థిరమైన మరియు అధిక నాణ్యత గల కోడ్‌ను వ్రాయడంలో మాకు సహాయపడే కొన్ని విధానాలను ఉపయోగించడం మంచిది.
QAలు ఎక్కువగా ఏమి కోరుకుంటున్నారు? వాళ్ళు హాల్లో ఉన్నారో లేదో నాకు తెలియదు. నాకు QA కావాలని చెప్పడం నాకు చాలా కష్టం, ఎందుకంటే నేను ఎప్పుడూ ఒకదాన్ని కాను. మరియు అబ్బాయిలకు ఎటువంటి నేరం లేదు, నేను ఎప్పటికీ చేయనని ఆశిస్తున్నాను అని చెప్పబడుతుంది. కానీ నేను వారి పనిని అర్ధంలేని మరియు పనికిరానిదిగా భావించే కారణంతో కాదు, కానీ నేను ఈ పనిని సమర్ధవంతంగా చేయగల వ్యక్తిగా భావించనందున, నేను దీన్ని చేయడానికి కూడా ప్రయత్నించను. కానీ నేను అర్థం చేసుకున్నదాని ప్రకారం, QAకి ఎక్కువగా నచ్చనిది ఉదయం పని చేయడం, నిరంతరం కొన్ని రకాల రిగ్రెషన్ పరీక్షలను నిర్వహించడం, డెవలపర్‌లకు 3 స్ప్రింట్‌ల క్రితం నివేదించిన అదే బగ్‌లపై అడుగు పెట్టడం మరియు ఇలా చెప్పడం: “మీరు ఎప్పుడు చేస్తాం , Monsieur D 'Artagnan, ఈ బగ్‌ని పరిష్కరించండి.' మరియు మాన్సియర్ డి'అర్టగ్నన్ అతనికి సమాధానమిస్తాడు: "అవును, అవును, అవును, నేను ఇప్పటికే దాన్ని పరిష్కరించాను." మరియు నేను ఒక బగ్‌ని పరిష్కరించాను మరియు మార్గం వెంట 5 చేసాను.
ఉత్పత్తిలో ఈ పరిష్కారాన్ని సమర్ధించే వ్యక్తులు ఈ పరిష్కారం దోషాలు లేకుండా పని చేయాలని కోరుకుంటారు, తద్వారా వారు ప్రతి శుక్రవారం సర్వర్‌ను రీబూట్ చేయాల్సిన అవసరం లేదు, సాధారణ వ్యక్తులందరూ బార్‌కి వెళ్లినప్పుడు. డెవలపర్లు శుక్రవారం నాడు మోహరించారు, అడ్మిన్‌లు శనివారం వరకు కూర్చుని, ఈ విస్తరణను పూర్తి చేయడానికి ప్రయత్నిస్తున్నారు.
మరియు వారు అదే సమస్యలను పరిష్కరించే లక్ష్యంతో ఉన్నారని మీరు ప్రజలకు వివరించినప్పుడు, మీరు ప్రక్రియలను అధికారికీకరించడానికి కొనసాగవచ్చు. ఇది చాలా ముఖ్యమైనది. ఎందుకు? ఎందుకంటే మేము "ఫార్మలైజేషన్" అని చెప్పినప్పుడు, మీ ప్రక్రియలు కనీసం ఎక్కడైనా రుమాలుపై ఎలా జరుగుతాయో వివరించడం మీకు ముఖ్యం. మీరు, ఉదాహరణకు, QA పర్యావరణం లేదా ఉత్పత్తి వాతావరణానికి అమలు చేస్తే, అది ఎల్లప్పుడూ ఈ క్రమంలోనే జరుగుతుందని మీరు అర్థం చేసుకోవాలి; ఈ దశల్లో మేము అమలు చేస్తాము, ఉదాహరణకు, ఆటోమేటిక్ యూనిట్ పరీక్షలు మరియు UI పరీక్షలు. విస్తరణ తర్వాత, విస్తరణ బాగా జరిగిందా లేదా పేలవంగా ఉందా అని మేము తనిఖీ చేస్తాము. కానీ మీరు ఉత్పత్తికి అమలు చేసినప్పుడు పదే పదే పునరావృతమయ్యే చర్యల యొక్క స్పష్టమైన జాబితాను మీరు ఇప్పటికే కలిగి ఉన్నారు.
И только когда у вас процессы формализованы, вы приступаете к выбору продуктов, которые помогут вам вот эти процессы автоматизировать.
దురదృష్టవశాత్తు, ఇది రివర్స్‌లో జరగడాన్ని నేను చాలా తరచుగా చూస్తాను. ఎవరైనా "DevOps" అనే పదాన్ని విన్న వెంటనే, వారు వెంటనే Jenkinsని ఇన్‌స్టాల్ చేయమని సూచిస్తారు, ఎందుకంటే వారు Jenkinsని ఇన్‌స్టాల్ చేసిన వెంటనే, వారికి DevOps ఉంటుందని వారు నమ్ముతారు. వారు జెంకిన్స్‌ని ఇన్‌స్టాల్ చేసారు, జెంకిన్స్ వెబ్‌సైట్‌లోని “హౌ టు” కథనాలను చదివి, ఈ హౌ టు ఆర్టికల్‌లలో ప్రాసెస్‌లను నింపడానికి ప్రయత్నించారు, ఆపై వ్యక్తుల వద్దకు వచ్చి, మీరు దీన్ని ఈ విధంగా చేయాలని పుస్తకం చెబుతుందని చెప్పారు, కాబట్టి మేము ఈ విధంగా చేస్తాము.
జెంకిన్స్ చెడ్డ సాధనం అని కాదు. ఏ విధంగానూ చెప్పాలని నా ఉద్దేశ్యం కాదు. కానీ ఇది ఉత్పత్తులలో ఒకటి మాత్రమే. మరియు మీరు ఉపయోగించే ఉత్పత్తి మీ చివరి నిర్ణయంగా ఉండాలి మరియు మీ మొదటిది కాదు. మీ ఉత్పత్తి సంస్కృతి మరియు విధానాల అమలు ద్వారా నడపబడకూడదు. ఇది అర్థం చేసుకోవడం చాలా ముఖ్యం, అందుకే నేను ఈ స్లయిడ్‌లో ఎక్కువ సమయాన్ని వెచ్చించాను మరియు ఇవన్నీ చాలా కాలం పాటు వివరించాను.
సాధారణంగా DevOps అభ్యాసాల గురించి మాట్లాడుకుందాం. ఏమిటి అవి? తేడా ఏమిటి? వాటిని ఎలా ప్రయత్నించాలి? అవి ఎందుకు ముఖ్యమైనవి?
మీరు విన్న మొదటి అభ్యాసాన్ని నిరంతర ఇంటిగ్రేషన్ అంటారు. బహుశా ప్రాజెక్ట్‌లో ఎవరైనా కంటిన్యూయస్ ఇంటిగ్రేషన్ (CI) కలిగి ఉండవచ్చు.
అతి పెద్ద సమస్య ఏమిటంటే, నేను చాలా తరచుగా ఒక వ్యక్తిని అడిగినప్పుడు: "మీకు ప్రాజెక్ట్‌లో CI ఉందా?" మరియు అతను ఇలా అన్నాడు: "అవును," అప్పుడు అతను ఏమి చేస్తాడు అని నేను అడిగినప్పుడు, అతను నాకు పూర్తిగా ఆటోమేషన్ ప్రక్రియను వివరిస్తాడు. ఇది పూర్తిగా నిజం కాదు.
వాస్తవానికి, CI యొక్క అభ్యాసం వేర్వేరు వ్యక్తులు వ్రాసే కోడ్‌ను ఒక రకమైన సింగిల్ కోడ్ బేస్‌లో ఏకీకృతం చేయడం లక్ష్యంగా పెట్టుకుంది. అంతే.
CIతో పాటు, నిరంతర విస్తరణ, విడుదల నిర్వహణ వంటి ఇతర అభ్యాసాలు సాధారణంగా ఉంటాయి, కానీ మేము దాని గురించి తర్వాత మాట్లాడుతాము.
వేర్వేరు వ్యక్తులు కోడ్‌ని వ్రాస్తారని మరియు ఈ కోడ్‌ని నిరంతరం ఒకే కోడ్ బేస్‌లో విలీనం చేయాలని CI స్వయంగా చెబుతుంది.
ఇది మనకు ఏమి ఇస్తుంది మరియు ఇది ఎందుకు ముఖ్యమైనది? మనకు డాట్‌నెట్ ఉంటే, అది మంచిది, ఇది కంపైల్డ్ భాష, మేము మా అప్లికేషన్‌ను కంపైల్ చేయవచ్చు. ఇది కంపైల్ చేస్తే, ఇది ఇప్పటికే మంచి సంకేతం. దీని అర్థం ఇంకా ఏమీ లేదు, కానీ మనం కనీసం కంపైల్ చేయగల మొదటి మంచి సంకేతం.
అప్పుడు మేము కొన్ని పరీక్షలను అమలు చేయవచ్చు, ఇది కూడా ప్రత్యేక అభ్యాసం. పరీక్షలు అన్ని ఆకుపచ్చగా ఉన్నాయి - ఇది రెండవ మంచి సంకేతం. కానీ మళ్ళీ, ఇది ఏమీ అర్థం కాదు.
కానీ మీరు దీన్ని ఎందుకు చేస్తారు? ఈ రోజు నేను మాట్లాడే అన్ని అభ్యాసాలు దాదాపు ఒకే విలువను కలిగి ఉంటాయి, అంటే దాదాపు ఒకే విధమైన ప్రయోజనాలను కలిగి ఉంటాయి మరియు ఇంచుమించు అదే విధంగా కొలుస్తారు.
మొదట, ఇది డెలివరీని వేగవంతం చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. డెలివరీని వేగవంతం చేయడానికి ఇది మిమ్మల్ని ఎలా అనుమతిస్తుంది? మేము మా కోడ్ బేస్‌లో కొన్ని కొత్త మార్పులు చేసినప్పుడు, మేము వెంటనే ఈ కోడ్‌తో ఏదైనా చేయడానికి ప్రయత్నించవచ్చు. గురువారం వచ్చే వరకు మేము వేచి ఉండము ఎందుకంటే గురువారం మేము దానిని QA ఎన్విరాన్‌మెంట్‌కు విడుదల చేస్తాము, మేము దీన్ని ఇక్కడే మరియు ఇక్కడే చేస్తాము.
నా జీవితంలోని ఒక విషాద కథను మీకు చెప్తాను. ఇది చాలా కాలం క్రితం, నేను ఇంకా యవ్వనంగా మరియు అందంగా ఉన్నప్పుడు. ఇప్పుడు నేను ఇప్పటికే యవ్వనంగా, అందంగా మరియు తెలివిగా మరియు నిరాడంబరంగా ఉన్నాను. కొంతకాలం క్రితం నేను ఒక ప్రాజెక్ట్‌లో ఉన్నాను. మాకు దాదాపు 30 మంది డెవలపర్‌లతో కూడిన పెద్ద బృందం ఉంది. మరియు మేము సుమారు 10 సంవత్సరాల పాటు అభివృద్ధి చేసిన పెద్ద, పెద్ద ఎంటర్‌ప్రైజ్ ప్రాజెక్ట్‌ని కలిగి ఉన్నాము. మరియు మాకు వేర్వేరు శాఖలు ఉన్నాయి. రిపోజిటరీలో మేము డెవలపర్లు నడిచే శాఖను కలిగి ఉన్నాము. మరియు ఉత్పత్తిలో ఉన్న కోడ్ సంస్కరణను ప్రదర్శించే ఒక శాఖ ఉంది.
డెవలపర్‌లకు అందుబాటులో ఉన్న బ్రాంచ్ కంటే ఉత్పత్తి శాఖ 3 నెలలు వెనుకబడి ఉంది. దీని అర్థం ఏమిటి? దీనర్థం, డెవలపర్‌ల తప్పు కారణంగా ఉత్పత్తికి వెళ్ళే బగ్ ఎక్కడో ఉన్న వెంటనే, వారు దానిని అనుమతించినందున మరియు QA యొక్క తప్పు కారణంగా, వారు దానిని చూసారు కాబట్టి, దీని అర్థం నేను ఒక ఉత్పత్తి కోసం hotfix కోసం పని, అప్పుడు నేను 3 నెలల క్రితం నా కోడ్ మార్పులను వెనక్కి తీసుకోవాలి. నేను 3 నెలల క్రితం కలిగి ఉన్నదాన్ని గుర్తుంచుకోవాలి మరియు అక్కడ దాన్ని సరిచేయడానికి ప్రయత్నించాలి.
మీకు ఇంకా ఈ అనుభవం లేకపోతే, మీరు దీన్ని మీ హోమ్ ప్రాజెక్ట్‌లో ప్రయత్నించవచ్చు. ప్రధాన విషయం ఏమిటంటే, దానిని వాణిజ్యపరంగా ప్రయత్నించవద్దు. కోడ్ యొక్క రెండు పంక్తులను వ్రాసి, వాటిని ఆరు నెలల పాటు మరచిపోయి, ఆపై తిరిగి వచ్చి, ఆ కోడ్ లైన్లు దేనికి సంబంధించినవి మరియు మీరు వాటిని ఎలా పరిష్కరించవచ్చు లేదా ఆప్టిమైజ్ చేయవచ్చు అని త్వరగా వివరించడానికి ప్రయత్నించండి. ఇది చాలా చాలా ఉత్తేజకరమైన అనుభవం.
మనకు నిరంతర ఇంటిగ్రేషన్ ప్రాక్టీస్ ఉంటే, నేను నా కోడ్‌ని వ్రాసిన వెంటనే ఇక్కడే మరియు ఇప్పుడే అనేక ఆటోమేటెడ్ టూల్స్‌తో దాన్ని తనిఖీ చేయడానికి ఇది అనుమతిస్తుంది. ఇది నాకు పూర్తి చిత్రాన్ని అందించకపోవచ్చు, అయినప్పటికీ, ఇది కనీసం కొన్ని నష్టాలను తొలగిస్తుంది. మరియు ఏదైనా సంభావ్య బగ్ ఉంటే, నేను దాని గురించి ఇప్పుడే తెలుసుకుంటాను, అంటే అక్షరాలా రెండు నిమిషాల్లో. నేను 3 నెలలు వెనక్కి వెళ్లాల్సిన అవసరం లేదు. నేను కేవలం 2 నిమిషాలు వెనక్కి వెళ్లాలి. ఒక మంచి కాఫీ మెషీన్‌కి 2 నిమిషాల్లో కాఫీ కాయడానికి కూడా సమయం ఉండదు, కనుక ఇది చాలా బాగుంది.
ఇది ప్రతి ప్రాజెక్ట్‌లో ఎప్పటికప్పుడు పునరావృతమయ్యే విలువను కలిగి ఉంటుంది, అనగా. మీరు సెటప్ చేసిన దానికే కాదు. మీరు ప్రాక్టీస్ రెండింటినీ పునరావృతం చేయవచ్చు మరియు ప్రాజెక్ట్‌లో మీరు చేసే ప్రతి కొత్త మార్పు కోసం CI కూడా పునరావృతమవుతుంది. మీ బృందం మరింత సమర్ధవంతంగా పని చేస్తుంది కాబట్టి ఇది వనరులను ఆప్టిమైజ్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. మీరు 3 నెలల క్రితం పనిచేసిన కోడ్ నుండి బగ్ మీకు వచ్చే పరిస్థితి ఇకపై ఉండదు. మీరు ఏదైనా సరిదిద్దడం ప్రారంభించే ముందు, అప్పుడు ఏమి జరిగిందో అర్థం చేసుకోవడానికి మరియు సందర్భం యొక్క సారాంశాన్ని పొందడానికి మీరు మొదటి రెండు గంటలు కూర్చుని గడిపినప్పుడు మీకు ఇకపై సందర్భ మార్పిడి ఉండదు.
ఈ అభ్యాసం యొక్క విజయం లేదా వైఫల్యాన్ని మనం ఎలా కొలవగలం? CI ప్రాజెక్ట్‌లో మేము అమలు చేసిన వాటిని మీరు బిగ్ బాస్‌కి నివేదిస్తే, అతను బ్లా బ్లా బ్లా అని విన్నాడు. మేము దానిని అమలు చేసాము, సరే, కానీ ఎందుకు, అది మనకు ఏమి తెచ్చిపెట్టింది, మనం దానిని ఎలా కొలుస్తాము, ఎంత సరిగ్గా లేదా తప్పుగా అమలు చేస్తున్నాము?
మొదటిది, CIకి కృతజ్ఞతలు, మన కోడ్ మరింత స్థిరంగా ఉన్నందున మేము మరింత తరచుగా మరియు మరింత తరచుగా అమలు చేయవచ్చు. అదే విధంగా, ఒక లోపాన్ని కనుగొనే సమయం తగ్గుతుంది మరియు ఈ లోపాన్ని సరిదిద్దే సమయం ఖచ్చితంగా తగ్గుతుంది, ఎందుకంటే మేము సిస్టమ్ నుండి ఇక్కడే మరియు ఇప్పుడే సమాధానాన్ని అందుకుంటాము, మా కోడ్‌లో ఏమి తప్పు ఉంది.
మేము కలిగి ఉన్న మరొక అభ్యాసం ఆటోమేషన్ టెస్టింగ్ ప్రాక్టీస్, ఇది చాలా తరచుగా CI అభ్యాసంతో వస్తుంది. అవి చేతికి అందుతాయి.
ఇక్కడ అర్థం చేసుకోవడం ముఖ్యం? మా పరీక్షలు భిన్నంగా ఉన్నాయని అర్థం చేసుకోవడం ముఖ్యం. మరియు ప్రతి ఆటోమేటెడ్ పరీక్ష దాని స్వంత సమస్యలను పరిష్కరించే లక్ష్యంతో ఉంటుంది. ఉదాహరణకు, మాడ్యూల్‌ను విడిగా పరీక్షించడానికి మాకు అనుమతించే యూనిట్ పరీక్షలు ఉన్నాయి, అనగా. వాక్యూమ్‌లో ఇది ఎలా పని చేస్తుంది? ఇది బాగుంది.
విభిన్న మాడ్యూల్స్ ఒకదానితో ఒకటి ఎలా కలిసిపోతాయో అర్థం చేసుకోవడానికి మాకు ఇంటిగ్రేషన్ పరీక్షలు కూడా ఉన్నాయి. ఇది కూడా మంచిది.
మేము UI ఆటోమేషన్ పరీక్షలను కలిగి ఉండవచ్చు, ఇది UIతో పని ఎంతవరకు కస్టమర్ సెట్ చేసిన కొన్ని అవసరాలకు అనుగుణంగా ఉందో తనిఖీ చేయడానికి అనుమతిస్తుంది.
మీరు అమలు చేసే నిర్దిష్ట పరీక్షలు మీరు వాటిని ఎంత తరచుగా అమలు చేస్తారో ప్రభావితం చేయవచ్చు. యూనిట్ పరీక్షలు సాధారణంగా చిన్నవి మరియు చిన్నవిగా వ్రాయబడతాయి. మరియు వాటిని క్రమం తప్పకుండా ప్రారంభించవచ్చు.
మేము UI ఆటోమేషన్ పరీక్షల గురించి మాట్లాడుతున్నట్లయితే, మీ ప్రాజెక్ట్ చిన్నదిగా ఉంటే మంచిది. మీ UI ఆటోమేషన్ పరీక్షలకు తగిన సమయం పట్టవచ్చు. కానీ సాధారణంగా UI ఆటోమేషన్ పరీక్ష అనేది పెద్ద ప్రాజెక్ట్‌లో చాలా గంటలు పడుతుంది. మరియు ఇది కొన్ని గంటలు ఉంటే మంచిది. ప్రతి నిర్మాణానికి వాటిని అమలు చేయడంలో ఎటువంటి ప్రయోజనం లేదు. రాత్రిపూట వాటిని అమలు చేయడం అర్ధమే. మరియు ప్రతి ఒక్కరూ ఉదయం పనికి వచ్చినప్పుడు: టెస్టర్‌లు మరియు డెవలపర్లు ఇద్దరూ, మేము రాత్రిపూట UI ఆటోటెస్ట్‌ని అమలు చేసాము మరియు ఈ ఫలితాలను పొందామని వారికి ఒక రకమైన నివేదిక వచ్చింది. మరియు ఇక్కడ, మీ ఉత్పత్తి కొన్ని అవసరాలకు అనుగుణంగా ఉందని తనిఖీ చేసే సర్వర్ యొక్క ఒక గంట పని అదే QA ఇంజనీర్ యొక్క ఒక గంట పని కంటే చాలా చౌకగా ఉంటుంది, అతను ఆహారం మరియు ధన్యవాదాలు కోసం పనిచేసే జూనియర్ QA ఇంజనీర్ అయినప్పటికీ. అదే, ఒక గంట యంత్రం ఆపరేషన్ చౌకగా ఉంటుంది. అందుకే ఇందులో పెట్టుబడి పెట్టడం సమంజసం.
నేను పని చేస్తున్న మరో ప్రాజెక్ట్ ఉంది. మేము ఈ ప్రాజెక్ట్‌లో రెండు వారాల స్ప్రింట్‌లను కలిగి ఉన్నాము. ప్రాజెక్ట్ పెద్దది, ఆర్థిక రంగానికి ముఖ్యమైనది మరియు పొరపాటు జరగలేదు. మరియు రెండు వారాల స్ప్రింట్ తర్వాత, డెవలప్‌మెంట్ సైకిల్‌ను టెస్టింగ్ ప్రక్రియ అనుసరించింది, దీనికి మరో 4 వారాలు పట్టింది. విషాదం యొక్క స్థాయిని ఊహించడానికి ప్రయత్నించండి. మేము రెండు వారాల పాటు కోడ్‌ని వ్రాస్తాము, ఆపై మేము దానిని అలా కోడ్‌ఫ్రీజ్ చేస్తాము, అప్లికేషన్ యొక్క కొత్త వెర్షన్‌కి ప్యాక్ చేస్తాము మరియు దానిని టెస్టర్‌లకు అందిస్తాము. పరీక్షకులు దీనిని మరో 4 వారాలు పరీక్షిస్తారు, అనగా. వారు దీన్ని పరీక్షిస్తున్నప్పుడు, వారి కోసం మరో రెండు వెర్షన్‌లను సిద్ధం చేయడానికి మాకు సమయం ఉంది. ఇది నిజంగా విచారకరమైన కేసు.
మరియు మీరు మరింత ఉత్పాదకంగా ఉండాలనుకుంటే, మీరు ఆటోమేటెడ్ టెస్టింగ్ పద్ధతులను అమలు చేయడం సమంజసమని మేము వారికి చెప్పాము, ఎందుకంటే ఇది ప్రస్తుతం ఇక్కడే మిమ్మల్ని బాధపెడుతోంది.
నిరంతర విస్తరణను ప్రాక్టీస్ చేయండి. బాగుంది, మీరు నిర్మించారు. ఇది ఇప్పటికే మంచిది. మీ కోడ్ కంపైల్ చేయబడింది. ఇప్పుడు ఈ బిల్డ్‌ని కొంత వాతావరణంలో అమర్చడం మంచిది. డెవలపర్‌ల కోసం వాతావరణంలో చెప్పండి.
ఇది ఎందుకు ముఖ్యమైనది? ముందుగా, మీరు విస్తరణ ప్రక్రియతో ఎంత విజయవంతమయ్యారో మీరు చూడవచ్చు. నేను ఇలాంటి ప్రాజెక్ట్‌లను కలుసుకున్నాను, నేను అడిగినప్పుడు: “మీరు అప్లికేషన్ యొక్క కొత్త వెర్షన్‌ను ఎలా అమలు చేస్తారు?”, అబ్బాయిలు నాతో ఇలా అంటారు: “మేము దానిని సమీకరించి జిప్ ఆర్కైవ్‌లో ప్యాక్ చేస్తాము. మేము దానిని మెయిల్ ద్వారా నిర్వాహకులకు పంపుతాము. అడ్మిన్ ఈ ఆర్కైవ్‌ను డౌన్‌లోడ్ చేసి, విస్తరిస్తారు. మరియు సర్వర్ కొత్త వెర్షన్‌ను తీయాలని కార్యాలయం మొత్తం ప్రార్థించడం ప్రారంభించింది.
సరళమైన వాటితో ప్రారంభిద్దాం. ఉదాహరణకు, వారు ఆర్కైవ్‌లో CSSని ఉంచడం మర్చిపోయారు లేదా జావా-స్క్రిప్ట్ ఫైల్ పేరులో హ్యాష్‌ట్యాగ్‌ని మార్చడం మర్చిపోయారు. మరియు మేము సర్వర్‌కి అభ్యర్థన చేసినప్పుడు, బ్రౌజర్ ఇప్పటికే ఈ జావా-స్క్రిప్ట్ ఫైల్‌ని కలిగి ఉందని భావించి, దానిని డౌన్‌లోడ్ చేయకూడదని నిర్ణయించుకుంటుంది. మరియు పాత వెర్షన్ ఉంది, ఏదో లేదు. సాధారణంగా, చాలా సమస్యలు ఉండవచ్చు. అందువల్ల, నిరంతర విస్తరణ యొక్క అభ్యాసం మీరు క్లీన్ రిఫరెన్స్ ఇమేజ్‌ని తీసి పూర్తిగా శుభ్రమైన కొత్త వాతావరణంలో అప్‌లోడ్ చేస్తే ఏమి జరుగుతుందో కనీసం పరీక్షించడానికి మిమ్మల్ని అనుమతిస్తుంది. ఇది ఎక్కడికి దారితీస్తుందో మీరు చూడవచ్చు.
అలాగే, మీరు ఒకదానికొకటి కోడ్‌ను ఏకీకృతం చేసినప్పుడు, అనగా. ఆదేశం మధ్య, ఇది UIలో ఎలా కనిపిస్తుందో చూడటానికి కూడా మిమ్మల్ని అనుమతిస్తుంది.
వనిల్లా జావా-స్క్రిప్ట్‌ను ఎక్కువగా ఉపయోగించినప్పుడు సంభవించే సమస్యల్లో ఒకటి, ఇద్దరు డెవలపర్లు విండో ఆబ్జెక్ట్‌లో ఒకే పేరుతో వేరియబుల్‌ను అనాలోచితంగా ప్రకటించారు. ఆపై, మీ అదృష్టాన్ని బట్టి. ఎవరి జావా-స్క్రిప్ట్ ఫైల్‌ను రెండవసారి బయటకు తీసినా మరొకరి మార్పులను ఓవర్‌రైట్ చేస్తుంది. ఇది చాలా ఉత్తేజకరమైనది కూడా. మీరు లోపలికి రండి: ఒకటి ఒక వ్యక్తికి పని చేస్తుంది, మరొకటి మరొకరికి పని చేయదు. మరియు ఇది అన్ని ఉత్పత్తిలో వచ్చినప్పుడు "అద్భుతం".
మేము కలిగి ఉన్న తదుపరి అభ్యాసం స్వయంచాలక పునరుద్ధరణ యొక్క అభ్యాసం, అంటే అప్లికేషన్ యొక్క మునుపటి సంస్కరణకు తిరిగి వెళ్లడం.
డెవలపర్‌లకు ఇది ఎందుకు ముఖ్యమైనది? కంప్యూటర్లు పెద్దవిగా మరియు ప్రోగ్రామ్‌లు చిన్నవిగా ఉన్న సుదూర, సుదూర 90 లను గుర్తుంచుకునే వారు ఇప్పటికీ ఉన్నారు. మరియు వెబ్ అభివృద్ధికి ఏకైక మార్గం PHP ద్వారా. PHP చెడ్డ భాష అని కాదు, అయినప్పటికీ.
కానీ సమస్య వేరేలా ఉండేది. మేము మా php సైట్ యొక్క క్రొత్త సంస్కరణను అమలు చేసినప్పుడు, మేము దానిని ఎలా అమలు చేసాము? చాలా తరచుగా మేము ఫార్ మేనేజర్ లేదా మరేదైనా తెరిచాము. మరియు ఈ ఫైల్‌లను FTPకి అప్‌లోడ్ చేసింది. మరియు మేము అకస్మాత్తుగా మనకు కొన్ని చిన్న, చిన్న బగ్ ఉందని గ్రహించాము, ఉదాహరణకు, మేము సెమికోలన్‌ను ఉంచడం మర్చిపోయాము లేదా డేటాబేస్ కోసం పాస్‌వర్డ్‌ను మార్చడం మర్చిపోయాము మరియు డేటాబేస్ కోసం పాస్‌వర్డ్ ఉంది, ఇది స్థానిక హోస్ట్‌లో ఉంది. మరియు మేము త్వరగా FTPకి కనెక్ట్ చేయాలని మరియు ఫైల్‌లను అక్కడే సవరించాలని నిర్ణయించుకున్నాము. ఇది కేవలం అగ్ని! ఇది 90వ దశకంలో ప్రజాదరణ పొందింది.
కానీ, మీరు క్యాలెండర్‌ను చూడకపోతే, 90 లు దాదాపు 30 సంవత్సరాల క్రితం. ఇప్పుడు ప్రతిదీ కొద్దిగా భిన్నంగా జరుగుతోంది. మరియు వారు మీకు చెప్పినప్పుడు విషాదం యొక్క స్థాయిని ఊహించడానికి ప్రయత్నించండి: "మేము ఉత్పత్తికి మోహరించాము, కానీ అక్కడ ఏదో తప్పు జరిగింది. ఇక్కడ మీ FTP లాగిన్ మరియు పాస్‌వర్డ్ ఉంది, ప్రొడక్షన్‌కి కనెక్ట్ చేయండి మరియు దాన్ని త్వరగా పరిష్కరించండి." మీరు చక్ నోరిస్ అయితే, ఇది పని చేస్తుంది. లేకపోతే, మీరు ఒక బగ్‌ని సరిచేస్తే, మీరు మరో 10 మందిని తయారు చేసే ప్రమాదం ఉంది. అందుకే మునుపటి సంస్కరణకు వెళ్లే ఈ అభ్యాసం మీరు చాలా సాధించడానికి అనుమతిస్తుంది.
ఏదో ఒకచోట ఏదో ఒకవిధంగా ఏదో ఒకవిధంగా ప్రోద్బలంలోకి వచ్చినప్పటికీ, అది చెడ్డది, కానీ ప్రాణాంతకం కాదు. మీరు కలిగి ఉన్న మునుపటి సంస్కరణకు తిరిగి వెళ్లవచ్చు. ఆ పరిభాషలో గ్రహించడం సులభమైతే దాన్ని బ్యాకప్ అని పిలవండి. మీరు ఈ మునుపటి సంస్కరణకు తిరిగి వెళ్లవచ్చు మరియు వినియోగదారులు ఇప్పటికీ మీ ఉత్పత్తితో పని చేయగలుగుతారు మరియు మీకు తగిన బఫర్ సమయం ఉంటుంది. మీరు ప్రశాంతంగా, తొందరపడకుండా, వీటన్నింటిని తీసుకొని స్థానికంగా పరీక్షించి, సరిచేసి, ఆపై కొత్త సంస్కరణను అప్‌లోడ్ చేయవచ్చు. దీన్ని చేయడం నిజంగా అర్ధమే.
ఇప్పుడు మునుపటి రెండు అభ్యాసాలను ఎలాగైనా కలపడానికి ప్రయత్నిద్దాం. మేము విడుదల నిర్వహణ అనే మూడవదాన్ని పొందుతాము.
మేము దాని శాస్త్రీయ రూపంలో నిరంతర విస్తరణ గురించి మాట్లాడేటప్పుడు, రిపోజిటరీ నుండి ఏదో ఒక బ్రాంచ్ నుండి కోడ్‌ని లాగి, దానిని కంపైల్ చేసి దానిని అమలు చేయాలి. మనకూ అదే వాతావరణం ఉంటే బాగుంటుంది. మనకు అనేక వాతావరణాలు ఉంటే, అదే కమిట్ నుండి కూడా ప్రతిసారీ కోడ్‌ని లాగవలసి ఉంటుందని దీని అర్థం. మేము దానిని ప్రతిసారీ తీసివేస్తాము, మేము ప్రతిసారీ దానిని నిర్మిస్తాము మరియు మేము దానిని కొత్త వాతావరణానికి అమలు చేస్తాము. ముందుగా, ఇది సమయం, ఎందుకంటే ప్రాజెక్ట్‌ను నిర్మించడానికి, మీకు పెద్దది ఉంటే మరియు 90ల నుండి వచ్చినట్లయితే, దీనికి చాలా గంటలు పట్టవచ్చు.
దానికి తోడు ఇంకో బాధ కూడా ఉంది. మీరు నిర్మించినప్పుడు, అదే మెషీన్‌లో కూడా, మీరు అదే మూలాలను నిర్మిస్తారు, ఈ యంత్రం చివరి బిల్డ్ సమయంలో ఉన్న స్థితిలోనే ఉందని మీకు ఇప్పటికీ హామీ లేదు.
ఎవరైనా వచ్చి మీ కోసం డాట్‌నెట్‌ని అప్‌డేట్ చేశారనుకుందాం లేదా దానికి విరుద్ధంగా ఎవరైనా ఏదైనా తొలగించాలని నిర్ణయించుకున్నారు. ఆపై మీకు అభిజ్ఞా వైరుధ్యం ఉంది, ఈ కమిట్ నుండి రెండు వారాల క్రితం మేము ఒక బిల్డ్‌ను నిర్మిస్తున్నాము మరియు అంతా బాగానే ఉంది, కానీ ఇప్పుడు అదే యంత్రం, అదే కమిట్, అదే కోడ్ లాగా ఉంది మేము నిర్మించడానికి ప్రయత్నిస్తున్నాము, కానీ అది పని చేయడం లేదు . మీరు దీనితో చాలా కాలం పాటు వ్యవహరిస్తారు మరియు మీరు దీన్ని గుర్తించడం వాస్తవం కాదు. కనీసం, మీరు మీ నరాలను చాలా పాడు చేస్తారు.
అందువల్ల, ఆర్టిఫ్యాక్ట్ రిపోజిటరీ లేదా గ్యాలరీ లేదా లైబ్రరీ అని పిలువబడే అదనపు సంగ్రహణను పరిచయం చేయమని విడుదల నిర్వహణ అభ్యాసం సూచిస్తుంది. మీకు ఏది కావాలంటే అది కాల్ చేయవచ్చు.
ప్రధాన ఆలోచన ఏమిటంటే, మేము మా విభిన్న వాతావరణాలకు విస్తరించడానికి సిద్ధంగా ఉన్న ఒక శాఖలో ఒక రకమైన కమిట్ అయిన వెంటనే, మేము ఈ కమిట్ నుండి అప్లికేషన్లను సేకరిస్తాము మరియు ఈ అప్లికేషన్ కోసం మనకు అవసరమైన ప్రతిదాన్ని మేము ప్యాక్ చేస్తాము. జిప్ ఆర్కైవ్‌లో మరియు కొంత విశ్వసనీయ నిల్వలో సేవ్ చేయండి. మరియు ఈ నిల్వ నుండి మనం ఎప్పుడైనా ఈ జిప్ ఆర్కైవ్‌ని పొందవచ్చు.
అప్పుడు మేము దానిని తీసుకొని స్వయంచాలకంగా దేవ్ ఎన్విరాన్‌మెంట్‌కు అమర్చాము. మేము అక్కడ పోటీ చేస్తాము మరియు ప్రతిదీ బాగుంటే, మేము వేదికపైకి వస్తాము. అన్నీ సరిగ్గా ఉంటే, మేము అదే ఆర్కైవ్‌ను ఉత్పత్తికి, అదే బైనరీలను సరిగ్గా ఒకసారి కంపైల్ చేస్తాము.
అదనంగా, మనకు ఇలాంటి గ్యాలరీ ఉన్నప్పుడు, మేము మునుపటి సంస్కరణకు రోల్‌బ్యాక్ గురించి మాట్లాడినప్పుడు చివరి స్లయిడ్‌లో మేము ప్రస్తావించిన నష్టాలను పరిష్కరించడంలో కూడా ఇది మాకు సహాయపడుతుంది. మీరు పొరపాటున ఏదైనా తప్పుని అమలు చేసినట్లయితే, మీరు ఎప్పుడైనా ఈ గ్యాలరీ నుండి ఏదైనా ఇతర మునుపటి సంస్కరణను తీసుకోవచ్చు మరియు అదే విధంగా ఈ పరిసరాలకు అన్‌ప్లాయ్ చేయవచ్చు. ఏదైనా తప్పు జరిగితే మునుపటి సంస్కరణకు సులభంగా తిరిగి వెళ్లడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది.
మరొక గొప్ప అభ్యాసం ఉంది. మేము మా అప్లికేషన్లను మునుపటి సంస్కరణకు రోల్‌బ్యాక్ చేసినప్పుడు, మాకు మునుపటి సంస్కరణ యొక్క మౌలిక సదుపాయాలు కూడా అవసరమని మీరు మరియు నేను అర్థం చేసుకున్నాము.
మేము వర్చువల్ ఇన్‌ఫ్రాస్ట్రక్చర్ గురించి మాట్లాడేటప్పుడు, ఇది నిర్వాహకులు ఏర్పాటు చేసిన విషయం అని చాలా మంది అనుకుంటారు. మరియు మీరు మీ అప్లికేషన్ యొక్క కొత్త వెర్షన్‌ను పరీక్షించాలనుకుంటున్న కొత్త సర్వర్‌ని పొందడానికి మీకు అవసరమైతే, మీరు తప్పనిసరిగా అడ్మిన్‌లు లేదా డెవొప్‌లకు టిక్కెట్‌ను వ్రాయాలి. Devops దీని కోసం 3 వారాలు పడుతుంది. మరియు 3 వారాల తర్వాత మేము మీ కోసం ఒక కోర్, రెండు గిగాబైట్‌ల RAM మరియు డాట్‌నెట్ లేకుండా విండోస్ సర్వర్‌తో వర్చువల్ మెషీన్‌ను ఇన్‌స్టాల్ చేసామని వారు మీకు చెప్తారు. మీరు ఇలా అంటారు: "అయితే నాకు డాట్‌నెట్ కావాలి." వారు: "సరే, 3 వారాల్లో తిరిగి రండి."
ఆలోచన ఏమిటంటే, ఇన్‌ఫ్రాస్ట్రక్చర్‌ని కోడ్ ప్రాక్టీస్‌లుగా ఉపయోగించడం ద్వారా, మీరు మీ వర్చువల్ ఇన్‌ఫ్రాస్ట్రక్చర్‌ను మరొక వనరుగా పరిగణించవచ్చు.
బహుశా, మీలో ఎవరైనా డాట్‌నెట్‌లో అప్లికేషన్లను అభివృద్ధి చేస్తుంటే, మీరు ఎంటిటీ ఫ్రేమ్‌వర్క్ అనే లైబ్రరీ గురించి విని ఉండవచ్చు. మైక్రోసాఫ్ట్ చురుగ్గా ముందుకు తెస్తున్న విధానాలలో ఎంటిటీ ఫ్రేమ్‌వర్క్ ఒకటి అని మీరు కూడా విని ఉండవచ్చు. డేటాబేస్తో పని చేయడానికి, ఇది కోడ్ ఫస్ట్ అనే విధానం. మీరు మీ డేటాబేస్ ఎలా ఉండాలనుకుంటున్నారో కోడ్‌లో వివరించినప్పుడు ఇది జరుగుతుంది. ఆపై మీరు అప్లికేషన్‌ను అమలు చేస్తారు. ఇది డేటాబేస్కు కనెక్ట్ చేస్తుంది, ఏ పట్టికలు ఉన్నాయి మరియు ఏ పట్టికలు లేవని అది స్వయంగా నిర్ణయిస్తుంది మరియు మీకు అవసరమైన ప్రతిదాన్ని సృష్టిస్తుంది.
మీరు మీ మౌలిక సదుపాయాలతో కూడా అదే చేయవచ్చు. మీకు ప్రాజెక్ట్ కోసం డేటాబేస్ కావాలా లేదా ప్రాజెక్ట్ కోసం మీకు విండోస్ సర్వర్ కావాలా అనే దాని మధ్య తేడా లేదు. ఇది కేవలం ఒక వనరు. మరియు మీరు ఈ వనరు యొక్క సృష్టిని ఆటోమేట్ చేయవచ్చు, మీరు ఈ వనరు యొక్క కాన్ఫిగరేషన్‌ను ఆటోమేట్ చేయవచ్చు. దీని ప్రకారం, మీరు ఏదైనా కొత్త కాన్సెప్ట్‌ను, కొన్ని కొత్త విధానాన్ని పరీక్షించాలనుకున్న ప్రతిసారీ, మీరు డెవొప్స్‌కి టికెట్ రాయాల్సిన అవసరం లేదు, మీరు రెడీమేడ్ టెంప్లేట్‌ల నుండి, రెడీమేడ్ స్క్రిప్ట్‌ల నుండి మీ కోసం ఒక వివిక్త మౌలిక సదుపాయాలను అమర్చవచ్చు మరియు దానిని అమలు చేయవచ్చు. మీ ప్రయోగాలన్నీ ఉన్నాయి. మీరు దీన్ని తొలగించవచ్చు, కొన్ని ఫలితాలను పొందవచ్చు మరియు దాని గురించి మరింత నివేదించవచ్చు.
తదుపరి అభ్యాసం, ఇది కూడా ఉనికిలో ఉంది మరియు ముఖ్యమైనది, కానీ కొంతమంది వ్యక్తులు ఉపయోగించేది, అప్లికేషన్ పనితీరు పర్యవేక్షణ.
అప్లికేషన్ పెర్ఫార్మెన్స్ మానిటరింగ్ గురించి నేను ఒక్క విషయం మాత్రమే చెప్పాలనుకుంటున్నాను. ఈ అభ్యాసం గురించి చాలా ముఖ్యమైనది ఏమిటి? అప్లికేషన్ పెర్ఫార్మెన్స్ మానిటరింగ్ అంటే అపార్ట్‌మెంట్ రిపేర్ చేయడం లాంటిదే. ఇది అంతిమ స్థితి కాదు, ఇది ఒక ప్రక్రియ. మీరు దీన్ని క్రమం తప్పకుండా చేయాలి.
మంచి మార్గంలో, దాదాపు ప్రతి బిల్డ్‌లో అప్లికేషన్ పనితీరు పర్యవేక్షణను నిర్వహించడం మంచిది, అయినప్పటికీ, మీరు అర్థం చేసుకున్నట్లుగా, ఇది ఎల్లప్పుడూ సాధ్యం కాదు. కానీ, కనీసం, ప్రతి విడుదలకు ఇది నిర్వహించాల్సిన అవసరం ఉంది.
ఇది ఎందుకు ముఖ్యమైనది? ఎందుకంటే మీరు అకస్మాత్తుగా పనితీరులో తగ్గుదలని అనుభవిస్తే, మీరు ఎందుకు స్పష్టంగా అర్థం చేసుకోవాలి. మీ బృందం రెండు వారాల స్ప్రింట్‌లను కలిగి ఉంటే, కనీసం ప్రతి రెండు వారాలకు ఒకసారి మీరు మీ అప్లికేషన్‌ను ఏదైనా ప్రత్యేక సర్వర్‌లో అమర్చాలి, అక్కడ మీకు స్పష్టంగా స్థిరమైన ప్రాసెసర్, RAM, డిస్క్‌లు మొదలైనవి ఉంటాయి మరియు అదే పనితీరు పరీక్షలను అమలు చేయండి. . మీరు ఫలితాన్ని పొందుతారు. మునుపటి స్ప్రింట్ నుండి ఇది ఎలా మారిందో చూడండి.
మరియు డ్రాడౌన్ ఎక్కడో బాగా తగ్గిపోయిందని మీరు కనుగొంటే, అది కేవలం గత రెండు వారాలలో జరిగిన మార్పుల వల్లనే అని అర్థం. ఇది చాలా వేగంగా సమస్యను గుర్తించడానికి మరియు పరిష్కరించడానికి మిమ్మల్ని అనుమతిస్తుంది. మరలా, ఇవి ఇంచుమించు అదే కొలమానాలు, దీని ద్వారా మీరు ఎంత విజయవంతంగా చేశారో కొలవవచ్చు.
మేము కలిగి ఉన్న తదుపరి అభ్యాసం కాన్ఫిగరేషన్ మేనేజ్‌మెంట్ అభ్యాసం. దీన్ని సీరియస్‌గా తీసుకునే వారు చాలా తక్కువ. కానీ నన్ను నమ్మండి, ఇది చాలా తీవ్రమైన విషయం.
ఇటీవల ఒక తమాషా కథ వచ్చింది. అబ్బాయిలు నా దగ్గరకు వచ్చి ఇలా అన్నారు: "మా అప్లికేషన్ యొక్క సెక్యూరిటీ ఆడిట్ నిర్వహించడంలో మాకు సహాయపడండి." మేము చాలా సేపు కలిసి కోడ్‌ని చూశాము, వారు అప్లికేషన్ గురించి నాకు చెప్పారు, రేఖాచిత్రాలను గీసారు. మరియు ప్లస్ లేదా మైనస్ ప్రతిదీ తార్కికంగా, అర్థమయ్యేలా, సురక్షితంగా ఉంది, కానీ ఒకటి ఉంది కానీ! వారు తమ సోర్స్ కంట్రోల్‌లో కాన్ఫిగరేషన్ ఫైల్‌లను కలిగి ఉన్నారు, వీటిలో IP డేటాబేస్తో ఉత్పత్తి నుండి, ఈ డేటాబేస్‌లకు కనెక్ట్ చేయడానికి లాగిన్‌లు మరియు పాస్‌వర్డ్‌లు మొదలైనవి ఉన్నాయి.
మరియు నేను ఇలా చెప్తున్నాను: “అబ్బాయిలు, సరే, మీరు మీ ఉత్పత్తి వాతావరణాన్ని ఫైర్‌వాల్‌తో మూసివేశారు, కానీ మీరు ఉత్పత్తి డేటాబేస్ కోసం లాగిన్ మరియు పాస్‌వర్డ్‌ని సోర్స్ కంట్రోల్‌లోనే కలిగి ఉండటం మరియు ఏదైనా డెవలపర్ చదవగలగడం అనేది ఇప్పటికే భారీ భద్రతా ప్రమాదం. . మరియు మీ అప్లికేషన్ కోడ్ పాయింట్ ఆఫ్ వ్యూ నుండి ఎంత సురక్షితమైనదైనా సరే, మీరు దానిని సోర్స్ కంట్రోల్‌లో వదిలేస్తే, మీరు ఎక్కడా ఎటువంటి ఆడిట్‌ను పాస్ చేయలేరు. అదే నేను మాట్లాడుతోంది.
ఆకృతీకరణ నిర్వహణ. మేము వేర్వేరు వాతావరణాలలో వేర్వేరు కాన్ఫిగరేషన్‌లను కలిగి ఉండవచ్చు. ఉదాహరణకు, QA, డెమో, ఉత్పత్తి వాతావరణం మొదలైన వాటి కోసం డేటాబేస్‌ల కోసం మేము వేర్వేరు లాగిన్‌లు మరియు పాస్‌వర్డ్‌లను కలిగి ఉండవచ్చు.
ఈ కాన్ఫిగరేషన్ స్వయంచాలకంగా కూడా చేయవచ్చు. ఇది ఎల్లప్పుడూ అప్లికేషన్ నుండి వేరుగా ఉండాలి. ఎందుకు? మీరు ఒకసారి అప్లికేషన్‌ను రూపొందించినందున, ఆపై మీరు SQL సర్వర్‌కి అటువంటి IP లేదా అటువంటి IP ద్వారా కనెక్ట్ చేసినా అప్లికేషన్ పట్టించుకోదు, అది అదే పని చేయాలి. అందువల్ల, అకస్మాత్తుగా మీలో ఒకరు ఇప్పటికీ కోడ్‌లోని కనెక్షన్ స్ట్రింగ్‌ను హార్డ్‌కోడ్ చేస్తుంటే, మీరు నాతో అదే ప్రాజెక్ట్‌లో ఉన్నట్లు కనుగొంటే నేను మిమ్మల్ని కనుగొని శిక్షిస్తానని గుర్తుంచుకోండి. ఇది ఎల్లప్పుడూ ప్రత్యేక కాన్ఫిగరేషన్‌లో ఉంచబడుతుంది, ఉదాహరణకు, web.configలో.
మరియు ఈ కాన్ఫిగరేషన్ ఇప్పటికే విడిగా నిర్వహించబడుతోంది, అనగా డెవలపర్ మరియు నిర్వాహకుడు ఒకే గదిలోకి వచ్చి కూర్చునే సమయం ఇది. మరియు డెవలపర్ ఇలా చెప్పవచ్చు: “చూడండి, నా అప్లికేషన్ యొక్క బైనరీలు ఇక్కడ ఉన్నాయి. వారు పని చేస్తారు. అప్లికేషన్ పని చేయడానికి డేటాబేస్ అవసరం. ఇక్కడ బైనరీల పక్కన ఒక ఫైల్ ఉంది. ఈ ఫైల్‌లో, ఈ ఫీల్డ్ లాగిన్‌కి బాధ్యత వహిస్తుంది, ఇది పాస్‌వర్డ్ కోసం, ఇది IP కోసం. ఎక్కడైనా అమర్చు." మరియు నిర్వాహకులకు ఇది సరళమైనది మరియు స్పష్టంగా ఉంటుంది. అతను ఈ కాన్ఫిగరేషన్‌ని నిర్వహించడం ద్వారా నిజంగా ఎక్కడైనా దానిని అమలు చేయవచ్చు.
మరియు నేను మాట్లాడదలిచిన చివరి అభ్యాసం మేఘాలకు చాలా చాలా సంబంధించినది. మరియు మీరు క్లౌడ్‌లో పని చేస్తే గరిష్ట ప్రభావాన్ని తెస్తుంది. ఇది మీ పర్యావరణం యొక్క స్వయంచాలక తొలగింపు.
ఈ కాన్ఫరెన్స్‌లో నేను పనిచేసే టీమ్‌ల నుండి చాలా మంది వ్యక్తులు ఉన్నారని నాకు తెలుసు. మరియు నేను పని చేసే అన్ని బృందాలతో, మేము ఈ అభ్యాసాన్ని ఉపయోగిస్తాము.
ఎందుకు? వాస్తవానికి, ప్రతి డెవలపర్‌కు 24/7 పని చేసే వర్చువల్ మెషీన్ ఉంటే చాలా బాగుంటుంది. కానీ బహుశా ఇది మీకు వార్త కావచ్చు, బహుశా మీరు శ్రద్ధ చూపలేదు, కానీ డెవలపర్ స్వయంగా 24/7 పని చేయడు. డెవలపర్ సాధారణంగా రోజుకు 8 గంటలు పని చేస్తాడు. అతను త్వరగా పనికి వచ్చినప్పటికీ, అతను జిమ్‌కి వెళ్ళే సమయంలో పెద్ద భోజనం చేస్తాడు. డెవలపర్ వాస్తవానికి ఈ వనరులను ఉపయోగించినప్పుడు రోజుకు 12 గంటలు ఉండనివ్వండి. మా చట్టం ప్రకారం, మాకు వారంలో 5 రోజులలో 7 పని దినాలుగా పరిగణించబడతాయి.
దీని ప్రకారం, వారపు రోజులలో ఈ యంత్రం 24 గంటలు పని చేయకూడదు, కానీ 12 మాత్రమే, మరియు వారాంతాల్లో ఈ యంత్రం అస్సలు పని చేయకూడదు. ప్రతిదీ చాలా సులభం అని అనిపించవచ్చు, కానీ ఇక్కడ చెప్పడం ముఖ్యం? ఈ ప్రాథమిక షెడ్యూల్‌లో ఈ సాధారణ అభ్యాసాన్ని అమలు చేయడం ద్వారా, ఈ పరిసరాల నిర్వహణ ఖర్చును 70% తగ్గించడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది, అంటే మీరు మీ dev, QA, డెమో, పర్యావరణం యొక్క ధరను తీసుకొని దానిని 3తో విభజించారు.
మిగిలిన డబ్బుతో ఏం చేయాలనేది ప్రశ్న. ఉదాహరణకు, డెవలపర్లు ఇప్పటికే రీషార్పర్‌ని కొనుగోలు చేయకపోతే కొనుగోలు చేయాలి. లేదా కాక్‌టెయిల్ పార్టీ చేసుకోండి. మీరు ఇంతకుముందు దేవ్ మరియు QA రెండూ మేత ఉండే ఒక వాతావరణాన్ని కలిగి ఉంటే మరియు అంతే, ఇప్పుడు మీరు 3 విభిన్నమైన వాటిని తయారు చేయవచ్చు, అవి వేరుచేయబడతాయి మరియు వ్యక్తులు పరస్పరం జోక్యం చేసుకోరు.
నిరంతర పనితీరు కొలతతో స్లయిడ్‌కు సంబంధించి, ప్రాజెక్ట్‌లోని డేటాబేస్‌లో 1 రికార్డులు ఉంటే, రెండు నెలల తర్వాత మిలియన్‌లు ఉంటే పనితీరును ఎలా పోల్చవచ్చు? ఎందుకు మరియు పనితీరును కొలిచే పాయింట్ ఏమిటో అర్థం చేసుకోవడం ఎలా?
ఇది మంచి ప్రశ్న, ఎందుకంటే మీరు ఎల్లప్పుడూ అదే వనరులపై పనితీరును కొలవాలి. అంటే, మీరు కొత్త కోడ్‌ను విడుదల చేస్తారు, మీరు కొత్త కోడ్‌లో పనితీరును కొలుస్తారు. ఉదాహరణకు, మీరు విభిన్న పనితీరు దృశ్యాలను పరీక్షించాలి, 1 మంది వినియోగదారులు మరియు డేటాబేస్ పరిమాణం 000 గిగాబైట్‌లు ఉన్న లైట్ లోడ్‌లో అప్లికేషన్ ఎలా పనిచేస్తుందో మీరు పరీక్షించాలనుకుంటున్నారని అనుకుందాం. మీరు దానిని కొలిచారు మరియు సంఖ్యలను పొందారు. తదుపరి మేము మరొక దృశ్యాన్ని తీసుకుంటాము. ఉదాహరణకు, 5 మంది వినియోగదారులు, డేటాబేస్ పరిమాణం 5 టెరాబైట్. మేము ఫలితాలను అందుకున్నాము మరియు వాటిని గుర్తుచేసుకున్నాము.
ఇక్కడ ముఖ్యమైనది ఏమిటి? ఇక్కడ ముఖ్యమైన విషయం ఏమిటంటే, దృష్టాంతం, డేటా పరిమాణం, ఏకకాల వినియోగదారుల సంఖ్య మొదలైన వాటిపై ఆధారపడి, మీరు నిర్దిష్ట పరిమితులను అమలు చేయవచ్చు. ఉదాహరణకు, నెట్‌వర్క్ కార్డ్ పరిమితికి, లేదా హార్డ్ డ్రైవ్ యొక్క పరిమితికి లేదా ప్రాసెసర్ సామర్థ్యాల పరిమితికి. ఇది మీరు అర్థం చేసుకోవడం ముఖ్యం. విభిన్న దృశ్యాలలో మీరు నిర్దిష్ట పరిమితుల్లోకి ప్రవేశిస్తారు. మరియు మీరు వాటిని కొట్టినప్పుడు మీరు సంఖ్యలను అర్థం చేసుకోవాలి.
మేము ప్రత్యేక పరీక్ష వాతావరణంలో పనితీరును కొలవడం గురించి మాట్లాడుతున్నామా? అంటే, ఇది ఉత్పత్తి కాదా?
అవును, ఇది ఉత్పత్తి కాదు, ఇది పరీక్ష వాతావరణం, ఇది ఎల్లప్పుడూ ఒకే విధంగా ఉంటుంది కాబట్టి మీరు మునుపటి కొలతలతో పోల్చవచ్చు.
అర్థమైంది ధన్యవాదాలు!
ప్రశ్నలు లేకుంటే, మనం ముగించగలమని నేను భావిస్తున్నాను. ధన్యవాదాలు!
మూలం: www.habr.com