CI సాధనాలు మరియు CI పూర్తిగా భిన్నమైన విషయాలు ఎందుకు చర్చిద్దాం.
CI ఏ నొప్పిని పరిష్కరించడానికి ఉద్దేశించబడింది, ఆలోచన ఎక్కడ నుండి వచ్చింది, ఇది పని చేస్తుందని తాజా నిర్ధారణలు ఏమిటి, మీకు ప్రాక్టీస్ ఉందని మరియు కేవలం జెంకిన్స్‌ని ఇన్‌స్టాల్ చేయలేదని ఎలా అర్థం చేసుకోవాలి.
కంటిన్యూయస్ ఇంటిగ్రేషన్ గురించి నివేదిక తయారు చేయాలనే ఆలోచన ఒక సంవత్సరం క్రితం, నేను ఇంటర్వ్యూలకు వెళ్లి ఉద్యోగం కోసం వెతుకుతున్నప్పుడు కనిపించింది. నేను 10-15 కంపెనీలతో మాట్లాడాను, వాటిలో ఒకటి మాత్రమే CI అంటే ఏమిటో స్పష్టంగా సమాధానం ఇవ్వగలిగింది మరియు అది తమ వద్ద లేదని వారు ఎలా గ్రహించారో వివరించగలిగారు. మిగిలిన వారు జెంకిన్స్ గురించి అర్థం కాని అర్ధంలేని మాటలు మాట్లాడుతున్నారు :) సరే, మన దగ్గర జెంకిన్స్ ఉన్నారు, అది బిల్డ్ చేస్తుంది, CI! నివేదిక సమయంలో, నేను నిరంతర ఇంటిగ్రేషన్ అంటే ఏమిటి మరియు జెంకిన్స్ మరియు సారూప్య సాధనాలు దీనితో ఎందుకు చాలా బలహీనమైన సంబంధాన్ని కలిగి ఉన్నాయో వివరించడానికి ప్రయత్నిస్తాను.
కాబట్టి, CI అనే పదం వినగానే సాధారణంగా ఏది గుర్తుకు వస్తుంది? చాలా మంది ప్రజలు జెంకిన్స్, గిట్లాబ్ CI, ట్రావిస్ మొదలైనవారి గురించి ఆలోచిస్తారు.
మనం దాన్ని గూగుల్ చేసినా, అది మనకు ఈ సాధనాలను ఇస్తుంది.
మీకు అడగడం తెలిసి ఉంటే, సాధనాలను జాబితా చేసిన వెంటనే, మీరు కమిట్ కోసం పుల్ రిక్వెస్ట్‌లో పరీక్షలను నిర్మించి, అమలు చేసినప్పుడు CI అని వారు మీకు చెబుతారు.
నిరంతర ఏకీకరణ అనేది సాధనాల గురించి కాదు, బ్రాంచ్‌లో పరీక్షలతో కూడిన సమావేశాల గురించి కాదు! నిరంతర ఇంటిగ్రేషన్ అనేది కొత్త కోడ్‌ను చాలా తరచుగా ఏకీకృతం చేసే అభ్యాసం మరియు దానిని ఉపయోగించడం జెంకిన్స్, గిట్‌ల్యాబ్ మొదలైన వాటికి కంచె వేయడం అవసరం లేదు.
పూర్తి స్థాయి CI ఎలా ఉంటుందో మనం గుర్తించే ముందు, మొదట దానితో వచ్చిన వ్యక్తుల సందర్భంలో డైవ్ చేసి, వారు పరిష్కరించడానికి ప్రయత్నిస్తున్న బాధను అనుభవిద్దాం.
మరియు వారు ఒక జట్టుగా కలిసి పని చేయడం యొక్క బాధను పరిష్కరించారు!
జట్లలో అభివృద్ధి చెందుతున్నప్పుడు డెవలపర్లు ఎదుర్కొనే ఇబ్బందుల ఉదాహరణలను చూద్దాం. ఇక్కడ మనకు ఒక ప్రాజెక్ట్, gitలో మాస్టర్ బ్రాంచ్ మరియు ఇద్దరు డెవలపర్లు ఉన్నారు.
మరియు ప్రతి ఒక్కరూ చాలా కాలంగా అలవాటుపడినట్లుగా వారు పనికి వెళ్లారు. మేము గొప్ప స్కీమ్ ఆఫ్ థింగ్స్‌లో ఒక పనిని తీసుకున్నాము, ఫీచర్ బ్రాంచ్‌ను సృష్టించాము మరియు కోడ్‌ను వ్రాసాము.
ఒకరు లక్షణాన్ని వేగంగా పూర్తి చేసి, దానిని మాస్టర్‌లో విలీనం చేశారు.
రెండవదానికి మరింత సమయం కావాలి, అది తరువాత విలీనం చేయబడింది మరియు వివాదంతో ముగిసింది. ఇప్పుడు, వ్యాపారానికి అవసరమైన ఫీచర్‌లను వ్రాయడానికి బదులుగా, డెవలపర్ తన సమయాన్ని మరియు శక్తిని వివాదాలను పరిష్కరించడానికి వెచ్చిస్తాడు.
మీ లక్షణాన్ని సాధారణ మాస్టర్‌తో కలపడం ఎంత కష్టమో, మేము దానిపై ఎక్కువ సమయాన్ని వెచ్చిస్తాము. మరియు నేను దీన్ని చాలా సరళమైన ఉదాహరణతో చూపించాను. కేవలం 2 డెవలపర్లు మాత్రమే ఉన్న ఉదాహరణ ఇది. ఒక కంపెనీలో 10 లేదా 15 లేదా 100 మంది వ్యక్తులు ఒక రిపోజిటరీకి వ్రాస్తే ఊహించండి. ఈ వైరుధ్యాలన్నింటినీ పరిష్కరించడానికి మీరు వెర్రితలలు వేస్తారు.
కొంచెం భిన్నమైన కేసు ఉంది. మాకు మాస్టర్ మరియు కొంతమంది డెవలపర్లు ఉన్నారు.
వారు ఒక కొమ్మను సృష్టించారు.
ఒకరు చనిపోయారు, అంతా బాగానే ఉంది, అతను పనిని ఆమోదించాడు.
రెండవ డెవలపర్, అదే సమయంలో, తన పనిని అప్పగించాడు. అతను దానిని సమీక్షకు పంపాడు అనుకుందాం. చాలా కంపెనీలకు రివ్యూ అనే పద్ధతి ఉంది. ఒక వైపు, ఈ అభ్యాసం మంచిది మరియు ఉపయోగకరంగా ఉంటుంది, మరోవైపు, ఇది అనేక విధాలుగా మనల్ని నెమ్మదిస్తుంది. మేము దానిలోకి వెళ్లము, కానీ చెడు సమీక్ష కథనం దేనికి దారితీస్తుందో చెప్పడానికి ఇక్కడ ఒక గొప్ప ఉదాహరణ ఉంది. మీరు సమీక్ష కోసం పుల్ అభ్యర్థనను సమర్పించారు. డెవలపర్ చేయడానికి ఇంకేమీ లేదు. అతను ఏమి చేయడం ప్రారంభిస్తాడు? అతను ఇతర పనులను చేపట్టడం ప్రారంభిస్తాడు.
ఈ సమయంలో, రెండవ డెవలపర్ వేరే పని చేసారు.
మొదటిది మూడవ పనిని పూర్తి చేసింది.
మరియు చాలా కాలం తర్వాత, అతని సమీక్ష పరీక్షించబడింది మరియు అతను నిబంధనలకు రావడానికి ప్రయత్నిస్తున్నాడు. అయితే ఏమి జరుగుతుంది? ఇది భారీ సంఖ్యలో సంఘర్షణలను పట్టుకుంటుంది. ఎందుకు? ఎందుకంటే అతని పుల్ రిక్వెస్ట్ రివ్యూలో వేలాడుతూ ఉండగా, కోడ్‌లో ఇప్పటికే చాలా విషయాలు మారిపోయాయి.
సంఘర్షణలతో కూడిన కథతో పాటు కమ్యూనికేషన్స్‌తో కూడిన కథనం కూడా ఉంది. మీ థ్రెడ్ రివ్యూలో వేలాడుతున్నప్పుడు, అది దేనికోసమో వేచి ఉన్నప్పుడు, మీరు చాలా కాలం పాటు ఫీచర్‌పై పని చేస్తున్నప్పుడు, మీ సర్వీస్ కోడ్ బేస్‌లో ఇంకా ఏమి మారుతుందో ట్రాక్ చేయడం ఆపివేస్తారు. బహుశా మీరు ఇప్పుడు పరిష్కరించడానికి ప్రయత్నిస్తున్నది నిన్న ఇప్పటికే పరిష్కరించబడింది మరియు మీరు కొంత పద్ధతిని తీసుకొని దాన్ని మళ్లీ ఉపయోగించుకోవచ్చు. కానీ మీరు దీన్ని చూడలేరు ఎందుకంటే మీరు ఎల్లప్పుడూ పాత బ్రాంచ్‌తో పని చేస్తున్నారు. మరియు ఈ పాత బ్రాంచ్ ఎల్లప్పుడూ మీరు విలీన వైరుధ్యాన్ని పరిష్కరించవలసి ఉంటుంది.
మేము ఒక బృందంగా పని చేస్తే, అంటే, రిపోజిటరీలో ఒక వ్యక్తి కాదు, 5-10 మంది చుట్టూ తిరుగుతున్నట్లయితే, మనం ఎక్కువ కాలం మా కోడ్‌ను మాస్టర్‌కు జోడించకపోతే, అంతిమంగా మనకు అవసరమైనందున మనం ఎక్కువ బాధపడతాము. ఏదో తర్వాత దానిని విలీనం చేయండి. మరియు మనకు ఎక్కువ వైరుధ్యాలు మరియు పాత సంస్కరణతో పని చేస్తే, మనకు ఎక్కువ సమస్యలు ఉంటాయి.
కలిసి ఏదైనా చేయడం బాధాకరం! మేము ఎల్లప్పుడూ ఒకరి మార్గంలో మరొకరు ఉంటాము.
ఈ సమస్య 20 సంవత్సరాల క్రితం గమనించబడింది. ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్‌లో నిరంతర ఇంటిగ్రేషన్ అభ్యాసం గురించి నేను మొదటి ప్రస్తావనను కనుగొన్నాను.
ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ అనేది మొదటి చురుకైన ఫ్రేమ్‌వర్క్. పేజీ 96లో కనిపించింది. మరియు కొన్ని రకాల ప్రోగ్రామింగ్ పద్ధతులు, ప్రణాళిక మరియు ఇతర విషయాలను ఉపయోగించాలనే ఆలోచన ఉంది, తద్వారా అభివృద్ధి సాధ్యమైనంత సరళంగా ఉంటుంది, తద్వారా మేము మా క్లయింట్ల నుండి ఏవైనా మార్పులు లేదా అవసరాలకు త్వరగా ప్రతిస్పందించగలము. మరియు వారు 24 సంవత్సరాల క్రితం దీనిని ఎదుర్కోవడం ప్రారంభించారు, మీరు చాలా కాలం పాటు ఏదైనా చేస్తే, మీకు విభేదాలు ఉన్నందున మీరు దానిపై ఎక్కువ సమయం గడుపుతారు.
ఇప్పుడు మేము "నిరంతర ఏకీకరణ" అనే పదబంధాన్ని ఒక్కొక్కటిగా విశ్లేషిస్తాము. మనం దానిని నేరుగా అనువదిస్తే, మనకు నిరంతర ఏకీకరణ లభిస్తుంది. కానీ ఇది ఎంత నిరంతరాయంగా ఉంటుందో చాలా స్పష్టంగా లేదు; ఇది చాలా నిరంతరాయంగా ఉంది. కానీ ఇది ఎంత ఏకీకరణను కలిగి ఉందో కూడా చాలా స్పష్టంగా లేదు.
అందుకే నేను ఇప్పుడు మీకు ఎక్స్‌ట్రీమ్ ప్రోగ్రామింగ్ నుండి కోట్స్ ఇస్తున్నాను. మరియు మేము రెండు పదాలను విడిగా విశ్లేషిస్తాము.
ఇంటిగ్రేషన్ - నేను ఇప్పటికే చెప్పినట్లుగా, ప్రతి ఇంజనీర్ కోడ్ యొక్క అత్యంత ప్రస్తుత వెర్షన్‌తో పని చేసేలా మేము కృషి చేస్తాము, తద్వారా అతను తన కోడ్‌ను ఒక సాధారణ బ్రాంచ్‌కు వీలైనంత తరచుగా జోడించడానికి ప్రయత్నిస్తాడు, తద్వారా ఇవి చిన్న శాఖలుగా ఉంటాయి. ఎందుకంటే అవి పెద్దవిగా ఉంటే, మనం ఒక వారం పాటు విలీన వైరుధ్యాలతో సులభంగా చిక్కుకుపోవచ్చు. మేము జలపాతం వంటి సుదీర్ఘ అభివృద్ధి చక్రం కలిగి ఉన్నట్లయితే ఇది ప్రత్యేకంగా వర్తిస్తుంది, ఇక్కడ డెవలపర్ కొన్ని భారీ ఫీచర్‌లను తగ్గించడానికి ఒక నెల పాటు వెళ్లిపోతాడు. మరియు అతను చాలా కాలం పాటు ఏకీకరణ దశలో ఇరుక్కుపోతాడు.
ఇంటిగ్రేషన్ అంటే మనం మన శాఖను తీసుకొని దానిని మాస్టర్‌తో ఏకీకృతం చేసినప్పుడు, మనం దానిని విలీనం చేస్తాము. మేము ట్రాన్స్‌బేస్ డెవలపర్‌గా ఉన్నప్పుడు అంతిమ ఎంపిక ఉంది, ఇక్కడ మేము ఎటువంటి అదనపు శాఖలు లేకుండా మాస్టర్‌కు వెంటనే వ్రాసేలా కృషి చేస్తాము.
సాధారణంగా, ఇంటిగ్రేషన్ అంటే మీ కోడ్‌ని తీసుకొని దానిని మాస్టర్‌లోకి లాగడం.
ఇక్కడ "నిరంతర" అనే పదానికి అర్థం ఏమిటి, దానిని కొనసాగింపు అంటారు? డెవలపర్ తన కోడ్‌ను వీలైనంత త్వరగా ఏకీకృతం చేయడానికి ప్రయత్నిస్తాడని ప్రాక్టీస్ సూచిస్తుంది. ఏదైనా పని చేస్తున్నప్పుడు ఇది అతని లక్ష్యం - వీలైనంత త్వరగా అతని కోడ్‌ను మాస్టర్‌గా పొందడం. ఆదర్శవంతమైన ప్రపంచంలో, డెవలపర్లు ప్రతి కొన్ని గంటలకు దీన్ని చేస్తారు. అంటే, మీరు ఒక చిన్న సమస్యను తీసుకొని దానిని మాస్టర్‌లో విలీనం చేయండి. అంతా గొప్పగా ఉంది. దీని కోసం మీరు ప్రయత్నిస్తున్నారు. మరియు ఇది నిరంతరం చేయాలి. మీరు ఏదైనా చేసిన వెంటనే, మీరు దానిని మాస్టర్‌లో ఉంచుతారు.
మరియు దేనినైనా తయారు చేసే డెవలపర్ దానిని పని చేయడానికి మరియు దేనినీ విచ్ఛిన్నం చేయకుండా చేయడానికి అతను చేసిన దానికి బాధ్యత వహిస్తాడు. సాధారణంగా పరీక్ష కథనం ఇక్కడే వస్తుంది. ఇది పని చేస్తుందని నిర్ధారించుకోవడానికి మేము మా నిబద్ధతపై, మా విలీనంపై కొన్ని పరీక్షలను అమలు చేయాలనుకుంటున్నాము. మరియు ఇక్కడే జెంకిన్స్ మీకు సహాయం చేయగలరు.
కానీ కథలతో: మార్పులను చిన్నదిగా చేద్దాం, పనులు చిన్నవిగా ఉండనివ్వండి, సమస్యను చేద్దాం మరియు వెంటనే దానిని మాస్టర్‌లో పొందుపరచడానికి ప్రయత్నిద్దాం - ఇక్కడ జెంకిన్స్ ఎవరూ సహాయం చేయరు. ఎందుకంటే జెంకిన్స్ మీకు పరీక్షలను నిర్వహించడంలో మాత్రమే సహాయం చేస్తుంది.
మీరు వాటిని లేకుండా చేయవచ్చు. ఇది మిమ్మల్ని అస్సలు బాధించదు. ఎందుకంటే ఆచరణ యొక్క లక్ష్యం సాధ్యమైనంత తరచుగా కొలవడం, తద్వారా భవిష్యత్తులో ఏదైనా సంఘర్షణలపై ఎక్కువ సమయం వృథా చేయకూడదు.
కొన్ని కారణాల వల్ల మనం 2020లో ఇంటర్నెట్ లేకుండా ఉన్నామని ఊహించుకుందాం. మరియు మేము స్థానికంగా పని చేస్తాము. మాకు జెంకిన్స్ లేరు. ఇది బాగానే ఉంది. మీరు ఇంకా ముందుకు వెళ్లి స్థానిక శాఖను ఏర్పాటు చేసుకోవచ్చు. మీరు అందులో కొంత కోడ్ రాశారు. మేము 3-4 గంటల్లో పనిని పూర్తి చేసాము. మేము మాస్టర్‌కి మారాము, ఒక git పుల్ చేసాము మరియు మా శాఖను అక్కడ విలీనం చేసాము. సిద్ధంగా ఉంది. మీరు దీన్ని తరచుగా చేస్తే, అభినందనలు, మీకు నిరంతర ఏకీకరణ ఉంటుంది!
ఆధునిక ప్రపంచంలో శక్తిని ఖర్చు చేయడం విలువైనది అని ఏ సాక్ష్యం ఉంది? ఎందుకంటే సాధారణంగా ఇది కష్టం. మీరు ఇలా పని చేయడానికి ప్రయత్నిస్తే, ఇప్పుడు కొంత ప్రణాళిక దెబ్బతింటుందని మీరు అర్థం చేసుకుంటారు, మీరు కుళ్ళిపోయే పనులకు ఎక్కువ సమయం కేటాయించవలసి ఉంటుంది. ఎందుకంటే మీరు మనిషిని చేస్తే ..., మీరు త్వరగా ఒప్పుకోలేరు మరియు తదనుగుణంగా, ఇబ్బందుల్లో పడతారు. మీకు ఇకపై అభ్యాసం ఉండదు.
మరియు అది ఖరీదైనది అవుతుంది. కంటిన్యూయస్ ఇంటిగ్రేషన్ ఉపయోగించి రేపటి నుండి వెంటనే పని చేయడం సాధ్యం కాదు. మీ అందరికీ అలవాటు పడటానికి చాలా సమయం పడుతుంది, కుళ్ళిపోయే పనికి అలవాటు పడటానికి మీకు చాలా సమయం పడుతుంది, రివ్యూ ప్రాక్టీస్‌ని మళ్లీ చేయడం అలవాటు చేసుకోవడానికి చాలా సమయం పడుతుంది, మీకు ఒకటి ఉంటే . ఎందుకంటే అది ఈరోజు కరిగిపోవడమే మా లక్ష్యం. మరియు మీరు మూడు రోజులలోపు సమీక్ష చేస్తే, మీకు సమస్యలు ఉన్నాయి మరియు నిరంతర ఏకీకరణ మీ కోసం పని చేయదు.
అయితే ఈ పద్ధతిలో పెట్టుబడి పెట్టడం సమంజసమని చెప్పే సంబంధిత ఆధారాలు ఏమైనా ఉన్నాయా?
నా మనసులోకి వచ్చిన మొదటి విషయం స్టేట్ ఆఫ్ DevOps. ఇది అబ్బాయిలు 7 సంవత్సరాలుగా నిర్వహిస్తున్న అధ్యయనం. ఇప్పుడు వారు దీన్ని స్వతంత్ర సంస్థగా చేస్తారు, కానీ Google కింద.
మరియు వారి 2018 అధ్యయనం స్వల్పకాలిక శాఖలను ఉపయోగించడానికి ప్రయత్నించే కంపెనీల మధ్య సహసంబంధాన్ని చూపింది, ఇవి త్వరగా ఏకీకృతం అవుతాయి, తరచుగా ఏకీకృతం చేయబడతాయి మరియు మెరుగైన IT పనితీరు సూచికలను కలిగి ఉంటాయి.
ఈ సూచికలు ఏమిటి? ఇవి తమ ప్రశ్నపత్రాలలో అన్ని కంపెనీల నుండి తీసుకునే 4 కొలమానాలు: విస్తరణ ఫ్రీక్వెన్సీ, మార్పులకు ప్రధాన సమయం, సేవను పునరుద్ధరించడానికి సమయం, వైఫల్యం రేటును మార్చడం.
మరియు, ముందుగా, ఈ సహసంబంధం ఉంది, తరచుగా కొలిచే కంపెనీలు మెరుగైన కొలమానాలను కలిగి ఉంటాయని మాకు తెలుసు. మరియు వారు కంపెనీల విభజనను అనేక వర్గాలుగా కలిగి ఉన్నారు: ఇవి నెమ్మదిగా ఉత్పత్తి చేసే కంపెనీలు, మీడియం పెర్ఫార్మర్, హై పెర్ఫార్మర్ మరియు ఎలైట్. ఎలైట్ నెట్‌ఫ్లిక్స్, అమెజాన్, ఇవి చాలా వేగంగా ఉంటాయి, ప్రతిదీ త్వరగా, అందంగా మరియు సమర్ధవంతంగా చేస్తాయి.
ఒక నెల క్రితం జరిగిన రెండవ కథ. టెక్నాలజీ రాడార్ Gitflow గురించి గొప్ప కథనాన్ని కలిగి ఉంది. Gitflow దాని శాఖలు దీర్ఘకాలం ఉండేలా అన్నిటికంటే భిన్నంగా ఉంటాయి. చాలా కాలం పాటు జీవించే విడుదల శాఖలు మరియు ఎక్కువ కాలం జీవించే ఫీచర్ బ్రాంచ్‌లు ఉన్నాయి. టెక్నాలజీ రాడార్ వద్ద ఈ అభ్యాసం హోల్డ్‌కి మార్చబడింది. ఎందుకు? ఎందుకంటే ప్రజలు ఏకీకరణ యొక్క బాధను ఎదుర్కొంటారు.
మీ శాఖ చాలా కాలం పాటు నివసిస్తుంటే, అది చిక్కుకుపోతుంది, కుళ్ళిపోతుంది మరియు మేము దానిని మార్చడానికి ఎక్కువ సమయం గడపడం ప్రారంభిస్తాము.
మరియు ఇటీవలే Gitflow రచయిత మాట్లాడుతూ, మీ లక్ష్యం నిరంతర ఇంటిగ్రేషన్ అయితే, మీ లక్ష్యం మీరు వీలైనంత తరచుగా రోల్ చేయాలనుకుంటే, Gitflow ఒక చెడ్డ ఆలోచన. మీరు దీని కోసం ప్రయత్నించగల బ్యాకెండ్ మీకు ఉంటే, Gitflow మీకు నిరుపయోగంగా ఉంటుంది, ఎందుకంటే Gitflow మిమ్మల్ని నెమ్మదిస్తుంది, Gitflow మీ కోసం ఏకీకరణతో సమస్యలను సృష్టిస్తుంది అని అతను వ్యాసానికి విడిగా జోడించాడు.
Gitflow చెడ్డదని మరియు ఉపయోగించకూడదని దీని అర్థం కాదు. ఇది ఇతర సందర్భాలలో. ఉదాహరణకు, మీరు సేవ లేదా అప్లికేషన్ యొక్క అనేక వెర్షన్‌లకు మద్దతు ఇవ్వవలసి వచ్చినప్పుడు, అంటే మీకు ఎక్కువ కాలం పాటు మద్దతు అవసరం.
కానీ మీరు అలాంటి సేవలకు మద్దతు ఇచ్చే వ్యక్తులతో మాట్లాడినట్లయితే, ఈ సంస్కరణ 3.2 అని మీరు చాలా బాధను వింటారు, ఇది 4 నెలల క్రితం, కానీ ఈ పరిష్కారాన్ని దానిలో చేర్చలేదు మరియు ఇప్పుడు, దీన్ని చేయడానికి, మీరు కొన్ని మార్పులు చేయాలి. మరియు ఇప్పుడు వారు మళ్లీ చిక్కుకుపోయారు మరియు ఇప్పుడు వారు కొన్ని కొత్త ఫీచర్‌లను అమలు చేయడానికి ప్రయత్నిస్తున్నారు.
అలెగ్జాండర్ కోవెలెవ్ చాట్‌లో సరిగ్గా గుర్తించినట్లుగా, సహసంబంధం కారణంతో సమానం కాదు. ఇది నిజం. అంటే, మీకు కంటిన్యూయస్ ఇంటిగ్రేషన్ ఉంటే, అన్ని కొలమానాలు గొప్పగా ఉంటాయని ప్రత్యక్ష సంబంధం లేదు. కానీ ఒక సానుకూల సహసంబంధం ఉంది, ఒకటి అయితే, చాలా మటుకు మరొకటి కూడా ఉంటుంది. వాస్తవం కాదు, కానీ చాలా మటుకు. ఇది కేవలం ఒక సహసంబంధం.
మనం ఇప్పటికే ఏదో చేస్తున్నామని అనిపిస్తోంది, మనం ఇప్పటికే విలీనం అవుతున్నట్లు అనిపిస్తుంది, కానీ మనకు ఇప్పటికీ నిరంతర ఏకీకరణ ఉందని, మనం తరచుగా విలీనం అవుతున్నామని ఎలా అర్థం చేసుకోవాలి?
Jez Humble హ్యాండ్‌బుక్, యాక్సిలరేట్, కంటిన్యూయస్ డెలివరీ వెబ్‌సైట్ మరియు నిరంతర డెలివరీ పుస్తక రచయిత. అతను ఈ పరీక్షను అందిస్తాడు:
- ఇంజనీర్ కోడ్ ప్రతిరోజూ మాస్టర్‌కు అందుతుంది.
- ప్రతి కమిట్ కోసం మీరు యూనిట్ పరీక్షలను అమలు చేస్తారు.
- మాస్టర్‌లో బిల్డ్ పడిపోయింది, ఇది సుమారు 10 నిమిషాల్లో పరిష్కరించబడింది.
మీకు తగినంత అభ్యాసం ఉందని నిర్ధారించుకోవడానికి ఇలాంటి పరీక్షను ఉపయోగించమని అతను సూచిస్తున్నాడు.
నేను రెండోది కొంచెం వివాదాస్పదంగా ఉన్నాను. అంటే, మీరు దీన్ని 10 నిమిషాల్లో పరిష్కరించగలిగితే, మీకు నిరంతర ఇంటిగ్రేషన్ ఉంది, ఇది కొంచెం వింతగా అనిపిస్తుంది, నా అభిప్రాయం, కానీ ఇది అర్ధమే. ఎందుకు? ఎందుకంటే మీరు తరచుగా స్తంభింపజేస్తే, మీ మార్పులు చిన్నవిగా ఉన్నాయని అర్థం. చిన్న మార్పు అంటే మీ మాస్టర్ బిల్డ్ విచ్ఛిన్నమైందని అర్థం, మార్పు చిన్నది అయినందున మీరు త్వరగా ఒక ఉదాహరణను కనుగొనవచ్చు. ఇక్కడ మీరు ఒక చిన్న విలీనాన్ని కలిగి ఉన్నారు, దానిలో 20-30 పంక్తులు మార్చబడ్డాయి. మరియు, తదనుగుణంగా, కారణం ఏమిటో మీరు త్వరగా అర్థం చేసుకోవచ్చు, ఎందుకంటే మార్పులు చిన్నవిగా ఉంటాయి, సమస్య కోసం శోధించడానికి మీకు చాలా చిన్న ప్రాంతం ఉంది.
మరియు విడుదల తర్వాత మా ఉత్పత్తి విరిగిపోయినప్పటికీ, మనకు నిరంతర ఇంటిగ్రేషన్ అభ్యాసం ఉంటే, మార్పులు చిన్నవిగా ఉన్నందున మేము నటించడం చాలా సులభం. అవును, ఇది ప్రణాళికను ప్రభావితం చేస్తుంది. ఇది బాధిస్తుంది. మరియు, బహుశా, ఈ అభ్యాసంలో చాలా కష్టమైన విషయం ఏమిటంటే, పనులను విచ్ఛిన్నం చేయడం అలవాటు చేసుకోవడం, అంటే, దీన్ని ఎలా చేయాలి, తద్వారా మీరు ఏదైనా తీసుకొని కొన్ని గంటల్లో చేయవచ్చు మరియు అదే సమయంలో సమీక్షను పాస్ చేయవచ్చు. మీకు ఒకటి ఉంది. సమీక్ష అనేది ఒక ప్రత్యేక నొప్పి.
యూనిట్ పరీక్షలు మీ ఏకీకరణ విజయవంతమైందా మరియు ఏమీ విచ్ఛిన్నం కాలేదా అని అర్థం చేసుకోవడానికి మీకు సహాయపడే సహాయకం. నా అభిప్రాయం ప్రకారం, ఇది కూడా పూర్తిగా తప్పనిసరి కాదు, ఎందుకంటే ఇది ఆచరణాత్మక అంశం కాదు.
ఇది నిరంతర ఏకీకరణకు సంక్షిప్త పరిచయం. ఈ సాధన కూడా అంతే. నేను ప్రశ్నలకు సిద్ధంగా ఉన్నాను.
నేను మళ్ళీ క్లుప్తంగా సంగ్రహిస్తాను:
- నిరంతర ఇంటిగ్రేషన్ జెంకిన్స్ కాదు, గిట్లాబ్ కాదు.
- ఇది సాధనం కాదు, మేము మా కోడ్‌ను వీలైనంత తరచుగా మాస్టర్‌లో విలీనం చేయడం ఒక అభ్యాసం.
- భవిష్యత్తులో విలీనాలతో ఉత్పన్నమయ్యే అపారమైన నొప్పిని నివారించడానికి మేము దీన్ని చేస్తాము, అంటే, భవిష్యత్తులో ఎక్కువ అనుభవించకుండా ఉండటానికి మేము ఇప్పుడు కొద్దిగా నొప్పిని అనుభవిస్తాము. అది మొత్తం పాయింట్.
- ప్రక్కన కోడ్ ద్వారా కమ్యూనికేషన్ ఉంది, కానీ నేను దీన్ని చాలా అరుదుగా చూస్తాను, కానీ ఇది కూడా దీని కోసం రూపొందించబడింది.
మీ ప్రశ్నలు
కుళ్ళిపోని పనులను ఏమి చేయాలి?
కుళ్ళిపోవు. సమస్య ఏమిటి? ఒక పని ఉంది మరియు అది కుళ్ళిపోలేదని మీరు ఉదాహరణగా చెప్పగలరా?
"పూర్తిగా" అనే పదం నుండి కుళ్ళిపోలేని పనులు ఉన్నాయి, ఉదాహరణకు, చాలా లోతైన నైపుణ్యం అవసరమయ్యేవి మరియు వాస్తవానికి కొంత జీర్ణమయ్యే ఫలితాన్ని సాధించడానికి ఒక నెల వ్యవధిలో పరిష్కరించబడతాయి.
నేను మిమ్మల్ని సరిగ్గా అర్థం చేసుకుంటే, కొన్ని పెద్ద మరియు సంక్లిష్టమైన పని ఉంది, దాని ఫలితం ఒక నెలలో మాత్రమే కనిపిస్తుంది?
అవును అది ఒప్పు. అవును, ఒక నెల కంటే ముందుగానే ఫలితాన్ని అంచనా వేయడం సాధ్యమవుతుంది.
ఫైన్. సాధారణంగా ఇది సమస్య కాదు. ఎందుకు? ఎందుకంటే ఈ సందర్భంలో, మేము కొమ్మల గురించి మాట్లాడేటప్పుడు, మేము ఒక లక్షణం ఉన్న కొమ్మ గురించి మాట్లాడటం లేదు. లక్షణాలు పెద్దవిగా మరియు సంక్లిష్టంగా ఉంటాయి. వారు పెద్ద సంఖ్యలో భాగాలను ప్రభావితం చేయవచ్చు. మరియు బహుశా మేము వాటిని ఒక శాఖలో పూర్తిగా చేయలేము. ఇది బాగానే ఉంది. మేము ఈ కథను విచ్ఛిన్నం చేయాలి. ఫీచర్ పూర్తిగా సిద్ధంగా లేకుంటే, దాని కోడ్‌లోని కొన్ని ముక్కలను విలీనం చేయడం సాధ్యం కాదని దీని అర్థం కాదు. మీరు మైగ్రేషన్‌ని జోడించారు మరియు ఫీచర్‌లో కొన్ని దశలు ఉన్నాయి. మీకు దశ ఉందని అనుకుందాం - వలసలు చేయండి, కొత్త పద్ధతిని జోడించండి. మరియు మీరు ఇప్పటికే ప్రతిరోజూ ఈ విషయాలను కొలవవచ్చు.
ఫైన్. అప్పుడు ప్రయోజనం ఏమిటి?
రోజూ చిన్న చిన్న వస్తువులను చంపడం వల్ల ప్రయోజనం ఏమిటి?
అవును.
వారు ఏదైనా విచ్ఛిన్నం చేస్తే, మీరు వెంటనే దాన్ని చూస్తారు. మీరు ఏదైనా విరిగిపోయిన చిన్న భాగాన్ని కలిగి ఉన్నారు, దాన్ని పరిష్కరించడం మీకు సులభం. విషయమేమిటంటే, కొన్ని వారాల్లో పెద్దదాన్ని విలీనం చేయడం కంటే ఇప్పుడు చిన్న భాగాన్ని విలీనం చేయడం చాలా సులభం. మరియు మూడవ అంశం ఏమిటంటే, ఇతర ఇంజనీర్లు కోడ్ యొక్క ప్రస్తుత సంస్కరణతో పని చేస్తారు. ఇక్కడ కొన్ని మైగ్రేషన్‌లు జోడించబడిందని వారు చూస్తారు, ఆపై వారు కూడా ఉపయోగించాలనుకునే కొన్ని పద్ధతి కనిపించింది. మీ కోడ్‌లో ఏమి జరుగుతుందో అందరూ చూస్తారు. ఈ మూడు విషయాల కోసమే సాధన చేస్తారు.
ధన్యవాదాలు, సమస్య మూసివేయబడింది!
(ఒలేగ్ సోరోకా) నేను జోడించవచ్చా? మీరు ప్రతిదీ సరిగ్గా చెప్పారు, నేను ఒక పదబంధాన్ని జోడించాలనుకుంటున్నాను.
కాబట్టి.
కంటిన్యూయస్ ఇంటిగ్రేషన్‌తో, కోడ్ ఒక సాధారణ బ్రాంచ్‌లో విలీనం చేయబడుతుంది, ఫీచర్ పూర్తిగా సిద్ధంగా ఉన్నప్పుడు కాదు, కానీ బిల్డ్ బ్రేకింగ్ ఆగిపోయినప్పుడు. మరియు మీరు సురక్షితంగా మీకు కావలసినన్ని సార్లు ఒక రోజు మాస్టర్ కట్టుబడి చేయవచ్చు. రెండవ అంశం ఏమిటంటే, కొన్ని కారణాల వల్ల మీరు నెలవారీ పనిని కనీసం మూడు రోజుల పాటు విధులుగా విభజించలేకపోతే, నేను మూడు గంటలు మౌనంగా ఉన్నాను, అప్పుడు మీకు చాలా పెద్ద సమస్య ఉంది. మరియు మీకు కంటిన్యూయస్ ఇంటిగ్రేషన్ లేకపోవడమే ఈ సమస్యలలో అతి తక్కువ. అంటే మీకు ఆర్కిటెక్చర్ మరియు జీరో ఇంజనీరింగ్ ప్రాక్టీస్‌లతో సమస్యలు ఉన్నాయని అర్థం. ఎందుకంటే ఇది పరిశోధన అయినప్పటికీ, ఏ సందర్భంలోనైనా ఇది పరికల్పనల రూపంలో లేదా చక్రం రూపంలో రూపొందించబడాలి.
మేము విజయవంతమైన కంపెనీలను వెనుకబడిన వాటి నుండి వేరుచేసే 4 కొలమానాల గురించి మాట్లాడాము. ఈ 4 కొలమానాలను చూడాలంటే మనం ఇంకా జీవించాలి. మీ సగటు పని పూర్తి కావడానికి ఒక నెల పట్టినట్లయితే, నేను ముందుగా ఈ మెట్రిక్‌పై దృష్టి పెడతాను. నేను మొదట దానిని 3 రోజులకు తగ్గిస్తాను. ఇక ఆ తర్వాత కంటిన్యూస్ గురించి ఆలోచించడం మొదలుపెట్టాను.
సాధారణంగా ఏదైనా పని పూర్తి కావడానికి నెల రోజులు పడితే ఇంజనీరింగ్ ప్రాక్టీస్‌లో పెట్టుబడి పెట్టడం వల్ల ప్రయోజనం ఉండదని మీరు అనుకుంటున్నారని నేను మీకు సరిగ్గా అర్థం చేసుకున్నానా?
మీకు నిరంతర ఏకీకరణ ఉంది. మరియు 10 నిమిషాల్లో మీరు పరిష్కారాన్ని పరిష్కరించవచ్చు లేదా దాన్ని వెనక్కి తిప్పవచ్చు. మీరు దాన్ని బయటకు తీశారని ఊహించుకోండి. అంతేకాకుండా, మీరు నిరంతర విస్తరణను కూడా కలిగి ఉన్నారు, మీరు దానిని ఉత్పత్తికి రూపొందించారు మరియు అప్పుడు మాత్రమే ఏదో తప్పు జరిగిందని గమనించారు. మరియు మీరు దాన్ని వెనక్కి తిప్పాలి, కానీ మీరు ఇప్పటికే మీ డేటాబేస్‌ను మార్చారు. మీరు ఇప్పటికే తదుపరి సంస్కరణ యొక్క డేటాబేస్ స్కీమాను కలిగి ఉన్నారు, అంతేకాకుండా, మీకు కొంత రకమైన బ్యాకప్ కూడా ఉంది మరియు డేటా కూడా అక్కడ వ్రాయబడింది.
మరియు మీకు ఏ ప్రత్యామ్నాయం ఉంది? మీరు కోడ్‌ని వెనక్కి తీసుకుంటే, అది ఈ అప్‌డేట్ చేయబడిన డేటాబేస్‌తో ఇకపై పని చేయదు.
ఆధారం మాత్రమే ముందుకు కదులుతుంది, అవును.
పేలవమైన ఇంజినీరింగ్ అభ్యాసాలు ఉన్న వ్యక్తులు చాలా వరకు మందపాటి పుస్తకాన్ని చదవలేదు ... బ్యాకప్‌తో ఏమి చేయాలి? మీరు బ్యాకప్ నుండి పునరుద్ధరించినట్లయితే, ఆ సమయంలో మీరు సేకరించిన డేటాను కోల్పోతారని అర్థం. ఉదాహరణకు, మేము డేటాబేస్ యొక్క కొత్త వెర్షన్‌తో మూడు గంటలు పనిచేశాము, వినియోగదారులు అక్కడ నమోదు చేసుకున్నారు. కొత్త వెర్షన్‌తో స్కీమ్ పని చేయనందున మీరు పాత బ్యాకప్‌ను తిరస్కరించారు, కాబట్టి మీరు ఈ వినియోగదారులను కోల్పోయారు. మరియు వారు అసంతృప్తి చెందారు, వారు ప్రమాణం చేస్తారు.
నిరంతర ఏకీకరణ మరియు నిరంతర డెలివరీకి మద్దతు ఇచ్చే పూర్తి స్థాయి అభ్యాసాలను నేర్చుకోవడానికి, ఎలా వ్రాయాలో నేర్చుకోవడం మాత్రమే సరిపోదు.... మొదట, వాటిలో చాలా ఉండవచ్చు, ఇది అసాధ్యమైనది. అదనంగా సైంటిఫిక్ వంటి ఇతర అభ్యాసాల సమూహం కూడా ఉన్నాయి. అటువంటి అభ్యాసం ఉంది, GitHub ఒక సమయంలో దానిని ప్రాచుర్యం పొందింది. మీరు పాత కోడ్ మరియు కొత్త కోడ్ రెండింటినీ ఒకే సమయంలో అమలు చేస్తున్నప్పుడు ఇది జరుగుతుంది. మీరు అసంపూర్తిగా ఉన్న లక్షణాన్ని చేసినప్పుడు ఇది జరుగుతుంది, అయితే ఇది కొంత విలువను అందిస్తుంది: ఫంక్షన్‌గా లేదా రెస్ట్ APIగా. మీరు కొత్త కోడ్ మరియు పాత కోడ్ రెండింటినీ అమలు చేసి, వాటి మధ్య వ్యత్యాసాన్ని సరిపోల్చండి. మరియు ఏదైనా తేడా ఉంటే, మీరు ఈ ఈవెంట్‌ను లాగిన్ చేయండి. ఈ విధంగా మీరు ఒక నిర్దిష్ట సమయం వరకు రెండింటి మధ్య వైరుధ్యాన్ని కలిగి ఉండకపోతే, పాత దాని పైన కొత్త ఫీచర్‌ని అందుబాటులోకి తీసుకురావడానికి సిద్ధంగా ఉన్నారని మీకు తెలుస్తుంది.
ఇలాంటి పద్ధతులు వందల సంఖ్యలో ఉన్నాయి. ట్రాన్స్‌బేస్ డెవలప్‌మెంట్‌తో ప్రారంభించాలని నేను సూచిస్తున్నాను. ఆమె కంటిన్యూయస్ ఇంటిగ్రేషన్‌లో 100% లేదు, కానీ అభ్యాసాలు ఒకే విధంగా ఉంటాయి, ఒకరు లేకుండా మరొకరు బాగా జీవించలేరు.
మీరు ప్రాక్టీస్‌లను చూడగలిగేలా ట్రాన్స్‌బేస్ డెవలప్‌మెంట్‌ని ఉదాహరణగా అందించారా లేదా వ్యక్తులు ట్రాన్స్‌బేస్ డీబెలప్‌మెంట్‌ని ఉపయోగించడం ప్రారంభించమని సూచిస్తున్నారా?
చూడండి, ఎందుకంటే వారు దానిని ఉపయోగించలేరు. వాటిని ఉపయోగించడానికి, మీరు చాలా చదవాలి. మరియు ఒక వ్యక్తి ఇలా అడిగినప్పుడు: "ఒక నెల సమయం పట్టే ఫీచర్‌తో ఏమి చేయాలి, అతను ట్రాన్స్‌బేస్ డెవలప్‌మెంట్ గురించి చదవలేదని అర్థం." నేను దీన్ని ఇంకా సిఫార్సు చేయను. వాస్తుపరంగా పెద్ద పనులను చిన్నవిగా ఎలా విభజించాలో అనే అంశంపై మాత్రమే దృష్టి పెట్టాలని నేను సలహా ఇస్తాను. ఇది కుళ్ళిపోవటం యొక్క సారాంశం.
కుళ్ళిపోవడం వాస్తుశిల్పి యొక్క సాధనాలలో ఒకటి. మేము మొదట విశ్లేషణ చేస్తాము, తరువాత కుళ్ళిపోవడం, తరువాత సంశ్లేషణ, తరువాత ఏకీకరణ. మరియు ఈ విధంగా ప్రతిదీ మాకు పని చేస్తుంది. మరియు మనం ఇంకా కుళ్ళిపోవడం ద్వారా నిరంతర ఏకీకరణకు ఎదగాలి. మొదటి దశలో ప్రశ్నలు తలెత్తుతాయి మరియు మేము ఇప్పటికే నాల్గవ దశ గురించి మాట్లాడుతున్నాము, అంటే మనం ఎంత తరచుగా ఏకీకరణ చేస్తే అంత మంచిది. దీన్ని చేయడం ఇంకా చాలా తొందరగా ఉంది; ముందుగా మీ ఏకశిలాను కత్తిరించడం మంచిది.
మీరు కొన్ని రేఖాచిత్రంలో అనేక బాణాలు మరియు చతురస్రాలను గీయాలి. ఇప్పుడు నేను కొత్త అప్లికేషన్ యొక్క ఆర్కిటెక్చరల్ రేఖాచిత్రాన్ని చూపుతాను మరియు ఒక చతురస్రాన్ని చూపిస్తాను, దాని లోపల అప్లికేషన్ కోసం ఆకుపచ్చ బటన్ ఉంది. ఏదైనా సందర్భంలో, మరిన్ని చతురస్రాలు మరియు బాణాలు ఉంటాయి. నేను చూసిన ప్రతి రేఖాచిత్రంలో ఒకటి కంటే ఎక్కువ ఉన్నాయి. మరియు గ్రాఫికల్ ప్రాతినిధ్య స్థాయిలో కూడా కుళ్ళిపోవడం ఇప్పటికే జరుగుతోంది. అందువలన, చతురస్రాలు స్వతంత్రంగా చేయవచ్చు. కాకపోతే, ఆర్కిటెక్ట్ కోసం నాకు పెద్ద ప్రశ్నలు ఉన్నాయి.
చాట్ నుండి ఒక ప్రశ్న ఉంది: "సమీక్ష తప్పనిసరి మరియు ఎక్కువ సమయం తీసుకుంటే, బహుశా ఒక రోజు లేదా అంతకంటే ఎక్కువ?"
మీకు అభ్యాసంలో సమస్యలు ఉన్నాయి. సమీక్ష ఒక రోజు లేదా అంతకంటే ఎక్కువ ఉండకూడదు. ఇది మునుపటి ప్రశ్నకు అదే కథ, కొంచెం మృదువైనది. ఒక రోజు సమీక్ష కొనసాగితే, ఈ సమీక్ష చాలా పెద్ద మార్పును కలిగి ఉంటుంది. దీన్ని చిన్నదిగా చేయాల్సిన అవసరం ఉందని దీని అర్థం. ఒలేగ్ సిఫార్సు చేసిన ట్రాన్స్‌బేస్ డెవలప్‌మెంట్‌లో, నిరంతర సమీక్ష అనే కథనం ఉంది. ఆమె ఆలోచన ఏమిటంటే, మేము ఉద్దేశపూర్వకంగా అలాంటి చిన్న పుల్ అభ్యర్థనను చేస్తాము, ఎందుకంటే మేము నిరంతరం మరియు ఒక సమయంలో కొద్దిగా విలీనం చేయడానికి ప్రయత్నిస్తాము. కాబట్టి పుల్ అభ్యర్థన ఒక సంగ్రహణ లేదా 10 పంక్తులను మారుస్తుంది. ఈ సమీక్షకు ధన్యవాదాలు, ఇది మాకు రెండు నిమిషాలు పడుతుంది.
సమీక్షకు ఒక రోజు లేదా అంతకంటే ఎక్కువ సమయం పట్టినట్లయితే, ఏదో తప్పు జరిగింది. మొదట, మీకు వాస్తుశాస్త్రంలో కొన్ని సమస్యలు ఉండవచ్చు. లేదా ఇది పెద్ద కోడ్ ముక్క, ఉదాహరణకు 1 లైన్లు. లేదా మీ నిర్మాణం చాలా క్లిష్టంగా ఉంది, ఒక వ్యక్తి దానిని అర్థం చేసుకోలేడు. ఇది కొంచెం పక్కదారి పట్టే సమస్య, కానీ ఇది కూడా పరిష్కరించబడాలి. బహుశా సమీక్ష అవసరం లేదు. దీని గురించి కూడా మనం ఆలోచించాలి. సమీక్ష అనేది మిమ్మల్ని నెమ్మదిస్తుంది. ఇది సాధారణంగా దాని ప్రయోజనాలను కలిగి ఉంది, కానీ మీరు దీన్ని ఎందుకు చేస్తున్నారో అర్థం చేసుకోవాలి. మీరు సమాచారాన్ని త్వరగా తెలియజేయడానికి ఇది ఒక మార్గమా, మీరు అంతర్గతంగా కొన్ని ప్రమాణాలను సెట్ చేయడానికి ఇది ఒక మార్గమా లేదా ఏమిటి? మీకు ఇది ఎందుకు అవసరం? ఎందుకంటే సమీక్ష చాలా త్వరగా జరగాలి లేదా పూర్తిగా రద్దు చేయాలి. ఇది ట్రాన్స్‌బేస్ డెవలప్‌మెంట్ లాంటిది - కథ చాలా అందంగా ఉంది, కానీ పరిణతి చెందిన అబ్బాయిలకు మాత్రమే.
4 కొలమానాలకు సంబంధించి, ఇది దేనికి దారితీస్తుందో అర్థం చేసుకోవడానికి వాటిని తీసివేయమని నేను ఇప్పటికీ సిఫార్సు చేస్తున్నాను. సంఖ్యలను చూడండి, చిత్రాన్ని చూడండి, ప్రతిదీ ఎంత చెడ్డది.
(డిమిత్రి) నేను మీతో దీని గురించి చర్చకు రావడానికి సిద్ధంగా ఉన్నాను. సంఖ్యలు మరియు కొలమానాలు అన్నీ గొప్పవి, అభ్యాసాలు గొప్పవి. కానీ వ్యాపారానికి ఇది అవసరమా అని మీరు అర్థం చేసుకోవాలి. ఆ రకమైన మార్పుల వేగం అవసరం లేని వ్యాపారాలు ఉన్నాయి. ప్రతి 15 నిమిషాలకు మార్పులు చేయలేని కంపెనీలు నాకు తెలుసు. మరియు వారు చాలా చెడ్డవారు కాబట్టి కాదు. ఇది అలాంటి జీవిత చక్రం. మరియు శాఖలు ఫీచర్ చేయడానికి, టోగుల్ ఫీచర్, మీరు లోతైన జ్ఞానం అవసరం.
ఇది సంక్లిష్టమైనది. మీరు టోగుల్ ఫీచర్ గురించి కథనాన్ని మరింత వివరంగా చదవాలనుకుంటే, నేను దానిని బాగా సిఫార్సు చేస్తున్నాను . మరియు టోగుల్ ఫీచర్‌ల గురించి మార్టిన్ ఫౌలర్ అద్భుతమైన కథనం ఉంది: ఏ రకాలు ఉన్నాయి, జీవిత చక్రాలు మొదలైనవి. టోగుల్ ఫీచర్ సంక్లిష్టంగా ఉంటుంది.
మరియు మీరు ఇప్పటికీ ప్రశ్నకు సమాధానం ఇవ్వలేదు: "జెంకిన్స్ అవసరమా లేదా?"
జెంకిన్స్ నిజంగా ఏ సందర్భంలో అవసరం లేదు. తీవ్రంగా అయితే, సాధనాలు: జెంకిన్స్, గిట్లాబ్ మీకు సౌలభ్యాన్ని అందిస్తాయి. అసెంబ్లీ సమావేశమైనా లేదా సమావేశమైనా మీరు చూస్తారు. వారు మీకు సహాయం చేయగలరు, కానీ వారు మీకు అభ్యాసాన్ని ఇవ్వరు. వారు మీకు ఒక సర్కిల్ మాత్రమే ఇవ్వగలరు - సరే, సరే కాదు. ఆపై, మీరు కూడా పరీక్షలు వ్రాస్తే, పరీక్షలు లేనట్లయితే, అది దాదాపు అర్ధంలేనిది. అందువల్ల, ఇది మరింత సౌకర్యవంతంగా ఉంటుంది కాబట్టి ఇది అవసరం, కానీ సాధారణంగా మీరు లేకుండా జీవించవచ్చు, మీరు చాలా కోల్పోరు.
అంటే, మీకు అభ్యాసాలు ఉంటే, మీకు ఇది అవసరం లేదని అర్థం?
అది నిజమే. నేను జెజ్ హంబుల్ పరీక్షను సిఫార్సు చేస్తున్నాను. అక్కడ నేను చివరి పాయింట్ పట్ల సందిగ్ధ వైఖరిని కలిగి ఉన్నాను. కానీ సాధారణంగా, మీకు మూడు విషయాలు ఉంటే, మీరు నిరంతరం విలీనం అవుతారు, మీరు మాస్టర్‌లో కమిట్‌లపై పరీక్షలను అమలు చేస్తారు, మీరు మాస్టర్‌లో బిల్డ్‌ను త్వరగా పరిష్కరించండి, ఆపై మీకు మరేమీ అవసరం లేదు.
మేము పాల్గొనేవారి నుండి ప్రశ్నల కోసం ఎదురు చూస్తున్నప్పుడు, నాకు ఒక ప్రశ్న ఉంది. మేము కేవలం ఉత్పత్తి కోడ్ గురించి మాట్లాడుతున్నాము. మీరు దీన్ని ఇన్‌ఫ్రాస్ట్రక్చర్ కోడ్ కోసం ఉపయోగించారా? ఇది ఒకే కోడ్‌గా ఉందా, అదే సూత్రాలు మరియు అదే జీవిత చక్రం ఉందా లేదా విభిన్న జీవిత చక్రాలు మరియు సూత్రాలు ఉన్నాయా? సాధారణంగా, అందరూ కంటిన్యూయస్ ఇంటిగ్రేషన్ మరియు డెవలప్‌మెంట్ గురించి మాట్లాడేటప్పుడు, ఇన్‌ఫ్రాస్ట్రక్చర్ కోడ్ కూడా ఉందని అందరూ మర్చిపోతారు. మరియు ఇటీవల ఇది మరింత ఎక్కువగా ఉంది. మరి ఈ నిబంధనలన్నీ అక్కడికి తీసుకురావాలా?
అది కూడా ఉండకూడదు, ఇది చాలా బాగుంది ఎందుకంటే ఇది జీవితాన్ని అదే విధంగా సులభతరం చేస్తుంది. మేము కోడ్‌తో పని చేసిన వెంటనే, బాష్ స్క్రిప్ట్‌లతో కాదు, కానీ మనకు సాధారణ కోడ్ ఉంటుంది.
స్టాప్, స్టాప్, బాష్ స్క్రిప్ట్ కూడా కోడ్. నా పాత ప్రేమను ముట్టుకోవద్దు.
సరే, నేను నీ జ్ఞాపకాలను తుంగలో తొక్కను. నాకు బాష్ పట్ల వ్యక్తిగతంగా అయిష్టం ఉంది. ఇది అన్ని సమయాలలో అగ్లీగా మరియు భయానకంగా ఉంటుంది. మరియు ఇది తరచుగా అనూహ్యంగా విరిగిపోతుంది, అందుకే నేను దీన్ని ఇష్టపడను. అయితే సరే, మీ వద్ద బాష్ కోడ్ ఉందనుకుందాం. బహుశా నాకు నిజంగా అర్థం కాకపోవచ్చు మరియు అక్కడ సాధారణ పరీక్ష ఫ్రేమ్‌వర్క్‌లు ఉన్నాయి. నాకు తెలియదు. మరియు మేము అదే ప్రయోజనాలను పొందుతాము.
మేము ఇన్‌ఫ్రాస్ట్రక్చర్‌ని కోడ్‌గా ఉపయోగించి పని చేసిన వెంటనే, డెవలపర్‌ల వంటి సమస్యలన్నీ మనకు వస్తాయి. కొన్ని నెలల క్రితం, ఒక సహోద్యోగి నాకు బాష్‌లో 1 లైన్ల కోసం పుల్ అభ్యర్థన పంపిన పరిస్థితిని ఎదుర్కొన్నాను. మరియు మీరు 000 గంటల పాటు సమీక్షలో పాల్గొనండి. అదే సమస్యలు తలెత్తుతాయి. ఇది ఇప్పటికీ కోడ్. మరియు ఇది ఇప్పటికీ ఒక సహకారం. మేము పుల్ అభ్యర్థనతో చిక్కుకుపోతాము మరియు అదే బాష్‌లో మేము అదే విలీన వైరుధ్యాలను పరిష్కరిస్తున్నాము అనే వాస్తవంతో మేము చిక్కుకుపోతాము, ఉదాహరణకు.
నేను ఇప్పుడు అత్యంత అందమైన ఇన్‌ఫ్రా ప్రోగ్రామింగ్‌లో ఈ మొత్తం విషయాన్ని చాలా చురుకుగా చూస్తున్నాను. నేను ఇప్పుడు పులుమిని ఇన్‌ఫ్రాస్ట్రక్చర్‌లోకి తీసుకువచ్చాను. ఇది దాని స్వచ్ఛమైన రూపంలో ప్రోగ్రామింగ్. అక్కడ ఇది మరింత బాగుంది, ఎందుకంటే నేను ప్రోగ్రామింగ్ లాంగ్వేజ్ యొక్క అన్ని సామర్థ్యాలను కలిగి ఉన్నాను, అంటే నేను అదే ifsతో బ్లూ నుండి అందంగా టోగుల్ చేసాను మరియు ప్రతిదీ బాగానే ఉంది. అంటే, నా మార్పు ఇప్పటికే మాస్టర్‌లో ఉంది. అందరూ అతన్ని ఇప్పటికే చూడగలరు. ఇతర ఇంజనీర్లకు దాని గురించి తెలుసు. ఇది ఇప్పటికే అక్కడ ఏదో ప్రభావితం చేసింది. అయితే, ఇది అన్ని మౌలిక సదుపాయాల కోసం ప్రారంభించబడలేదు. ఇది నా టెస్ట్ బెంచ్‌ల కోసం ఆన్ చేయబడింది, ఉదాహరణకు. అందువల్ల, మీ ప్రశ్నకు మళ్లీ సమాధానం ఇవ్వడానికి, ఇది అవసరం. ఇది కోడ్‌తో పనిచేసే ఇంజనీర్లుగా, అదే విధంగా మాకు జీవితాన్ని సులభతరం చేస్తుంది.
ఎవరికైనా ప్రశ్నలు ఉంటే?
నాకు ఒక ప్రశ్న ఉంది. నేను ఒలేగ్‌తో చర్చను కొనసాగించాలనుకుంటున్నాను. సాధారణంగా, మీరు చెప్పింది నిజమే అని నేను అనుకుంటున్నాను, ఒక పని పూర్తి కావడానికి నెల రోజులు పడితే, మీకు వాస్తు సమస్య, విశ్లేషణ, కుళ్ళిపోవడం, ప్రణాళిక మొదలైన వాటిలో మీకు సమస్య ఉంటుంది. కానీ మీరు ప్రారంభిస్తే నాకు అనిపిస్తుంది. కంటిన్యూయస్ ఇంటిగ్రేషన్ ప్రకారం జీవించడానికి ప్రయత్నిస్తే, మీరు ప్లానింగ్‌తో నొప్పిని సరిచేయడం ప్రారంభిస్తారు, ఎందుకంటే మీరు దాని నుండి మరెక్కడా దూరంగా ఉండరు.
(ఒలేగ్) అవును, అది నిజమే. ఈ అభ్యాసం ఏదైనా ఇతర తీవ్రమైన సంస్కృతిని మార్చే అభ్యాసంతో పోల్చవచ్చు. అధిగమించడానికి కష్టతరమైన విషయం అలవాట్లు, ముఖ్యంగా చెడు అలవాట్లు. మరియు ఈ అభ్యాసాన్ని అమలు చేయడానికి, మీ చుట్టూ ఉన్నవారి అలవాట్లలో తీవ్రమైన మార్పు అవసరం అయితే: డెవలపర్లు, మేనేజ్‌మెంట్, ప్రొడక్షన్ మేనేజర్, అప్పుడు మీకు ఆశ్చర్యం కలుగుతుంది.
ఏ ఆశ్చర్యకరమైనవి ఉండవచ్చు? మీరు మరింత తరచుగా కలిసిపోవాలని నిర్ణయించుకున్నారని చెప్పండి. మరియు మీరు ఇంటిగ్రేషన్‌తో ముడిపడి ఉన్న కొన్ని ఇతర విషయాలు ఉన్నాయి, ఉదాహరణకు, కళాఖండాలు. మరియు మీ కంపెనీలో, ఉదాహరణకు, ప్రతి కళాఖండాన్ని ఏదో ఒక రకమైన ఆర్టిఫ్యాక్ట్ స్టోరేజ్ సిస్టమ్‌లో తప్పనిసరిగా లెక్కించాలనే విధానం ఉంది. మరియు దీనికి కొంత సమయం పడుతుంది. ఉత్పత్తిలో విడుదలకు సిద్ధంగా ఉందని నిర్ధారించుకోవడానికి ఒక వ్యక్తి విడుదల మేనేజర్‌గా ఈ కళాకృతిని పరీక్షించినట్లు బాక్స్‌ను తనిఖీ చేయాలి. 5-10-15 నిమిషాలు తీసుకుంటే, మీరు వారానికి ఒకసారి లేఅవుట్ చేస్తే, వారానికి ఒకసారి అరగంట ఖర్చు చేయడం చిన్న పన్ను.
మీరు కంటిన్యూయస్ ఇంటిగ్రేషన్‌ను రోజుకు 10 సార్లు చేస్తే, 10 సార్లు 30 నిమిషాలతో గుణించాలి. మరియు ఇది ఈ విడుదల మేనేజర్ యొక్క పని సమయాన్ని మించిపోయింది. అతను దీన్ని చేయడంలో అలసిపోతాడు. కొన్ని అభ్యాసాలకు స్థిర ఖర్చులు ఉన్నాయి. అంతే.
మరియు మీరు ఈ నియమాన్ని రద్దు చేయాలి, తద్వారా మీరు ఇకపై అలాంటి చెత్తను చేయలేరు, అనగా మీరు ఏదైనా దానికి అనుగుణంగా మాన్యువల్‌గా డిగ్రీని కేటాయించరు. మీరు పూర్తిగా కొన్ని స్వయంచాలక సంసిద్ధత పరీక్షలపై ఆధారపడుతున్నారు.
మరియు మీకు ఎవరి నుండి రుజువు కావాలంటే, బాస్ దానిపై సంతకం చేస్తే, మరియు అతను దానిని అనుమతించాడని వాస్య చెప్పకుండా మీరు ఉత్పత్తిలోకి రాకూడదు, మొదలైనవి - ఈ అర్ధంలేనిది అభ్యాసకుడి మార్గంలో వస్తుంది. ఎందుకంటే పన్నుతో సంబంధం ఉన్న కొన్ని కార్యకలాపాలు ఉంటే, అప్పుడు ప్రతిదీ 100 రెట్లు పెరుగుతుంది. అందువల్ల, షిఫ్ట్ తరచుగా అందరికీ ఆనందంతో స్వాగతం పలకదు. ఎందుకంటే మనుషుల అలవాట్లు మారడం కష్టం.
ఒక వ్యక్తి తన సాధారణ పనిని చేసినప్పుడు, అతను దాదాపు ఆలోచించకుండా చేస్తాడు. ఆమె అభిజ్ఞా భారం సున్నా. అతను దానితో ఆడుకుంటాడు, అతని తలలో ఇప్పటికే చెక్‌లిస్ట్ ఉంది, అతను దానిని వెయ్యి సార్లు చేసాడు. మరియు మీరు వచ్చి అతనికి చెప్పిన వెంటనే: "ఈ అభ్యాసాన్ని రద్దు చేసి, సోమవారం నుండి కొత్తదాన్ని పరిచయం చేద్దాం" అని అతనికి చెప్పండి, అది అతనికి శక్తివంతమైన అభిజ్ఞా భారంగా మారుతుంది. మరియు ఇది అందరికీ ఒకేసారి వస్తుంది.
అందువల్ల, సరళమైన విషయం ఏమిటంటే, ప్రతి ఒక్కరూ ఈ లగ్జరీని కొనుగోలు చేయలేరు, కానీ నేను ఎల్లప్పుడూ చేసేది ఇదే, ఇది క్రిందిది. కొత్త ప్రాజెక్ట్ ప్రారంభమైతే, సాధారణంగా పరీక్షించబడని అన్ని పద్ధతులు వెంటనే ఈ ప్రాజెక్ట్‌లో చిక్కుకుపోతాయి. ప్రాజెక్ట్ చిన్నది అయినప్పటికీ, మేము నిజంగా ఏదైనా రిస్క్ చేయము. ఇంకా ఉత్పత్తి లేదు, నాశనం చేయడానికి ఏమీ లేదు. అందువల్ల, దీనిని శిక్షణగా ఉపయోగించవచ్చు. ఈ విధానం పనిచేస్తుంది. కానీ అన్ని కంపెనీలకు ఇటువంటి ప్రాజెక్టులను తరచుగా ప్రారంభించే అవకాశం లేదు. ఇది కూడా కొంచెం వింతగా ఉన్నప్పటికీ, ఇప్పుడు పూర్తి డిజిటల్ రూపాంతరం ఉన్నందున, పోటీదారులతో కొనసాగడానికి ప్రతి ఒక్కరూ తప్పనిసరిగా ప్రయోగాలను ప్రారంభించాలి.
ఇక్కడ మీరు మొదట మీరు ఏమి చేయాలో అర్థం చేసుకోవాలి అనే నిర్ణయానికి వచ్చారు. ప్రపంచం ఆదర్శం కాదు, ప్రోడ్ కూడా ఆదర్శం కాదు.
అవును, ఈ విషయాలు పరస్పరం అనుసంధానించబడి ఉన్నాయి.
వ్యాపారాలు కూడా ఈ విధంగా వెళ్లాల్సిన అవసరం ఉందని ఎల్లప్పుడూ అర్థం చేసుకోలేరు.
ఎలాంటి మార్పులు చేయలేని పరిస్థితి నెలకొంది. దీంతో జట్టుపై మరింత ఒత్తిడి పెరిగే పరిస్థితి. జట్టు ఇప్పటికే చాలా కాలిపోయింది. ఆమెకు ఎలాంటి ప్రయోగాలకు ఖాళీ సమయం ఉండదు. వారు ఉదయం నుండి సాయంత్రం వరకు లక్షణాలపై పని చేస్తారు. మరియు నిర్వహణలో తక్కువ మరియు తక్కువ ఫీచర్లు ఉన్నాయి. మరింత ఎక్కువ అవసరం. అటువంటి పరిస్థితిలో, ఎటువంటి మార్పులు సాధ్యం కాదు. నిన్నటిలాగే రేపు కూడా చేస్తాం అని మాత్రమే టీమ్‌కి చెప్పగలం, మనం కొంచెం ఎక్కువ ఫీచర్లు చేస్తే చాలు. ఈ కోణంలో, ఏ అభ్యాసాలకు ఎటువంటి పరివర్తనాలు సాధ్యం కాదు. గొడ్డలికి పదును పెట్టడానికి సమయం లేనప్పుడు ఇది ఒక క్లాసిక్ పరిస్థితి, చెట్లను నరికివేయాలి, కాబట్టి వారు దానిని నిస్తేజంగా గొడ్డలితో కత్తిరించారు. ఇక్కడ సాధారణ చిట్కాలు లేవు.
(డిమిత్రి) నేను చాట్ నుండి ఒక వివరణను చదువుతాను: “కానీ మాకు వివిధ స్థాయిలలో చాలా పరీక్ష కవరేజ్ అవసరం. పరీక్షలకు ఎంత సమయం కేటాయించారు? ఇది కొంచెం ఖరీదైనది మరియు చాలా సమయం పడుతుంది."
(ఒలేగ్) ఇది ఒక క్లాసిక్ దురభిప్రాయం. మీరు నమ్మకంగా ఉండటానికి తగినంత పరీక్షలు ఉండాలి. నిరంతర ఏకీకరణ అనేది 100% పరీక్షలు ముందుగా పూర్తి చేయబడిన విషయం కాదు మరియు మీరు ఈ అభ్యాసాన్ని వర్తింపజేయడం ప్రారంభించండి. కంటిన్యూయస్ ఇంటిగ్రేషన్ అనేది మీ కళ్లతో మీరు చూసే ప్రతి మార్పులు చాలా స్పష్టంగా ఉండడం వల్ల, పరీక్షలు లేకుండా కూడా ఏదైనా విచ్ఛిన్నం అవుతుందా లేదా అని మీరు అర్థం చేసుకోగలగడం వల్ల మీ అభిజ్ఞా భారాన్ని తగ్గిస్తుంది. మార్పులు చిన్నవిగా ఉన్నందున మీరు దీన్ని మీ తలపై త్వరగా పరీక్షించవచ్చు. మీరు మాన్యువల్ టెస్టర్‌లను మాత్రమే కలిగి ఉన్నప్పటికీ, వారికి కూడా ఇది సులభం. మీరు బయటకు వెళ్లి ఇలా అన్నారు: "చూడండి, ఏదైనా విరిగిపోయిందా?" వారు తనిఖీ చేసి, "లేదు, ఏమీ విరిగిపోలేదు." ఎందుకంటే టెస్టర్‌కు ఎక్కడ చూడాలో తెలుసు. మీరు ఒక కోడ్ ముక్కతో అనుబంధించబడిన ఒక నిబద్ధతను కలిగి ఉన్నారు. మరియు ఇది నిర్దిష్ట ప్రవర్తన ద్వారా దోపిడీ చేయబడుతుంది.
ఇక్కడ మీరు, కోర్సు యొక్క, అలంకరించబడిన.
(డిమిత్రి) నేను ఇక్కడ అంగీకరించను. ఒక అభ్యాసం ఉంది - పరీక్ష ఆధారిత అభివృద్ధి, దీని నుండి మిమ్మల్ని కాపాడుతుంది.
(ఒలేగ్) సరే, నేను ఇంకా ఆ స్థితికి చేరుకోలేదు. మొదటి భ్రమ ఏమిటంటే, మీరు 100% పరీక్షలు రాయాలి లేదా మీరు నిరంతర ఇంటిగ్రేషన్ చేయవలసిన అవసరం లేదు. ఇది నిజం కాదు. ఇవి రెండు సమాంతర పద్ధతులు. మరియు అవి నేరుగా ఆధారపడి ఉండవు. మీ పరీక్ష కవరేజ్ సరైనదిగా ఉండాలి. ఆప్టిమల్ - కమిట్ అయిన తర్వాత మీ మాస్టర్ మిగిలి ఉన్న మాస్టర్ యొక్క నాణ్యత శుక్రవారం సాయంత్రం తాగిన మత్తులో “డిప్లాయ్” బటన్‌ను నమ్మకంగా నొక్కడానికి మిమ్మల్ని అనుమతిస్తుంది అని మీకు మీరే నమ్మకం ఉందని దీని అర్థం. మీరు దీన్ని ఎలా సాధిస్తారు? సమీక్ష ద్వారా, కవరేజ్ ద్వారా, మంచి పర్యవేక్షణ ద్వారా.
మంచి పర్యవేక్షణ పరీక్షల నుండి వేరు చేయలేనిది. మీరు ప్రీ ప్రోడ్‌లో ఒకసారి పరీక్షలను అమలు చేస్తే, వారు మీ అన్ని వినియోగదారు స్క్రిప్ట్‌లను ఒకసారి తనిఖీ చేస్తారు మరియు అంతే. మరియు మీరు వాటిని అంతులేని లూప్‌లో అమలు చేస్తే, ఇది మీ మోహరించిన మానిటరింగ్ సిస్టమ్, ఇది క్రాష్ అయినా కాకపోయినా అన్నింటినీ అనంతంగా పరీక్షిస్తుంది. ఈ సందర్భంలో, ఇది ఒకటి లేదా రెండుసార్లు చేసినా మాత్రమే తేడా. చాలా మంచి పరీక్షల సెట్... అనంతంగా నడుస్తోంది, ఇది పర్యవేక్షణ. మరియు సరైన పర్యవేక్షణ ఇలా ఉండాలి.
అందువల్ల, మీరు శుక్రవారం సాయంత్రం సిద్ధమై ఇంటికి వెళ్ళినప్పుడు మీరు ఈ స్థితిని ఎలా సాధిస్తారు అనేది మరొక ప్రశ్న. బహుశా మీరు ఒక బోల్డ్ స్కాంబాగ్.
కంటిన్యూయస్ ఇంటిగ్రేషన్‌కి కొంచెం వెనక్కి వెళ్దాం. మేము కొంచెం భిన్నమైన సంక్లిష్టమైన అభ్యాసంలోకి పారిపోయాము.
మరియు రెండవ భ్రమ ఏమిటంటే, MVP, వారు చెప్పేది, త్వరగా చేయవలసి ఉంటుంది, కాబట్టి అక్కడ పరీక్షలు అవసరం లేదు. ఖచ్చితంగా ఆ విధంగా కాదు. వాస్తవం ఏమిటంటే, మీరు MVPలో వినియోగదారు కథనాన్ని వ్రాసినప్పుడు, మీరు దానిని బంతిపై అభివృద్ధి చేయవచ్చు, అనగా, ఒక రకమైన వినియోగదారు కథనం ఉందని మీరు విన్నారు మరియు వెంటనే దానిని కోడ్ చేయడానికి పరిగెత్తారు లేదా మీరు TDDని ఉపయోగించి పని చేయవచ్చు. మరియు TDD ప్రకారం, ఆచరణలో చూపినట్లుగా, ఇది ఎక్కువ సమయం తీసుకోదు, అంటే పరీక్షలు ఒక దుష్ప్రభావం. TDD యొక్క అభ్యాసం పరీక్ష గురించి కాదు. టెస్ట్ డ్రైవెన్ డెవలప్‌మెంట్ అని పిలువబడినప్పటికీ, ఇది పరీక్షల గురించి కాదు. ఇది కూడా ఒక నిర్మాణ విధానం. ఇది సరిగ్గా అవసరమైనది రాయడం మరియు అవసరం లేనిది రాయడం అనే విధానం. ఇది అప్లికేషన్ ఆర్కిటెక్చర్‌ను రూపొందించే విషయంలో మీ ఆలోచన యొక్క తదుపరి పునరావృతంపై దృష్టి సారించే అభ్యాసం.
అందువల్ల, ఈ భ్రమలను వదిలించుకోవడం అంత సులభం కాదు. MVP మరియు పరీక్షలు ఒకదానికొకటి విరుద్ధంగా లేవు. దీనికి విరుద్ధంగా, మీరు TDD ప్రాక్టీస్‌ని ఉపయోగించి MVP చేస్తే, మీరు దీన్ని అస్సలు ప్రాక్టీస్ చేయకుండా చేయడం కంటే మెరుగ్గా మరియు వేగంగా చేస్తారు, కానీ బంతిపై.
ఇది చాలా స్పష్టమైన మరియు సంక్లిష్టమైన ఆలోచన. ఇప్పుడు నేను మరిన్ని పరీక్షలు వ్రాస్తాను మరియు అదే సమయంలో నేను వేగంగా ఏదైనా చేస్తాను అని మీరు విన్నప్పుడు, అది పూర్తిగా సరిపోదు.
(డిమిత్రి) ఇక్కడ చాలా మంది, వారు MVP అని పిలిచినప్పుడు, ప్రజలు సాధారణమైనదాన్ని వ్రాయడానికి చాలా సోమరిపోతారు. మరియు ఇవి ఇప్పటికీ భిన్నమైన విషయాలు. MVPని పని చేయని కొన్ని చెడ్డ వస్తువుగా మార్చాల్సిన అవసరం లేదు.
అవును, అవును, మీరు చెప్పింది నిజమే.
ఆపై అకస్మాత్తుగా ఉత్పత్తిలో MVP.
ఎప్పటికీ.
మరియు మీరు పరీక్షలు వ్రాస్తారని మరియు ఎక్కువ పని చేస్తున్నట్లు మీరు విన్నప్పుడు TDD చాలా అసాధారణంగా అనిపిస్తుంది. ఇది చాలా వింతగా అనిపిస్తుంది, కానీ వాస్తవానికి ఇది ఈ విధంగా వేగంగా మరియు అందంగా మారుతుంది. మీరు పరీక్ష వ్రాసేటప్పుడు, ఏ కోడ్‌ని పిలవాలి మరియు ఎలా పిలుస్తారు, అలాగే దాని నుండి మనం ఏ ప్రవర్తనను ఆశిస్తున్నాము అనే దాని గురించి మీరు ఇప్పటికే మీ తలపై చాలా ఆలోచిస్తారు. నేను కొన్ని ఫంక్షన్ వ్రాసాను మరియు అది ఏదో చేస్తుంది అని మీరు చెప్పరు. ఆమెకు అలాంటి పరిస్థితులు ఉన్నాయని మొదట మీరు అనుకున్నారు, ఆమెను అలా మరియు అలాంటి విధంగా పిలుస్తారు. మీరు దీన్ని పరీక్షలతో కవర్ చేస్తారు మరియు మీ కోడ్‌లో మీ ఇంటర్‌ఫేస్‌లు ఎలా కనిపిస్తాయో దీని నుండి మీరు అర్థం చేసుకుంటారు. ఇది వాస్తుశిల్పంపై చాలా ప్రభావం చూపుతుంది. మీ కోడ్ స్వయంచాలకంగా మరింత మాడ్యులర్ అవుతుంది, ఎందుకంటే మీరు దీన్ని ఎలా పరీక్షిస్తారో అర్థం చేసుకోవడానికి ప్రయత్నించండి, ఆపై మాత్రమే వ్రాయండి.
TDDతో నాకు ఏమి జరిగిందంటే, నేను రూబీ ప్రోగ్రామర్‌గా ఉన్నప్పుడు ఏదో ఒక సమయంలో రూబీ మెంటార్‌ని నియమించుకున్నాను. మరియు అతను ఇలా అన్నాడు: "TDD ప్రకారం చేద్దాం." నేను ఇలా అనుకున్నాను: "పాపం, ఇప్పుడు నేను అదనంగా ఏదైనా వ్రాయాలి." మరియు మేము రెండు వారాల్లో TDDని ఉపయోగించి పైథాన్‌లో అన్ని వర్కింగ్ కోడ్‌లను వ్రాస్తానని అంగీకరించాము. రెండు వారాల తర్వాత, నేను తిరిగి వెళ్లకూడదని గ్రహించాను. దీన్ని ప్రతిచోటా వర్తింపజేయడానికి రెండు వారాల పాటు ప్రయత్నించిన తర్వాత, మీరు ఆలోచించడం కూడా ఎంత సులభమైందో మీకు అర్థమవుతుంది. కానీ ఇది స్పష్టంగా లేదు, కాబట్టి TDD కష్టతరమైనది, సమయం తీసుకుంటుంది మరియు అనవసరమైనది అనే భావన మీకు ఉంటే, కేవలం రెండు వారాల పాటు దానితో కట్టుబడి ప్రయత్నించండి అని నేను అందరికీ సిఫార్సు చేస్తున్నాను. నాకు రెండు సరిపోతాయి.
(డిమిత్రి) మేము ఈ ఆలోచనను ఇన్‌ఫ్రాస్ట్రక్చర్ ఆపరేషన్ కోణం నుండి విస్తరించవచ్చు. మేము ఏదైనా కొత్తదాన్ని ప్రారంభించే ముందు, మేము మానిటరింగ్ చేసి, ఆపై ప్రారంభించాము. ఈ సందర్భంలో, పర్యవేక్షణ మాకు సాధారణ పరీక్ష అవుతుంది. మరియు పర్యవేక్షణ ద్వారా అభివృద్ధి ఉంది. కానీ దాదాపు ప్రతి ఒక్కరూ ఇది చాలా పొడవుగా ఉందని, నేను సోమరిగా ఉన్నాను, నేను తాత్కాలిక డ్రాఫ్ట్ చేసాను. మేము సాధారణ పర్యవేక్షణ చేసి ఉంటే, మేము CI సిస్టమ్ స్థితిని అర్థం చేసుకుంటాము. మరియు CI వ్యవస్థకు చాలా పర్యవేక్షణ ఉంది. మేము వ్యవస్థ యొక్క స్థితిని అర్థం చేసుకున్నాము, దాని లోపల ఏమి ఉందో మేము అర్థం చేసుకున్నాము. మరియు అభివృద్ధి సమయంలో, మేము వ్యవస్థను తయారు చేస్తున్నాము, తద్వారా అది కావలసిన స్థితికి చేరుకుంటుంది.
ఈ పద్ధతులు చాలా కాలంగా ప్రసిద్ది చెందాయి. మేము 4 సంవత్సరాల క్రితం దీని గురించి చర్చించాము. కానీ 4 సంవత్సరాలలో ఆచరణాత్మకంగా ఏమీ మారలేదు.
కానీ ఈ గమనికపై, నేను అధికారిక చర్చను ముగించాలని ప్రతిపాదిస్తున్నాను.
వీడియో (మీడియా మూలకం వలె చొప్పించబడింది, కానీ కొన్ని కారణాల వలన పని చేయదు):
మూలం: www.habr.com