నేడు, చాలా సాఫ్ట్‌వేర్ ఉత్పత్తులు బృందాలుగా అభివృద్ధి చేయబడ్డాయి. విజయవంతమైన జట్టు అభివృద్ధికి పరిస్థితులు సాధారణ రేఖాచిత్రం రూపంలో సూచించబడతాయి.

మీరు మీ కోడ్‌ని వ్రాసిన తర్వాత, మీరు దీన్ని నిర్ధారించుకోవాలి:

1. Работает.
2. ఇది మీ సహోద్యోగులు వ్రాసిన కోడ్‌తో సహా దేనినీ విచ్ఛిన్నం చేయదు.

రెండు షరతులు నెరవేరినట్లయితే, మీరు విజయానికి మార్గంలో ఉన్నారు. ఈ పరిస్థితులను సులభంగా తనిఖీ చేయడానికి మరియు లాభదాయకమైన మార్గం నుండి వైదొలగకుండా ఉండటానికి, మేము నిరంతర ఏకీకరణతో ముందుకు వచ్చాము.

CI అనేది వర్క్‌ఫ్లో, మీరు మీ కోడ్‌ని మొత్తం ఉత్పత్తి కోడ్‌లో వీలైనంత తరచుగా ఏకీకృతం చేస్తారు. మరియు మీరు ఏకీకృతం చేయరు, కానీ ప్రతిదీ పని చేస్తుందో లేదో నిరంతరం తనిఖీ చేయండి. మీరు చాలా మరియు తరచుగా తనిఖీ చేయవలసి ఉన్నందున, ఇది ఆటోమేషన్ గురించి ఆలోచించడం విలువ. మీరు అన్నింటినీ మాన్యువల్‌గా తనిఖీ చేయవచ్చు, కానీ మీరు చేయకూడదు, మరియు ఇక్కడ ఎందుకు ఉంది.

• ప్రియమైన ప్రజలారా. ఏదైనా ప్రోగ్రామర్ యొక్క ఒక గంట పని ఏదైనా సర్వర్ యొక్క ఒక గంట పని కంటే ఖరీదైనది.
• ప్రజలు తప్పులు చేస్తారు. అందువల్ల, పరీక్షలు తప్పు బ్రాంచ్‌లో అమలు చేయబడినప్పుడు లేదా పరీక్షకులకు తప్పు కమిట్ చేయబడినప్పుడు పరిస్థితులు తలెత్తవచ్చు.
• ప్రజలు సోమరిపోతులు. ఎప్పటికప్పుడు, నేను ఒక పనిని పూర్తి చేసినప్పుడు, ఆలోచన పుడుతుంది: “చెక్ చేయడానికి ఏమి ఉంది? నేను రెండు పంక్తులు వ్రాసాను - ప్రతిదీ పని చేస్తుంది! మీలో కొందరికి కూడా కొన్నిసార్లు అలాంటి ఆలోచనలు ఉంటాయని నేను అనుకుంటున్నాను. కానీ మీరు ఎల్లప్పుడూ తనిఖీ చేయాలి.

అవిటో మొబైల్ డెవలప్‌మెంట్ టీమ్‌లో కంటిన్యూయస్ ఇంటిగ్రేషన్ ఎలా అమలు చేయబడింది మరియు అభివృద్ధి చేయబడింది, అవి రోజుకు 0 నుండి 450 బిల్డ్‌ల వరకు ఎలా సాగాయి మరియు ఆ బిల్డ్ మెషీన్లు రోజుకు 200 గంటలు సమావేశమవుతాయని నికోలాయ్ నెస్టెరోవ్ చెప్పారు (న్నెస్టెరోవ్) CI/CD ఆండ్రాయిడ్ అప్లికేషన్ యొక్క అన్ని పరిణామాత్మక మార్పులలో భాగస్వామి.

కథనం Android కమాండ్ యొక్క ఉదాహరణపై ఆధారపడి ఉంటుంది, అయితే చాలా విధానాలు iOSలో కూడా వర్తిస్తాయి.

ఒకప్పుడు, అవిటో ఆండ్రాయిడ్ టీమ్‌లో ఒక వ్యక్తి పనిచేశాడు. నిర్వచనం ప్రకారం, అతనికి నిరంతర ఏకీకరణ నుండి ఏమీ అవసరం లేదు: ఏకీకృతం చేయడానికి ఎవరూ లేరు.

కానీ అప్లికేషన్ పెరిగింది, మరిన్ని కొత్త పనులు కనిపించాయి మరియు తదనుగుణంగా బృందం పెరిగింది. ఏదో ఒక సమయంలో, కోడ్ ఇంటిగ్రేషన్ ప్రక్రియను మరింత అధికారికంగా ఏర్పాటు చేయడానికి ఇది సమయం. Git ఫ్లోను ఉపయోగించాలని నిర్ణయించారు.

Git ఫ్లో యొక్క భావన బాగా తెలుసు: ఒక ప్రాజెక్ట్‌కు ఒక సాధారణ అభివృద్ధి శాఖ ఉంటుంది మరియు ప్రతి కొత్త ఫీచర్ కోసం, డెవలపర్‌లు ఒక ప్రత్యేక శాఖను కట్ చేసి, దానికి కట్టుబడి, పుష్ చేసి, వారు తమ కోడ్‌ను అభివృద్ధి శాఖలో విలీనం చేయాలనుకున్నప్పుడు, తెరవండి అభ్యర్థనను లాగండి. జ్ఞానాన్ని పంచుకోవడానికి మరియు విధానాలను చర్చించడానికి, మేము కోడ్ సమీక్షను పరిచయం చేసాము, అంటే సహోద్యోగులు ఒకరి కోడ్‌ను మరొకరు తనిఖీ చేసి నిర్ధారించుకోవాలి.

తనిఖీలు

మీ కళ్ళతో కోడ్‌ని చూడటం చాలా బాగుంది, కానీ సరిపోదు. అందువల్ల, ఆటోమేటిక్ తనిఖీలను ప్రవేశపెడుతున్నారు.

• అన్నింటిలో మొదటిది, మేము తనిఖీ చేస్తాము ARK అసెంబ్లీ.
• చాలా జూనిట్ పరీక్షలు.
• మేము కోడ్ కవరేజీని పరిశీలిస్తాము, మేము పరీక్షలను అమలు చేస్తున్నందున.

ఈ తనిఖీలను ఎలా అమలు చేయాలో అర్థం చేసుకోవడానికి, Avitoలో అభివృద్ధి ప్రక్రియను చూద్దాం.

దీనిని క్రమపద్ధతిలో ఇలా సూచించవచ్చు:

• డెవలపర్ తన ల్యాప్‌టాప్‌లో కోడ్‌ను వ్రాస్తాడు. మీరు ఇక్కడే ఇంటిగ్రేషన్ తనిఖీలను అమలు చేయవచ్చు - కమిట్ హుక్‌తో లేదా నేపథ్యంలో తనిఖీలను అమలు చేయండి.
• డెవలపర్ కోడ్‌ను పుష్ చేసిన తర్వాత, అతను పుల్ అభ్యర్థనను తెరుస్తాడు. దాని కోడ్ డెవలప్ బ్రాంచ్‌లో చేర్చబడాలంటే, కోడ్ రివ్యూ ద్వారా వెళ్లి అవసరమైన నిర్ధారణల సంఖ్యను సేకరించడం అవసరం. మీరు ఇక్కడ తనిఖీలు మరియు బిల్డ్‌లను ప్రారంభించవచ్చు: అన్ని బిల్డ్‌లు విజయవంతమయ్యే వరకు, పుల్ అభ్యర్థన విలీనం చేయబడదు.
• పుల్ అభ్యర్థన విలీనం చేయబడిన తర్వాత మరియు డెవలప్‌లో కోడ్ చేర్చబడిన తర్వాత, మీరు అనుకూలమైన సమయాన్ని ఎంచుకోవచ్చు: ఉదాహరణకు, రాత్రి సమయంలో, అన్ని సర్వర్‌లు ఖాళీగా ఉన్నప్పుడు మరియు మీకు నచ్చినన్ని తనిఖీలను అమలు చేయండి.

వారి ల్యాప్‌టాప్‌లో స్కాన్‌లను అమలు చేయడం ఎవరికీ నచ్చలేదు. డెవలపర్ ఒక లక్షణాన్ని పూర్తి చేసిన తర్వాత, అతను దానిని త్వరగా పుష్ చేసి, పుల్ రిక్వెస్ట్‌ను తెరవాలనుకుంటున్నాడు. ఈ సమయంలో కొన్ని దీర్ఘ తనిఖీలు ప్రారంభించబడితే, ఇది చాలా ఆహ్లాదకరమైనది కాదు, కానీ అభివృద్ధిని కూడా తగ్గిస్తుంది: ల్యాప్టాప్ ఏదో తనిఖీ చేస్తున్నప్పుడు, దానిపై సాధారణంగా పని చేయడం అసాధ్యం.

మేము రాత్రిపూట తనిఖీలను అమలు చేయడం నిజంగా ఇష్టపడ్డాము, ఎందుకంటే చాలా సమయం మరియు సర్వర్లు ఉన్నాయి, మీరు చుట్టూ తిరగవచ్చు. కానీ, దురదృష్టవశాత్తు, ఫీచర్ కోడ్ అభివృద్ధిలోకి వచ్చినప్పుడు, CI కనుగొన్న లోపాలను పరిష్కరించడానికి డెవలపర్‌కు చాలా తక్కువ ప్రేరణ ఉంటుంది. మార్నింగ్ రిపోర్ట్‌లో కనిపించిన అన్ని లోపాలను నేను క్రమానుగతంగా చూసినప్పుడు నేను వాటిని ఏదో ఒక రోజు తర్వాత సరిచేస్తానని ఆలోచిస్తున్నాను, ఎందుకంటే ఇప్పుడు జిరాలో నేను చేయాలనుకుంటున్న కొత్త పని ఉంది.

చెక్‌లు పుల్ రిక్వెస్ట్‌ను బ్లాక్ చేస్తే, తగినంత ప్రేరణ ఉంటుంది, ఎందుకంటే బిల్డ్‌లు ఆకుపచ్చగా మారే వరకు, కోడ్ అభివృద్ధిలోకి రాదు, అంటే పని పూర్తి చేయబడదు.

ఫలితంగా, మేము క్రింది వ్యూహాన్ని ఎంచుకున్నాము: మేము రాత్రిపూట గరిష్టంగా సాధ్యమయ్యే చెక్‌ల సెట్‌ను అమలు చేస్తాము మరియు వాటిలో అత్యంత క్లిష్టమైన వాటిని మరియు, ముఖ్యంగా, పుల్ అభ్యర్థనపై వేగవంతమైన వాటిని ప్రారంభిస్తాము. కానీ మేము అక్కడ ఆగము-సమాంతరంగా, మేము చెక్‌ల వేగాన్ని ఆప్టిమైజ్ చేస్తాము, తద్వారా అభ్యర్థన తనిఖీలను లాగడానికి వాటిని నైట్ మోడ్ నుండి బదిలీ చేస్తాము.

ఆ సమయంలో, మా బిల్డ్‌లన్నీ చాలా త్వరగా పూర్తయ్యాయి, కాబట్టి మేము పుల్ అభ్యర్థన కోసం బ్లాకర్‌గా ARK బిల్డ్, జూనిట్ పరీక్షలు మరియు కోడ్ కవరేజ్ లెక్కలను చేర్చాము. మేము దానిని ఆన్ చేసాము, దాని గురించి ఆలోచించాము మరియు కోడ్ కవరేజీని వదిలివేసాము ఎందుకంటే ఇది మాకు అవసరం లేదని మేము భావించాము.

ప్రాథమిక CIని పూర్తిగా సెటప్ చేయడానికి మాకు రెండు రోజులు పట్టింది (ఇకపై సమయం అంచనా సుమారుగా ఉంటుంది, స్కేల్‌కి అవసరం).

ఆ తరువాత, మేము మరింత ఆలోచించడం ప్రారంభించాము - మేము సరిగ్గా తనిఖీ చేస్తున్నామా? మేము పుల్ రిక్వెస్ట్‌లపై బిల్డ్‌లను సరిగ్గా అమలు చేస్తున్నామా?

మేము పుల్ అభ్యర్థన తెరవబడిన బ్రాంచ్ యొక్క చివరి కమిట్‌పై నిర్మాణాన్ని ప్రారంభించాము. కానీ ఈ కమిట్ యొక్క పరీక్షలు డెవలపర్ వ్రాసిన కోడ్ పనిచేస్తుందని మాత్రమే చూపుతుంది. కానీ అతను ఏమీ విచ్ఛిన్నం చేయలేదని వారు నిరూపించరు. నిజానికి, మీరు డెవలప్‌ బ్రాంచ్‌లో ఫీచర్‌ని విలీనం చేసిన తర్వాత దాని స్థితిని తనిఖీ చేయాలి.

దీన్ని చేయడానికి, మేము సాధారణ బాష్ స్క్రిప్ట్‌ను వ్రాసాము premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

ఇక్కడ అభివృద్ధి నుండి అన్ని తాజా మార్పులు కేవలం పైకి లాగి, ప్రస్తుత శాఖలో విలీనం చేయబడతాయి. మేము అన్ని బిల్డ్‌లలో మొదటి దశగా premerge.sh స్క్రిప్ట్‌ని జోడించాము మరియు మనకు ఏమి కావాలో సరిగ్గా తనిఖీ చేయడం ప్రారంభించాము, అంటే అనుసంధానం.

సమస్యను స్థానికీకరించి, పరిష్కారాన్ని కనుగొని, ఈ స్క్రిప్ట్ రాయడానికి మూడు రోజులు పట్టింది.

అప్లికేషన్ అభివృద్ధి చేయబడింది, మరిన్ని పనులు కనిపించాయి, బృందం పెరిగింది మరియు premerge.sh కొన్నిసార్లు మమ్మల్ని నిరాశపరచడం ప్రారంభించింది. డెవలప్‌లో బిల్డ్‌ను విచ్ఛిన్నం చేసే విరుద్ధమైన మార్పులు ఉన్నాయి.

ఇది ఎలా జరుగుతుందో ఉదాహరణ:

ఇద్దరు డెవలపర్‌లు ఏకకాలంలో A మరియు B లక్షణాలపై పని చేయడం ప్రారంభిస్తారు. ఫీచర్ A యొక్క డెవలపర్ ప్రాజెక్ట్‌లో ఉపయోగించని లక్షణాన్ని కనుగొంటారు answer() మరియు, ఒక మంచి బాలుడు స్కౌట్ వలె, దానిని తీసివేస్తాడు. అదే సమయంలో, ఫీచర్ B యొక్క డెవలపర్ తన బ్రాంచ్‌లో ఈ ఫంక్షన్‌కి కొత్త కాల్‌ని జోడిస్తుంది.

డెవలపర్‌లు తమ పనిని పూర్తి చేసి, అదే సమయంలో పుల్ అభ్యర్థనను తెరుస్తారు. బిల్డ్‌లు ప్రారంభించబడ్డాయి, తాజా అభివృద్ధి స్థితికి సంబంధించి రెండు పుల్ అభ్యర్థనలను premerge.sh తనిఖీ చేస్తుంది - అన్ని చెక్‌లు ఆకుపచ్చగా ఉన్నాయి. ఆ తర్వాత, ఫీచర్ A యొక్క పుల్ అభ్యర్థన విలీనం చేయబడింది, ఫీచర్ B యొక్క పుల్ అభ్యర్థన విలీనం చేయబడింది... బూమ్! డెవలప్ కోడ్ ఉనికిలో లేని ఫంక్షన్‌కు కాల్‌ని కలిగి ఉన్నందున విరామాలను అభివృద్ధి చేయండి.

అది అభివృద్ధి చెందనప్పుడు, అది స్థానిక విపత్తు. మొత్తం బృందం ఏదైనా సేకరించి పరీక్ష కోసం సమర్పించలేరు.

నేను చాలా తరచుగా మౌలిక సదుపాయాల పనులపై పని చేస్తాను: విశ్లేషణలు, నెట్‌వర్క్, డేటాబేస్‌లు. అంటే, ఇతర డెవలపర్‌లు ఉపయోగించే ఆ ఫంక్షన్‌లు మరియు తరగతులను నేనే వ్రాసాను. ఈ కారణంగా, నేను చాలా తరచుగా ఇలాంటి పరిస్థితుల్లో నన్ను కనుగొన్నాను. నేను కూడా ఈ చిత్రాన్ని కొంతకాలం వేలాడదీశాను.

ఇది మాకు సరిపోదు కాబట్టి, దీన్ని ఎలా నిరోధించాలనే దానిపై మేము ఎంపికలను అన్వేషించడం ప్రారంభించాము.

అభివృద్ధిని ఎలా విచ్ఛిన్నం చేయకూడదు

మొదటి ఎంపిక: అభివృద్ధిని నవీకరించేటప్పుడు అన్ని పుల్ అభ్యర్థనలను పునర్నిర్మించండి. మా ఉదాహరణలో, డెవలప్‌లో A ఫీచర్‌తో పుల్ అభ్యర్థన మొదట చేర్చబడినట్లయితే, ఫీచర్ B యొక్క పుల్ అభ్యర్థన పునర్నిర్మించబడుతుంది మరియు తదనుగుణంగా, సంకలన లోపం కారణంగా తనిఖీలు విఫలమవుతాయి.

దీనికి ఎంత సమయం పడుతుందో అర్థం చేసుకోవడానికి, రెండు PRలతో ఒక ఉదాహరణను పరిగణించండి. మేము రెండు PRలను తెరుస్తాము: రెండు నిర్మాణాలు, రెండు పరుగుల తనిఖీలు. మొదటి PR అభివృద్ధిలో విలీనం అయిన తర్వాత, రెండవది పునర్నిర్మించబడాలి. మొత్తంగా, రెండు PRలకు మూడు పరుగుల తనిఖీలు అవసరం: 2 + 1 = 3.

సూత్రప్రాయంగా, ఇది మంచిది. కానీ మేము గణాంకాలను పరిశీలించాము మరియు మా బృందంలో సాధారణ పరిస్థితి 10 ఓపెన్ PRలు, ఆపై చెక్‌ల సంఖ్య పురోగతి యొక్క మొత్తం: 10 + 9 +... + 1 = 55. అంటే, 10ని అంగీకరించడం PRలు, మీరు 55 సార్లు పునర్నిర్మించవలసి ఉంటుంది. మరియు ఈ డజను ప్రాసెస్ చేస్తున్నప్పుడు ఎవరూ అదనపు పుల్ అభ్యర్థనను తెరవనప్పుడు, అన్ని తనిఖీలు మొదటిసారిగా పాస్ అయినప్పుడు, ఇది ఆదర్శవంతమైన పరిస్థితిలో ఉంటుంది.

“విలీనం” బటన్‌పై మొదట క్లిక్ చేయాల్సిన డెవలపర్‌గా మిమ్మల్ని మీరు ఊహించుకోండి, ఎందుకంటే పొరుగువారు ఇలా చేస్తే, అన్ని బిల్డ్‌లు మళ్లీ పూర్తయ్యే వరకు మీరు వేచి ఉండాలి... లేదు, అది పని చేయదు , ఇది అభివృద్ధిని తీవ్రంగా నెమ్మదిస్తుంది.

రెండవ సాధ్యం మార్గం: కోడ్ సమీక్ష తర్వాత పుల్ అభ్యర్థనలను సేకరించండి. అంటే, మీరు పుల్ అభ్యర్థనను తెరిచి, సహోద్యోగుల నుండి అవసరమైన సంఖ్యలో ఆమోదాలను సేకరించి, అవసరమైన వాటిని సరిచేసి, ఆపై బిల్డ్‌లను ప్రారంభించండి. అవి విజయవంతమైతే, పుల్ అభ్యర్థన అభివృద్ధిలో విలీనం చేయబడుతుంది. ఈ సందర్భంలో, అదనపు పునఃప్రారంభాలు లేవు, కానీ అభిప్రాయం బాగా మందగిస్తుంది. డెవలపర్‌గా, నేను పుల్ అభ్యర్థనను తెరిచినప్పుడు, అది పని చేస్తుందో లేదో వెంటనే చూడాలనుకుంటున్నాను. ఉదాహరణకు, ఒక పరీక్ష విఫలమైతే, మీరు దాన్ని త్వరగా పరిష్కరించాలి. ఆలస్యమైన బిల్డ్ విషయంలో, ఫీడ్‌బ్యాక్ నెమ్మదిస్తుంది మరియు అందువల్ల మొత్తం అభివృద్ధి. ఇది కూడా మాకు సరిపోలేదు.

ఫలితంగా, మూడవ ఎంపిక మాత్రమే మిగిలి ఉంది - బైక్. మా కోడ్ మొత్తం, మా మూలాలన్నీ బిట్‌బకెట్ సర్వర్‌లోని రిపోజిటరీలో నిల్వ చేయబడతాయి. దీని ప్రకారం, మేము Bitbucket కోసం ఒక ప్లగిన్‌ను అభివృద్ధి చేయాల్సి వచ్చింది.

ఈ ప్లగ్ఇన్ పుల్ రిక్వెస్ట్ మెర్జింగ్ మెకానిజంను ఓవర్‌రైడ్ చేస్తుంది. ప్రారంభం ప్రామాణికం: PR తెరుచుకుంటుంది, అన్ని సమావేశాలు ప్రారంభించబడ్డాయి, కోడ్ సమీక్ష పూర్తయింది. కానీ కోడ్ సమీక్ష పూర్తయిన తర్వాత మరియు డెవలపర్ "విలీనం"పై క్లిక్ చేయాలని నిర్ణయించుకున్న తర్వాత, చెక్‌లు అమలు చేయబడే అభివృద్ధి స్థితికి వ్యతిరేకంగా ప్లగ్ఇన్ తనిఖీ చేస్తుంది. బిల్డ్‌ల తర్వాత డెవలప్‌ని అప్‌డేట్ చేసినట్లయితే, అటువంటి పుల్ అభ్యర్థనను ప్రధాన శాఖలో విలీనం చేయడానికి ప్లగ్ఇన్ అనుమతించదు. ఇది సాపేక్షంగా ఇటీవలి అభివృద్ధి యొక్క నిర్మాణాలను పునఃప్రారంభిస్తుంది.

విరుద్ధమైన మార్పులతో మా ఉదాహరణలో, అటువంటి బిల్డ్‌లు కంపైలేషన్ లోపం కారణంగా విఫలమవుతాయి. దీని ప్రకారం, ఫీచర్ B యొక్క డెవలపర్ కోడ్‌ని సరిచేయాలి, తనిఖీలను పునఃప్రారంభించాలి, ఆపై ప్లగ్ఇన్ స్వయంచాలకంగా పుల్ అభ్యర్థనను వర్తింపజేస్తుంది.

ఈ ప్లగ్‌ఇన్‌ని అమలు చేయడానికి ముందు, మేము ఒక పుల్ అభ్యర్థనకు సగటున 2,7 సమీక్ష రన్‌లను చేసాము. ప్లగిన్‌తో 3,6 లాంచ్‌లు ఉన్నాయి. ఇది మాకు సరిపోయింది.

ఈ ప్లగ్‌ఇన్‌లో లోపం ఉందని గమనించాలి: ఇది బిల్డ్‌ను ఒకసారి మాత్రమే పునఃప్రారంభిస్తుంది. అంటే, ఇప్పటికీ ఒక చిన్న విండో ఉంది, దీని ద్వారా విరుద్ధమైన మార్పులు అభివృద్ధి చెందుతాయి. కానీ దీని సంభావ్యత తక్కువగా ఉంది మరియు మేము ప్రారంభాల సంఖ్య మరియు వైఫల్యం సంభావ్యత మధ్య ఈ ట్రేడ్-ఆఫ్ చేసాము. రెండు సంవత్సరాలలో అది ఒక్కసారి మాత్రమే కాల్పులు జరిపింది, కాబట్టి అది ఫలించలేదు.

Bitbucket ప్లగ్ఇన్ యొక్క మొదటి సంస్కరణను వ్రాయడానికి మాకు రెండు వారాలు పట్టింది.

కొత్త చెక్కులు

ఇంతలో, మా బృందం పెరుగుతూనే ఉంది. కొత్త చెక్కులు జోడించబడ్డాయి.

మేము ఆలోచించాము: వాటిని నిరోధించగలిగితే తప్పులు ఎందుకు చేయాలి? మరియు వారు అమలు ఎందుకు స్టాటిక్ కోడ్ విశ్లేషణ. మేము ఆండ్రాయిడ్ SDKలో చేర్చబడిన లింట్‌తో ప్రారంభించాము. కానీ ఆ సమయంలో అతనికి కోట్లిన్ కోడ్‌తో ఎలా పని చేయాలో తెలియదు మరియు మేము ఇప్పటికే కోట్లిన్‌లో వ్రాసిన అప్లికేషన్‌లో 75% కలిగి ఉన్నాము. అందువల్ల, అంతర్నిర్మిత వాటిని మెత్తటికి జోడించారు ఆండ్రాయిడ్ స్టూడియో తనిఖీలు.

దీన్ని చేయడానికి, మేము చాలా వక్రీకరణలు చేయాల్సి వచ్చింది: ఆండ్రాయిడ్ స్టూడియోని తీసుకోండి, దాన్ని డాకర్‌లో ప్యాక్ చేయండి మరియు వర్చువల్ మానిటర్‌తో CIలో రన్ చేయండి, తద్వారా ఇది నిజమైన ల్యాప్‌టాప్‌లో రన్ అవుతుందని భావిస్తుంది. కానీ అది పనిచేసింది.

ఈ సమయంలోనే మేము చాలా రాయడం ప్రారంభించాము ఇన్స్ట్రుమెంటేషన్ పరీక్షలు మరియు అమలు చేయబడింది స్క్రీన్‌షాట్ పరీక్ష. ప్రత్యేక చిన్న వీక్షణ కోసం రిఫరెన్స్ స్క్రీన్‌షాట్ రూపొందించబడినప్పుడు ఇది జరుగుతుంది మరియు పరీక్షలో వీక్షణ నుండి స్క్రీన్‌షాట్ తీసుకోవడం మరియు దానిని స్టాండర్డ్ డైరెక్ట్ పిక్సెల్ పిక్సెల్‌తో పోల్చడం ఉంటుంది. ఏదైనా వ్యత్యాసం ఉంటే, లేఅవుట్ ఎక్కడో తప్పుగా ఉందని లేదా స్టైల్స్‌లో ఏదో తప్పు జరిగిందని అర్థం.

కానీ ఇన్‌స్ట్రుమెంటేషన్ పరీక్షలు మరియు స్క్రీన్‌షాట్ పరీక్షలను పరికరాల్లో అమలు చేయాలి: ఎమ్యులేటర్‌లలో లేదా నిజమైన పరికరాల్లో. పరీక్షలు చాలా ఉన్నాయి మరియు అవి తరచుగా అమలు చేయబడతాయని పరిగణనలోకి తీసుకుంటే, మొత్తం పొలం అవసరం. మీ స్వంత వ్యవసాయ క్షేత్రాన్ని ప్రారంభించడం చాలా శ్రమతో కూడుకున్నది, కాబట్టి మేము రెడీమేడ్ ఎంపికను కనుగొన్నాము - Firebase Test Lab.

ఫైర్‌బేస్ టెస్ట్ ల్యాబ్

Firebase అనేది Google ఉత్పత్తి అయినందున ఇది ఎంచుకోబడింది, అంటే ఇది నమ్మదగినది మరియు ఎప్పటికీ చనిపోయే అవకాశం ఉండదు. ధరలు సహేతుకమైనవి: నిజమైన పరికరం యొక్క ఆపరేషన్ గంటకు $5, ఎమ్యులేటర్ యొక్క ఆపరేషన్ గంటకు 1 $.

ఫైర్‌బేస్ టెస్ట్ ల్యాబ్‌ను మా CIలో అమలు చేయడానికి సుమారు మూడు వారాలు పట్టింది.

కానీ జట్టు పెరుగుతూనే ఉంది మరియు ఫైర్‌బేస్, దురదృష్టవశాత్తు, మమ్మల్ని నిరాశపరచడం ప్రారంభించింది. ఆ సమయంలో, అతనికి ఎటువంటి SLA లేదు. కొన్నిసార్లు ఫైర్‌బేస్ పరీక్షల కోసం అవసరమైన పరికరాల సంఖ్య ఉచితం అయ్యే వరకు వేచి ఉండేలా చేసింది మరియు మేము కోరుకున్నట్లుగా వాటిని వెంటనే అమలు చేయడం ప్రారంభించలేదు. లైన్‌లో వేచి ఉండటానికి అరగంట వరకు పట్టింది, ఇది చాలా ఎక్కువ సమయం. ప్రతి PRలో ఇన్‌స్ట్రుమెంటేషన్ పరీక్షలు నిర్వహించబడ్డాయి, జాప్యాలు నిజంగా అభివృద్ధిని మందగించాయి, ఆపై నెలవారీ బిల్లు రౌండ్ మొత్తంతో వచ్చింది. సాధారణంగా, టీమ్ తగినంతగా పెరిగినందున, ఫైర్‌బేస్‌ని విడిచిపెట్టి, ఇంట్లోనే పని చేయాలని నిర్ణయించారు.

డాకర్ + పైథాన్ + బాష్

మేము డాకర్‌ని తీసుకున్నాము, దానిలో ఎమ్యులేటర్‌లను నింపాము, పైథాన్‌లో ఒక సాధారణ ప్రోగ్రామ్‌ను వ్రాసాము, ఇది సరైన సమయంలో సరైన సంస్కరణలో అవసరమైన సంఖ్యలో ఎమ్యులేటర్‌లను ప్రారంభిస్తుంది మరియు అవసరమైనప్పుడు వాటిని ఆపివేస్తుంది. మరియు, వాస్తవానికి, రెండు బాష్ స్క్రిప్ట్‌లు - అవి లేకుండా మనం ఎక్కడ ఉంటాం?

మా స్వంత పరీక్ష వాతావరణాన్ని సృష్టించడానికి ఐదు వారాలు పట్టింది.

ఫలితంగా, ప్రతి పుల్ అభ్యర్థన కోసం తనిఖీల యొక్క విస్తృతమైన విలీన-నిరోధిత జాబితా ఉంది:

• ARK అసెంబ్లీ;
• జూనిట్ పరీక్షలు;
• లింట్;
• Android స్టూడియో తనిఖీలు;
• ఇన్స్ట్రుమెంటేషన్ పరీక్షలు;
• స్క్రీన్‌షాట్ పరీక్షలు.

ఇది అనేక సాధ్యం విచ్ఛిన్నాలను నిరోధించింది. సాంకేతికంగా ప్రతిదీ పని చేసింది, కానీ డెవలపర్లు ఫలితాల కోసం నిరీక్షణ చాలా పొడవుగా ఉందని ఫిర్యాదు చేశారు.

చాలా పొడవు ఎంత? మేము Bitbucket మరియు TeamCity నుండి డేటాను విశ్లేషణ సిస్టమ్‌లోకి అప్‌లోడ్ చేసాము మరియు దానిని గ్రహించాము సగటు నిరీక్షణ సమయం 45 నిమిషాలు. అంటే, డెవలపర్, పుల్ అభ్యర్థనను తెరిచేటప్పుడు, బిల్డ్ ఫలితాల కోసం సగటున 45 నిమిషాలు వేచి ఉంటాడు. నా అభిప్రాయం ప్రకారం, ఇది చాలా ఉంది మరియు మీరు అలా పని చేయలేరు.

వాస్తవానికి, మేము మా నిర్మాణాలన్నింటినీ వేగవంతం చేయాలని నిర్ణయించుకున్నాము.

వేగం పెంచుదాం

బిల్డ్‌లు తరచుగా క్యూలో నిలబడటం చూసి, మనం చేసే మొదటి పని మరింత హార్డ్‌వేర్‌ను కొనుగోలు చేసింది - విస్తృతమైన అభివృద్ధి సరళమైనది. బిల్డ్‌లు క్యూలో నిలబడటం ఆగిపోయింది, కానీ వేచి ఉండే సమయం కొద్దిగా తగ్గింది, ఎందుకంటే కొన్ని తనిఖీలు చాలా ఎక్కువ సమయం తీసుకున్నాయి.

చాలా సమయం పట్టే చెక్కులను తీసివేయడం

మా నిరంతర ఏకీకరణ ఈ రకమైన లోపాలు మరియు సమస్యలను పట్టుకోగలదు.

• వెళ్ళడం లేదు. విరుద్ధమైన మార్పుల కారణంగా ఏదైనా నిర్మించనప్పుడు CI సంకలన లోపాన్ని గుర్తించగలదు. నేను ఇప్పటికే చెప్పినట్లుగా, అప్పుడు ఎవరూ దేనినీ సమీకరించలేరు, అభివృద్ధి ఆగిపోతుంది మరియు ప్రతి ఒక్కరూ భయపడతారు.
• ప్రవర్తనలో బగ్. ఉదాహరణకు, అప్లికేషన్ నిర్మించబడినప్పుడు, కానీ మీరు బటన్‌ను నొక్కినప్పుడు క్రాష్ అవుతుంది లేదా బటన్ అస్సలు నొక్కబడనప్పుడు. ఇది చెడ్డది ఎందుకంటే అటువంటి బగ్ వినియోగదారుని చేరవచ్చు.
• లేఅవుట్‌లో బగ్. ఉదాహరణకు, ఒక బటన్ క్లిక్ చేయబడింది, కానీ 10 పిక్సెల్‌లను ఎడమవైపుకు తరలించింది.
• సాంకేతిక రుణాల పెరుగుదల.

ఈ జాబితాను చూసిన తర్వాత, మొదటి రెండు పాయింట్లు మాత్రమే క్లిష్టమైనవని మేము గ్రహించాము. ఇలాంటి సమస్యలను ముందుగా పట్టుకోవాలని అనుకుంటున్నాం. లేఅవుట్‌లోని బగ్‌లు డిజైన్-రివ్యూ దశలో కనుగొనబడతాయి మరియు వాటిని సులభంగా సరిదిద్దవచ్చు. సాంకేతిక రుణంతో వ్యవహరించడానికి ప్రత్యేక ప్రక్రియ మరియు ప్రణాళిక అవసరం, కాబట్టి మేము దానిని పుల్ అభ్యర్థనపై పరీక్షించకూడదని నిర్ణయించుకున్నాము.

ఈ వర్గీకరణ ఆధారంగా, మేము చెక్‌ల మొత్తం జాబితాను కదిలించాము. లింట్‌ను దాటింది మరియు దాని ప్రారంభాన్ని రాత్రిపూట వాయిదా వేసింది: ప్రాజెక్ట్‌లో ఎన్ని సమస్యలు ఉన్నాయో నివేదికను రూపొందించడం కోసం. మేము సాంకేతిక రుణంతో విడిగా పనిచేయడానికి అంగీకరించాము మరియు ఆండ్రాయిడ్ స్టూడియో తనిఖీలు పూర్తిగా వదిలివేయబడ్డాయి. రన్నింగ్ ఇన్‌స్పెక్షన్‌ల కోసం డాకర్‌లోని ఆండ్రాయిడ్ స్టూడియో ఆసక్తికరంగా అనిపిస్తుంది, కానీ సపోర్ట్‌లో చాలా ఇబ్బందిని కలిగిస్తుంది. ఆండ్రాయిడ్ స్టూడియో సంస్కరణలకు ఏదైనా అప్‌డేట్ అంటే అపారమయిన బగ్‌లతో పోరాటం. స్క్రీన్‌షాట్ పరీక్షలకు మద్దతు ఇవ్వడం కూడా కష్టం, ఎందుకంటే లైబ్రరీ చాలా స్థిరంగా లేదు మరియు తప్పుడు పాజిటివ్‌లు ఉన్నాయి. చెక్ లిస్ట్ నుండి స్క్రీన్‌షాట్ పరీక్షలు తీసివేయబడ్డాయి.

ఫలితంగా, మాకు మిగిలింది:

• ARK అసెంబ్లీ;
• జూనిట్ పరీక్షలు;
• ఇన్స్ట్రుమెంటేషన్ పరీక్షలు.

గ్రాడిల్ రిమోట్ కాష్

భారీ తనిఖీలు లేకుండా, ప్రతిదీ మెరుగుపడింది. కానీ పరిపూర్ణతకు పరిమితి లేదు!

మా అప్లికేషన్ ఇప్పటికే దాదాపు 150 గ్రాడిల్ మాడ్యూల్‌లుగా విభజించబడింది. గ్రాడిల్ రిమోట్ కాష్ సాధారణంగా ఈ సందర్భంలో బాగా పని చేస్తుంది, కాబట్టి మేము దీన్ని ప్రయత్నించాలని నిర్ణయించుకున్నాము.

గ్రేడిల్ రిమోట్ కాష్ అనేది వ్యక్తిగత మాడ్యూల్స్‌లో వ్యక్తిగత పనుల కోసం కళాఖండాలను కాష్ చేయగల సేవ. Gradle, వాస్తవానికి కోడ్‌ను కంపైల్ చేయడానికి బదులుగా, రిమోట్ కాష్‌ని కొట్టడానికి HTTPని ఉపయోగిస్తుంది మరియు ఎవరైనా ఇప్పటికే ఈ పనిని నిర్వహించారా అని అడగండి. అవును అయితే, అది కేవలం ఫలితాన్ని డౌన్‌లోడ్ చేస్తుంది.

Gradle ఒక డాకర్ చిత్రాన్ని అందిస్తుంది కాబట్టి Gradle రిమోట్ కాష్‌ని అమలు చేయడం సులభం. మేము దీన్ని మూడు గంటల్లో చేయగలిగాము.

మీరు చేయాల్సిందల్లా డాకర్‌ని ప్రారంభించి, ప్రాజెక్ట్‌లో ఒక లైన్ రాయడం. ఇది త్వరగా ప్రారంభించబడినప్పటికీ, ప్రతిదీ సరిగ్గా పనిచేయడానికి చాలా సమయం పడుతుంది.

క్రింద కాష్ మిస్స్ గ్రాఫ్ ఉంది.

చాలా ప్రారంభంలో, కాష్ మిస్‌ల శాతం దాదాపు 65. మూడు వారాల తర్వాత, మేము ఈ విలువను 20%కి పెంచగలిగాము. ఆండ్రాయిడ్ అప్లికేషన్ సేకరించే టాస్క్‌లు విచిత్రమైన ట్రాన్సిటివ్ డిపెండెన్సీలను కలిగి ఉన్నాయని తేలింది, దీని కారణంగా గ్రాడిల్ కాష్‌ను కోల్పోయింది.

కాష్‌ని కనెక్ట్ చేయడం ద్వారా, మేము బిల్డ్‌ను బాగా వేగవంతం చేసాము. కానీ అసెంబ్లీకి అదనంగా, ఇన్స్ట్రుమెంటేషన్ పరీక్షలు కూడా ఉన్నాయి, మరియు అవి చాలా సమయం పడుతుంది. ప్రతి పుల్ అభ్యర్థన కోసం బహుశా అన్ని పరీక్షలను అమలు చేయవలసిన అవసరం లేదు. తెలుసుకోవడానికి, మేము ప్రభావ విశ్లేషణను ఉపయోగిస్తాము.

ప్రభావ విశ్లేషణ

పుల్ అభ్యర్థనపై, మేము git diffని సేకరిస్తాము మరియు సవరించిన Gradle మాడ్యూల్‌లను కనుగొంటాము.

మార్చబడిన మాడ్యూల్‌లను మరియు వాటిపై ఆధారపడిన అన్ని మాడ్యూల్‌లను తనిఖీ చేసే ఇన్‌స్ట్రుమెంటేషన్ పరీక్షలను మాత్రమే అమలు చేయడం అర్ధమే. పొరుగు మాడ్యూల్స్ కోసం పరీక్షలను అమలు చేయడంలో ఎటువంటి పాయింట్ లేదు: అక్కడ కోడ్ మారలేదు మరియు ఏమీ విచ్ఛిన్నం కాదు.

ఇన్‌స్ట్రుమెంటేషన్ పరీక్షలు అంత సులభం కాదు, ఎందుకంటే అవి తప్పనిసరిగా టాప్-లెవల్ అప్లికేషన్ మాడ్యూల్‌లో ఉండాలి. ప్రతి పరీక్ష ఏ మాడ్యూల్‌కు చెందినదో అర్థం చేసుకోవడానికి మేము బైట్‌కోడ్ విశ్లేషణతో హ్యూరిస్టిక్‌లను ఉపయోగించాము.

ఇన్‌స్ట్రుమెంటేషన్ పరీక్షల ఆపరేషన్‌ను అప్‌గ్రేడ్ చేయడం వలన అవి ప్రమేయం ఉన్న మాడ్యూల్‌లను మాత్రమే పరీక్షించడానికి దాదాపు ఎనిమిది వారాలు పట్టింది.

తనిఖీలను వేగవంతం చేసే చర్యలు విజయవంతంగా పనిచేశాయి. 45 నిమిషాల నుండి మేము దాదాపు 15కి చేరుకున్నాము. బిల్డ్ కోసం పావుగంట వేచి ఉండటం ఇప్పటికే సాధారణం.

కానీ ఇప్పుడు డెవలపర్లు ఏ బిల్డ్‌లు ప్రారంభించబడుతున్నాయో అర్థం కావడం లేదని, లాగ్‌ను ఎక్కడ చూడాలి, బిల్డ్ ఎందుకు ఎరుపుగా ఉంది, ఏ పరీక్ష విఫలమైంది మొదలైనవి తమకు అర్థం కావడం లేదని ఫిర్యాదు చేయడం ప్రారంభించారు.

అభిప్రాయంతో సమస్యలు అభివృద్ధిని నెమ్మదిస్తాయి, కాబట్టి మేము ప్రతి PR గురించి స్పష్టమైన మరియు వివరణాత్మక సమాచారాన్ని అందించడానికి మరియు వీలైనంతగా నిర్మించడానికి ప్రయత్నించాము. మేము బిట్‌బకెట్‌లో PRకి వ్యాఖ్యలతో ప్రారంభించాము, ఏ బిల్డ్ విఫలమైంది మరియు ఎందుకు విఫలమైంది మరియు స్లాక్‌లో లక్ష్య సందేశాలను వ్రాసాము. చివరికి, మేము ప్రస్తుతం అమలవుతున్న అన్ని బిల్డ్‌ల జాబితాతో మరియు వాటి స్థితితో పేజీ కోసం PR డ్యాష్‌బోర్డ్‌ను సృష్టించాము: క్యూలో, నడుస్తున్న, క్రాష్ లేదా పూర్తయిన. మీరు బిల్డ్‌పై క్లిక్ చేసి, దాని లాగ్‌ను పొందవచ్చు.

వివరణాత్మక అభిప్రాయం కోసం ఆరు వారాలు గడిపారు.

ప్రణాళికలు

ఇటీవలి చరిత్రకు వెళ్దాం. ఫీడ్‌బ్యాక్ సమస్యను పరిష్కరించిన తర్వాత, మేము కొత్త స్థాయికి చేరుకున్నాము - మేము మా స్వంత ఎమ్యులేటర్ ఫారమ్‌ను నిర్మించాలని నిర్ణయించుకున్నాము. అనేక పరీక్షలు మరియు ఎమ్యులేటర్లు ఉన్నప్పుడు, వాటిని నిర్వహించడం కష్టం. ఫలితంగా, మా ఎమ్యులేటర్‌లన్నీ ఫ్లెక్సిబుల్ రిసోర్స్ మేనేజ్‌మెంట్‌తో k8s క్లస్టర్‌కి మారాయి.

అదనంగా, ఇతర ప్రణాళికలు ఉన్నాయి.

• రిటర్న్ లింట్ (మరియు ఇతర స్టాటిక్ విశ్లేషణ). మేము ఇప్పటికే ఈ దిశలో పని చేస్తున్నాము.
• PR బ్లాకర్‌లో ప్రతిదీ అమలు చేయండి ఎండ్-టు-ఎండ్ పరీక్షలు అన్ని SDK సంస్కరణల్లో.

కాబట్టి, అవిటోలో నిరంతర ఏకీకరణ అభివృద్ధి చరిత్రను మేము గుర్తించాము. ఇప్పుడు నేను అనుభవజ్ఞుడైన దృక్కోణం నుండి కొన్ని సలహాలు ఇవ్వాలనుకుంటున్నాను.

చిట్కాలు

నేను ఒక్క సలహా మాత్రమే ఇవ్వగలిగితే అది ఇలా ఉంటుంది:

దయచేసి షెల్ స్క్రిప్ట్‌లతో జాగ్రత్తగా ఉండండి!

బాష్ చాలా సౌకర్యవంతమైన మరియు శక్తివంతమైన సాధనం, ఇది స్క్రిప్ట్‌లను వ్రాయడానికి చాలా సౌకర్యవంతంగా మరియు వేగంగా ఉంటుంది. కానీ మీరు దానితో ఒక ఉచ్చులో పడవచ్చు మరియు, దురదృష్టవశాత్తు, మేము దానిలో పడిపోయాము.

ఇదంతా మా బిల్డ్ మెషీన్‌లలో నడిచే సాధారణ స్క్రిప్ట్‌లతో ప్రారంభమైంది:

#!/usr/bin/env bash
./gradlew assembleDebug

కానీ, మీకు తెలిసినట్లుగా, ప్రతిదీ అభివృద్ధి చెందుతుంది మరియు కాలక్రమేణా మరింత క్లిష్టంగా మారుతుంది - ఒక స్క్రిప్ట్‌ను మరొకదాని నుండి అమలు చేద్దాం, అక్కడ కొన్ని పారామితులను పాస్ చేద్దాం - చివరికి మనం ఇప్పుడు ఏ స్థాయిలో బాష్ గూడులో ఉన్నామో నిర్ణయించే ఫంక్షన్‌ను వ్రాయవలసి వచ్చింది. అవసరమైన కోట్‌లను ఇన్సర్ట్ చేయడానికి, అన్నింటినీ ప్రారంభించడానికి.

అటువంటి స్క్రిప్ట్‌ల అభివృద్ధికి కార్మిక వ్యయాలను మీరు ఊహించవచ్చు. ఈ ఉచ్చులో పడవద్దని నేను మీకు సలహా ఇస్తున్నాను.

ఏమి భర్తీ చేయవచ్చు?

• ఏదైనా స్క్రిప్టింగ్ భాష. కు వ్రాయండి పైథాన్ లేదా కోట్లిన్ స్క్రిప్ట్ ఇది ప్రోగ్రామింగ్, స్క్రిప్ట్‌లు కాదు కాబట్టి మరింత సౌకర్యవంతంగా ఉంటుంది.
• లేదా రూపంలో అన్ని బిల్డ్ లాజిక్‌లను వివరించండి కస్టమ్ గ్రేడిల్ టాస్క్‌లు మీ ప్రాజెక్ట్ కోసం.

మేము రెండవ ఎంపికను ఎంచుకోవాలని నిర్ణయించుకున్నాము మరియు ఇప్పుడు మేము అన్ని బాష్ స్క్రిప్ట్‌లను క్రమపద్ధతిలో తొలగిస్తున్నాము మరియు చాలా కస్టమ్ గ్రాడిల్ టాస్క్‌లను వ్రాస్తున్నాము.

చిట్కా #2: కోడ్‌లో మౌలిక సదుపాయాలను నిల్వ చేయండి.

నిరంతర ఇంటిగ్రేషన్ సెట్టింగ్ Jenkins లేదా TeamCity మొదలైన UI ఇంటర్‌ఫేస్‌లో కాకుండా నేరుగా ప్రాజెక్ట్ రిపోజిటరీలో టెక్స్ట్ ఫైల్‌ల రూపంలో నిల్వ చేయబడినప్పుడు ఇది సౌకర్యవంతంగా ఉంటుంది. ఇది సంస్కరణను ఇస్తుంది. మరొక బ్రాంచ్‌లో కోడ్‌ను రోల్‌బ్యాక్ చేయడం లేదా బిల్డ్ చేయడం కష్టం కాదు.

స్క్రిప్ట్‌లను ప్రాజెక్ట్‌లో నిల్వ చేయవచ్చు. పర్యావరణంతో ఏమి చేయాలి?

చిట్కా #3: డాకర్ పర్యావరణానికి సహాయం చేయవచ్చు.

ఇది ఖచ్చితంగా Android డెవలపర్‌లకు సహాయం చేస్తుంది; దురదృష్టవశాత్తూ iOSకి ఇంకా ఒకటి లేదు.

ఇది jdk మరియు android-sdkని కలిగి ఉన్న సాధారణ డాకర్ ఫైల్‌కి ఉదాహరణ:

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

ఈ డాకర్ ఫైల్‌ను వ్రాసిన తర్వాత (నేను మీకు ఒక రహస్యం చెబుతాను, మీరు దీన్ని వ్రాయవలసిన అవసరం లేదు, కానీ దానిని GitHub నుండి రెడీమేడ్‌గా లాగండి) మరియు చిత్రాన్ని సమీకరించిన తర్వాత, మీరు అప్లికేషన్‌ను రూపొందించగల వర్చువల్ మెషీన్‌ను పొందుతారు. మరియు జూనిట్ పరీక్షలను అమలు చేయండి.

ఇది అర్ధవంతం కావడానికి రెండు ప్రధాన కారణాలు స్కేలబిలిటీ మరియు రిపీటబిలిటీ. డాకర్‌ని ఉపయోగించి, మీరు డజను బిల్డ్ ఏజెంట్‌లను త్వరగా పెంచుకోవచ్చు, అవి మునుపటి వాతావరణాన్ని కలిగి ఉంటాయి. ఇది CI ఇంజనీర్ల జీవితాన్ని చాలా సులభం చేస్తుంది. Android-sdkని డాకర్‌లోకి నెట్టడం చాలా సులభం, కానీ ఎమ్యులేటర్‌లతో ఇది కొంచెం కష్టం: మీరు కొంచెం కష్టపడాలి (లేదా పూర్తయిన దాన్ని మళ్లీ GitHub నుండి డౌన్‌లోడ్ చేసుకోండి).

చిట్కా నం. 4: తనిఖీలు తనిఖీల కోసం జరగవని, ప్రజల కోసం అని మర్చిపోవద్దు.

త్వరిత మరియు, ముఖ్యంగా, డెవలపర్‌లకు స్పష్టమైన అభిప్రాయం చాలా ముఖ్యం: ఏది విరిగింది, ఏ పరీక్ష విఫలమైంది, నేను బిల్డ్‌లాగ్‌ని ఎక్కడ చూడగలను.

చిట్కా #5: నిరంతర ఏకీకరణను అభివృద్ధి చేస్తున్నప్పుడు ఆచరణాత్మకంగా ఉండండి.

మీరు ఏ రకమైన లోపాలను నిరోధించాలనుకుంటున్నారు, ఎంత వనరులు, సమయం మరియు కంప్యూటర్ సమయాన్ని వెచ్చించాలనుకుంటున్నారో స్పష్టంగా అర్థం చేసుకోండి. ఉదాహరణకు, ఎక్కువ సమయం పట్టే తనిఖీలను రాత్రిపూట వాయిదా వేయవచ్చు. మరియు వాటిలో చాలా ముఖ్యమైన లోపాలు లేని వాటిని పూర్తిగా వదిలివేయాలి.

చిట్కా #6: రెడీమేడ్ టూల్స్ ఉపయోగించండి.

క్లౌడ్ CIని అందించే అనేక కంపెనీలు ఇప్పుడు ఉన్నాయి.

చిన్న జట్లకు ఇది మంచి పరిష్కారం. మీరు దేనికీ మద్దతు ఇవ్వాల్సిన అవసరం లేదు, కొంచెం డబ్బు చెల్లించండి, మీ అప్లికేషన్‌ను రూపొందించండి మరియు ఇన్‌స్ట్రుమెంటేషన్ పరీక్షలను కూడా అమలు చేయండి.

చిట్కా #7: పెద్ద బృందంలో, అంతర్గత పరిష్కారాలు మరింత లాభదాయకంగా ఉంటాయి.

కానీ ముందుగానే లేదా తరువాత, జట్టు పెరుగుతున్న కొద్దీ, అంతర్గత పరిష్కారాలు మరింత లాభదాయకంగా మారతాయి. ఈ నిర్ణయాలలో ఒక సమస్య ఉంది. ఆర్థిక శాస్త్రంలో రాబడిని తగ్గించే చట్టం ఉంది: ఏదైనా ప్రాజెక్ట్‌లో, ప్రతి తదుపరి మెరుగుదల మరింత కష్టతరమైనది మరియు మరింత ఎక్కువ పెట్టుబడి అవసరం.

ఎకనామిక్స్ నిరంతర ఏకీకరణతో సహా మన మొత్తం జీవితాన్ని వివరిస్తుంది. నేను మా నిరంతర ఏకీకరణ యొక్క ప్రతి దశ అభివృద్ధి కోసం కార్మిక ఖర్చుల షెడ్యూల్‌ను రూపొందించాను.

ఏదైనా మెరుగుదల మరింత కష్టతరంగా మారుతున్నట్లు స్పష్టమవుతుంది. ఈ గ్రాఫ్‌ను చూస్తే, జట్టు పరిమాణం పెరుగుదలకు అనుగుణంగా నిరంతర ఇంటిగ్రేషన్‌ను అభివృద్ధి చేయాల్సిన అవసరం ఉందని మీరు అర్థం చేసుకోవచ్చు. ఇద్దరు వ్యక్తుల బృందం కోసం, అంతర్గత ఎమ్యులేటర్ ఫారమ్‌ను అభివృద్ధి చేయడానికి 50 రోజులు గడపడం అనేది ఒక సాధారణ ఆలోచన. కానీ అదే సమయంలో, ఒక పెద్ద జట్టు కోసం, నిరంతర ఇంటిగ్రేషన్ చేయకపోవడం కూడా చెడ్డ ఆలోచన, ఎందుకంటే ఇంటిగ్రేషన్ సమస్యలు, కమ్యూనికేషన్ ఫిక్సింగ్ మొదలైనవి. దానికి ఇంకా ఎక్కువ సమయం పడుతుంది.

ప్రజలు ఖరీదైనవి, తప్పులు చేస్తారు మరియు సోమరితనం ఉన్నందున ఆటోమేషన్ అవసరం అనే ఆలోచనతో మేము ప్రారంభించాము. కానీ ప్రజలు కూడా ఆటోమేట్ చేస్తారు. అందువలన, అన్ని అదే సమస్యలు ఆటోమేషన్ వర్తిస్తాయి.

• ఆటోమేషన్ ఖరీదైనది. కార్మిక షెడ్యూల్‌ను గుర్తుంచుకోండి.
• ఆటోమేషన్ విషయానికి వస్తే, ప్రజలు తప్పులు చేస్తారు.
• కొన్నిసార్లు ఇది ఆటోమేట్ చేయడానికి చాలా సోమరితనం, ఎందుకంటే ప్రతిదీ ఆ విధంగా పనిచేస్తుంది. మరేదైనా మెరుగుపరచడం ఎందుకు, ఈ నిరంతర ఏకీకరణ ఎందుకు?

కానీ నా దగ్గర గణాంకాలు ఉన్నాయి: 20% అసెంబ్లీలలో లోపాలు పట్టుబడ్డాయి. మరియు మా డెవలపర్లు కోడ్ పేలవంగా వ్రాయడం దీనికి కారణం కాదు. ఎందుకంటే డెవలపర్లు ఏదైనా పొరపాటు చేస్తే, అది డెవలప్‌లో ముగియదని, ఆటోమేటెడ్ చెక్‌ల ద్వారా పట్టుబడుతుందని నమ్మకంగా ఉన్నారు. దీని ప్రకారం, డెవలపర్లు స్థానికంగా ఏదైనా అమలు చేయడం మరియు పరీక్షించడం కంటే కోడ్ మరియు ఆసక్తికరమైన విషయాలను వ్రాయడానికి ఎక్కువ సమయాన్ని వెచ్చిస్తారు.

నిరంతర ఏకీకరణను ప్రాక్టీస్ చేయండి. కానీ మితంగా.

మార్గం ద్వారా, నికోలాయ్ నెస్టెరోవ్ స్వయంగా గొప్ప నివేదికలు ఇవ్వడమే కాకుండా, ప్రోగ్రామ్ కమిటీ సభ్యుడు కూడా AppsConf మరియు మీ కోసం అర్థవంతమైన ప్రసంగాలను సిద్ధం చేయడంలో ఇతరులకు సహాయపడుతుంది. తదుపరి సమావేశ కార్యక్రమం యొక్క సంపూర్ణత మరియు ఉపయోగాన్ని అంశాల ద్వారా అంచనా వేయవచ్చు షెడ్యూల్. మరియు వివరాల కోసం, ఏప్రిల్ 22-23 తేదీలలో ఇన్ఫోస్పేస్‌కు రండి.

మూలం: www.habr.com