අද බොහෝ මෘදුකාංග නිෂ්පාදන කණ්ඩායම් වශයෙන් සංවර්ධනය කර ඇත. සාර්ථක කණ්ඩායම් සංවර්ධනය සඳහා කොන්දේසි සරල රූප සටහනක් ආකාරයෙන් නිරූපණය කළ හැකිය.

ඔබ ඔබේ කේතය ලිවූ පසු, ඔබ එය සහතික කර ගත යුතුය:

1. .
2. එය ඔබේ සගයන් ලියූ කේතය ඇතුළුව කිසිවක් බිඳ නොදමති.

කොන්දේසි දෙකම සපුරා ඇත්නම්, ඔබ සාර්ථකත්වයේ මාවතේ ය. මෙම තත්ත්වයන් පහසුවෙන් පරීක්ෂා කිරීමට සහ ලාභදායි මාර්ගයෙන් බැහැර නොවීමට, අපි අඛණ්ඩ ඒකාබද්ධතාවය ඉදිරිපත් කළෙමු.

CI යනු ඔබ ඔබේ කේතය හැකි සෑම විටම සමස්ත නිෂ්පාදන කේතයට ඒකාබද්ධ කරන කාර්ය ප්‍රවාහයකි. තවද ඔබ ඒකාබද්ධ කිරීම පමණක් නොව, සෑම දෙයක්ම ක්රියා කරන බව නිරන්තරයෙන් පරීක්ෂා කරන්න. ඔබ බොහෝ විට සහ බොහෝ විට පරීක්ෂා කිරීමට අවශ්ය බැවින්, එය ස්වයංක්රීයකරණය ගැන සිතීම වටී. ඔබට සියල්ල අතින් පරීක්ෂා කළ හැකිය, නමුත් ඔබ නොකළ යුතු අතර, ඒ මන්ද යන්නයි.

• ආදරණීය ජනතාවනි. ඕනෑම ක්‍රමලේඛකයෙකුගේ වැඩ පැයක් ඕනෑම සේවාදායකයක වැඩ කරන පැයකට වඩා මිල අධිකය.
• මිනිස්සු වැරදි කරනවා. එමනිසා, පරීක්ෂණ වැරදි ශාඛාවක් මත ධාවනය වූ විට හෝ පරීක්ෂකයින් සඳහා වැරදි කැපවීමක් සම්පාදනය කළ විට තත්වයන් පැන නැගිය හැක.
• මිනිස්සු කම්මැලියි. වරින් වර, මම කාර්යයක් අවසන් කරන විට, සිතුවිල්ල පැන නගී: “පරීක්ෂා කිරීමට ඇත්තේ කුමක්ද? මම පේළි දෙකක් ලිව්වා - හැම දෙයක්ම වැඩ කරනවා! මම හිතන්නේ ඔබලාගෙන් සමහරෙකුට ද සමහර විට එවැනි සිතුවිලි ඇති වේ. නමුත් ඔබ නිතරම පරීක්ෂා කළ යුතුය.

Avito ජංගම සංවර්ධන කණ්ඩායම තුළ අඛණ්ඩ ඒකාබද්ධතාවය ක්‍රියාත්මක කර සංවර්ධනය කරන ලද ආකාරය, ඔවුන් දිනකට ගොඩනැගීම් 0 සිට 450 දක්වා ගිය ආකාරය සහ යන්ත්‍ර දිනකට පැය 200 ක් එකලස් කරන ආකාරය, Nikolai Nesterov පවසයි (nnesterov) යනු CI/CD ඇන්ඩ්‍රොයිඩ් යෙදුමේ සියලුම පරිණාමීය වෙනස්කම් සඳහා සහභාගී වන්නෙකි.

කතාව Android විධානයක උදාහරණයක් මත පදනම් වේ, නමුත් බොහෝ ප්‍රවේශයන් iOS සඳහාද අදාළ වේ.

වරෙක Avito Android කණ්ඩායමේ එක් පුද්ගලයෙක් වැඩ කළා. නිර්වචනය අනුව, ඔහුට අඛණ්ඩ ඒකාබද්ධතාවයෙන් කිසිවක් අවශ්‍ය නොවීය: ඒ සමඟ ඒකාබද්ධ වීමට කිසිවෙකු සිටියේ නැත.

නමුත් යෙදුම වර්ධනය විය, වැඩි වැඩියෙන් නව කාර්යයන් දර්ශනය වූ අතර ඒ අනුව කණ්ඩායම වර්ධනය විය. යම් අවස්ථාවක, කේත ඒකාබද්ධ කිරීමේ ක්‍රියාවලියක් වඩාත් විධිමත් ලෙස ස්ථාපිත කිරීමට කාලයයි. Git flow භාවිතා කිරීමට තීරණය විය.

Git ප්‍රවාහය පිළිබඳ සංකල්පය හොඳින් දන්නා කරුණකි: ව්‍යාපෘතියකට එක් පොදු සංවර්ධන ශාඛාවක් ඇති අතර, සෑම නව විශේෂාංගයක් සඳහාම, සංවර්ධකයින් වෙනම ශාඛාවක් කපා, එයට කැපවී, තල්ලු කර, ඔවුන්ගේ කේතය සංවර්ධන ශාඛාවට ඒකාබද්ධ කිරීමට අවශ්‍ය වූ විට, විවෘත කරන්න. අදින්න ඉල්ලීම. දැනුම බෙදා ගැනීමට සහ ප්‍රවේශයන් සාකච්ඡා කිරීමට, අපි කේත සමාලෝචනය හඳුන්වා දුන්නෙමු, එනම්, සගයන් එකිනෙකාගේ කේතය පරීක්ෂා කර තහවුරු කළ යුතුය.

චෙක්පත්

ඔබේ ඇස්වලින් කේතය බැලීම සිසිල්, නමුත් ප්රමාණවත් නොවේ. එබැවින්, ස්වයංක්රීය චෙක්පත් හඳුන්වා දෙනු ලැබේ.

• පළමුවෙන්ම, අපි පරීක්ෂා කරමු ARK එකලස් කිරීම.
• ගොඩක් ජූනිට් පරීක්ෂණ.
• අපි කේත ආවරණය සලකා බලමු, අපි පරීක්ෂණ පවත්වන නිසා.

මෙම චෙක්පත් ක්රියාත්මක කළ යුතු ආකාරය තේරුම් ගැනීමට, Avito හි සංවර්ධන ක්රියාවලිය දෙස බලමු.

එය ක්‍රමානුකූලව මෙලෙස නිරූපණය කළ හැක.

• සංවර්ධකයෙක් ඔහුගේ ලැප්ටොප් එකේ කේතයක් ලියයි. ඔබට මෙහි ඒකාබද්ධතා චෙක්පත් ක්‍රියාත්මක කළ හැක - එක්කෝ කැපවීම් කොක්කකින් හෝ හුදෙක් පසුබිමේ චෙක්පත් ධාවනය කරන්න.
• සංවර්ධකයා කේතය තල්ලු කළ පසු, ඔහු අදින්න ඉල්ලීමක් විවෘත කරයි. එහි කේතය සංවර්ධිත ශාඛාවට ඇතුළත් කිරීම සඳහා, කේත සමාලෝචනයක් හරහා ගොස් අවශ්ය තහවුරු කිරීම් සංඛ්යාව එකතු කිරීම අවශ්ය වේ. ඔබට මෙහි චෙක්පත් සහ ගොඩනැගීම් සබල කළ හැක: සියලු ගොඩනැගීම් සාර්ථක වන තුරු, ඇදීමේ ඉල්ලීම ඒකාබද්ධ කළ නොහැක.
• ඇදීමේ ඉල්ලීම ඒකාබද්ධ කර කේතය සංවර්‍ධනයට ඇතුළත් කළ පසු, ඔබට පහසු වේලාවක් තෝරා ගත හැකිය: උදාහරණයක් ලෙස, රාත්‍රියේදී, සියලුම සේවාදායකයන් නොමිලේ වන විට සහ ඔබ කැමති තරම් චෙක්පත් ක්‍රියාත්මක කරන්න.

කිසිවෙකු ඔවුන්ගේ ලැප්ටොප් පරිගණකයේ ස්කෑන් ධාවනය කිරීමට කැමති වූයේ නැත. සංවර්ධකයෙකු විශේෂාංගයක් අවසන් කළ විට, ඔහුට එය ඉක්මනින් තල්ලු කර ඇදීමේ ඉල්ලීමක් විවෘත කිරීමට අවශ්‍ය වේ. මේ මොහොතේ සමහර දිගු චෙක්පත් දියත් කර ඇත්නම්, මෙය ඉතා ප්රසන්න පමණක් නොව, සංවර්ධනය මන්දගාමී වේ: ලැප්ටොප් පරිගණකය යමක් පරීක්ෂා කරන අතර, එය සාමාන්යයෙන් වැඩ කිරීමට නොහැකි ය.

අපි ඇත්තටම රාත්‍රියේ චෙක්පත් ධාවනය කිරීමට ප්‍රිය කළෙමු, බොහෝ කාලයක් සහ සේවාදායකයන් ඇති නිසා, ඔබට සැරිසැරීමට හැකිය. එහෙත්, අවාසනාවන්ත ලෙස, විශේෂාංග කේතය සංවර්ධනය වන විට, සංවර්ධකයාට CI සොයාගත් දෝෂ නිවැරදි කිරීමට වඩා අඩු පෙළඹවීමක් ඇත. උදේ රිපෝට් එකේ තියෙන වැරදි ඔක්කොම බලපුවාම මම කලින් කලට හිත හදාගත්තා, පස්සේ දවසක ඒවා හදන්නම් කියලා, මොකද දැන් ජිරා එකේ අලුත් වැඩක් තියෙනවා කරන්න පටන් ගන්න.

චෙක්පත් ඇදීමේ ඉල්ලීමක් අවහිර කරන්නේ නම්, ප්‍රමාණවත් අභිප්‍රේරණයක් ඇත, මන්ද ගොඩනැගීම් කොළ පැහැයට හැරෙන තුරු, කේතය දියුණුවට පත් නොවනු ඇත, එනම් කාර්යය සම්පූර්ණ නොවනු ඇත.

එහි ප්‍රතිඵලයක් වශයෙන්, අපි පහත උපාය මාර්ගය තෝරා ගත්තෙමු: අපි රාත්‍රියේදී හැකි උපරිම චෙක්පත් කට්ටලය ක්‍රියාත්මක කරන අතර, ඒවායින් වඩාත් විවේචනාත්මක ඒවා සහ, වඩාත්ම වැදගත් ලෙස, ඇදීමේ ඉල්ලීම මත වේගවත්ම ඒවා දියත් කරමු. නමුත් අපි එතනින් නවතින්නේ නැහැ - සමාන්තරව, අපි චෙක්පත් වල වේගය ප්‍රශස්ත කරන අතර එමඟින් ඉල්ලීම් චෙක්පත් අදින්න රාත්‍රී මාදිලියෙන් මාරු කරන්න.

ඒ වන විට, අපගේ සියලු ගොඩනැගීම් ඉතා ඉක්මනින් අවසන් වූ අතර, එබැවින් අපි ඇදීමේ ඉල්ලීම සඳහා අවහිර කරන්නෙකු ලෙස ARK ගොඩනැගීම, ජූනිට් පරීක්ෂණ සහ කේත ආවරණ ගණනය කිරීම් ඇතුළත් කළෙමු. අපි එය ක්‍රියාත්මක කර, ඒ ගැන කල්පනා කර, අපට එය අවශ්‍ය නැතැයි සිතූ නිසා කේත ආවරණය අත්හැරියෙමු.

මූලික CI සම්පූර්ණයෙන්ම පිහිටුවීමට අපට දින දෙකක් ගත විය (මෙතැන් සිට කාල ඇස්තමේන්තුව දළ වශයෙන් වේ, පරිමාණය සඳහා අවශ්‍ය වේ).

ඊට පසු, අපි තවදුරටත් සිතන්නට පටන් ගත්තෙමු - අපි නිවැරදිව පරීක්ෂා කරනවාද? අපි ඇදීමේ ඉල්ලීම් මත ගොඩනැගීම් නිවැරදිව ක්‍රියාත්මක කරනවාද?

ඇදීමේ ඉල්ලීම විවෘත කළ ශාඛාවේ අවසාන කැපවීම මත අපි ගොඩනැගීම ආරම්භ කළෙමු. නමුත් මෙම කැපවීම පිළිබඳ පරීක්ෂණ මගින් පෙන්නුම් කළ හැක්කේ සංවර්ධකයා විසින් ලියන ලද කේතය ක්‍රියාත්මක වන බව පමණි. නමුත් ඔහු කිසිවක් කැඩුවේ නැති බව ඔවුන් ඔප්පු කරන්නේ නැත. ඇත්ත වශයෙන්ම, විශේෂාංගයක් ඒකාබද්ධ කිරීමෙන් පසු ඔබ සංවර්ධන ශාඛාවේ තත්වය පරීක්ෂා කළ යුතුය.

මෙය සිදු කිරීම සඳහා, අපි සරල bash පිටපතක් ලිව්වා 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 හි ඇදීමේ ඉල්ලීම ඒකාබද්ධ වේ... Boom! සංවර්ධක කේතයේ නොපවතින ශ්‍රිතයකට ඇමතුමක් අඩංගු බැවින් බිඳීම් සංවර්ධනය කරන්න.

එය වර්ධනය නොවන විට, එය දේශීය ව්යසනය. මුළු කණ්ඩායමටම කිසිවක් එකතු කර පරීක්ෂණයට ඉදිරිපත් කළ නොහැක.

මම බොහෝ විට යටිතල පහසුකම් කාර්යයන් සඳහා වැඩ කළෙමි: විශ්ලේෂණ, ජාල, දත්ත සමුදායන්. එනම්, වෙනත් සංවර්ධකයින් භාවිතා කරන එම කාර්යයන් සහ පන්ති ලිව්වේ මමයි. මේ නිසා, මම බොහෝ විට සමාන තත්වයන්ට මුහුණ දුන්නා. මම මේ පින්තූරය පවා කාලයක් එල්ලා තිබුණා.

මෙය අපට නොගැලපෙන නිසා, අපි මෙය වළක්වා ගන්නේ කෙසේද යන්න පිළිබඳ විකල්ප ගවේෂණය කිරීමට පටන් ගත්තෙමු.

සංවර්ධනය බිඳ නොදැමෙන්නේ කෙසේද

පළමු විකල්පය: සංවර්ධනය යාවත්කාලීන කිරීමේදී සියලුම ඇදීමේ ඉල්ලීම් නැවත ගොඩනඟන්න. අපගේ උදාහරණයේ, A විශේෂාංගය සහිත ඇදීමේ ඉල්ලීම සංවර්ධිතයට ඇතුළත් කළ පළමු අවස්ථාව නම්, B විශේෂාංගයේ ඇදීමේ ඉල්ලීම නැවත ගොඩනඟනු ලබන අතර, ඒ අනුව, සම්පාදන දෝෂයක් හේතුවෙන් චෙක්පත් අසාර්ථක වනු ඇත.

මෙය කොපමණ කාලයක් ගතවේද යන්න තේරුම් ගැනීමට, PR දෙකක් සහිත උදාහරණයක් සලකා බලන්න. අපි PR දෙකක් විවෘත කරමු: ගොඩනැගීම් දෙකක්, චෙක්පත් දෙකක්. පළමු PR එක සංවර්ධනයට ඒකාබද්ධ කළ පසු, දෙවැන්න නැවත ගොඩනැංවිය යුතුය. සමස්තයක් වශයෙන්, PR දෙකක් සඳහා චෙක්පත් තුනක් අවශ්‍ය වේ: 2 + 1 = 3.

මූලධර්මය අනුව, එය හොඳයි. නමුත් අපි සංඛ්‍යාලේඛන දෙස බැලූ අතර, අපගේ කණ්ඩායමේ සාමාන්‍ය තත්වය විවෘත PR 10 ක් වූ අතර, පසුව චෙක්පත් ගණන ප්‍රගතියේ එකතුව වේ: 10 + 9 +... + 1 = 55. එනම්, 10 පිළිගැනීමට PRs, ඔබ 55 වතාවක් නැවත ගොඩනඟා ගත යුතුය. මෙම දුසිම ක්‍රියාවට නංවන අතරතුර කිසිවකු අමතර ඇදීමේ ඉල්ලීමක් විවෘත නොකරන විට, සියලු චෙක්පත් පළමු වරට සමත් වූ විට, මෙය කදිම තත්ත්වයක පවතී.

ඔබ “ඒකාබද්ධ” බොත්තම ක්ලික් කළ යුතු පළමු සංවර්ධකයෙකු ලෙස සිතන්න, මන්ද අසල්වැසියෙකු මෙය කළහොත්, සියලු ගොඩනැගීම් නැවත සිදු වන තෙක් ඔබට බලා සිටීමට සිදුවනු ඇත... නැත, එය ක්‍රියා නොකරනු ඇත. , එය බරපතල ලෙස සංවර්ධනය මන්දගාමී වනු ඇත.

හැකි දෙවන ක්රමය: කේත සමාලෝචනයෙන් පසු ඇදීමේ ඉල්ලීම් එකතු කරන්න. එනම්, ඔබ අදින්න ඉල්ලීමක් විවෘත කර, සගයන්ගෙන් අවශ්‍ය අනුමැතිය ලබා ගැනීම, අවශ්‍ය දේ නිවැරදි කර, පසුව ගොඩනැගීම් දියත් කිරීම. ඒවා සාර්ථක නම්, ඇදීමේ ඉල්ලීම සංවර්ධනයට ඒකාබද්ධ වේ. මෙම අවස්ථාවේදී, අතිරේක නැවත ආරම්භ කිරීම් නොමැත, නමුත් ප්රතිපෝෂණය බෙහෙවින් මන්දගාමී වේ. සංවර්ධකයෙකු ලෙස, මම ඇදීමේ ඉල්ලීමක් විවෘත කළ විට, එය ක්‍රියාත්මක වේද යන්න වහාම බැලීමට මට අවශ්‍යය. උදාහරණයක් ලෙස, පරීක්ෂණයක් අසමත් වුවහොත්, ඔබ ඉක්මනින් එය නිවැරදි කළ යුතුය. ප්‍රමාද වූ ගොඩනැගීමකදී, ප්‍රතිපෝෂණය මන්දගාමී වන අතර, එබැවින් සමස්ත සංවර්ධනය. මේකත් අපිට ගැළපුණේ නැහැ.

එහි ප්රතිඵලයක් වශයෙන්, තුන්වන විකල්පය පමණක් ඉතිරි විය - බයිසිකලය. අපගේ සියලුම කේතයන්, අපගේ සියලුම මූලාශ්‍ර Bitbucket සේවාදායකයේ ගබඩාවක ගබඩා කර ඇත. ඒ අනුව Bitbucket සඳහා ප්ලගිනයක් සංවර්ධනය කිරීමට සිදු විය.

මෙම ප්ලගිනය ඇදීමේ ඉල්ලීම ඒකාබද්ධ කිරීමේ යාන්ත්‍රණය අභිබවා යයි. ආරම්භය සම්මත වේ: PR විවෘත වේ, සියලුම එකලස් කිරීම් දියත් කර ඇත, කේත සමාලෝචනය අවසන් වේ. නමුත් කේත සමාලෝචනය අවසන් වූ පසු සහ සංවර්ධකයා "ඒකාබද්ධ" මත ක්ලික් කිරීමට තීරණය කළ පසු, ප්ලගිනය චෙක්පත් ක්‍රියාත්මක වූයේ කුමන සංවර්ධනයට එරෙහිවද යන්න පරීක්ෂා කරයි. ගොඩනැගීම් වලින් පසුව develop යාවත්කාලීන කර ඇත්නම්, ප්ලගිනය එවැනි ඇදීමේ ඉල්ලීමක් ප්‍රධාන ශාඛාවට ඒකාබද්ධ කිරීමට ඉඩ නොදේ. එය සාපේක්ෂ වශයෙන් මෑත කාලීන සංවර්ධනයක් නැවත ආරම්භ කරනු ඇත.

පරස්පර වෙනස්කම් සහිත අපගේ උදාහරණයේ, සම්පාදනය කිරීමේ දෝෂයක් හේතුවෙන් එවැනි ගොඩනැගීම් අසාර්ථක වනු ඇත. ඒ අනුව, විශේෂාංගය B හි සංවර්ධකයාට කේතය නිවැරදි කිරීමට, චෙක්පත් නැවත ආරම්භ කිරීමට සිදුවනු ඇත, එවිට ප්ලගිනය ස්වයංක්‍රීයව ඇදීමේ ඉල්ලීම යොදනු ඇත.

මෙම ප්ලගිනය ක්‍රියාත්මක කිරීමට පෙර, අපි ඇදීමේ ඉල්ලීමකට සාමාන්‍ය සමාලෝචන ලකුණු 2,7ක් ලබා ගත්තෙමු. ප්ලගිනය සමඟ දියත් කිරීම් 3,6 ක් විය. මෙය අපට ගැලපේ.

මෙම ප්ලගිනයට අඩුපාඩුවක් ඇති බව සඳහන් කිරීම වටී: එය ගොඩනැගීම නැවත ආරම්භ කරන්නේ එක් වරක් පමණි. එනම්, ගැටුම්කාරී වෙනස්කම් වර්ධනය විය හැකි කුඩා කවුළුවක් තවමත් පවතී. නමුත් මෙය සිදුවීමේ සම්භාවිතාව අඩු වන අතර, අපි ආරම්භ කිරීම් ගණන සහ අසාර්ථක වීමේ සම්භාවිතාව අතර මෙම ගනුදෙනුව සිදු කළෙමු. වසර දෙකකින් එය එක් වරක් පමණක් වෙඩි තැබුවේය, එබැවින් එය නිෂ්ඵල නොවේ.

Bitbucket ප්ලගිනයේ පළමු අනුවාදය ලිවීමට අපට සති දෙකක් ගත විය.

නව චෙක්පත්

මේ අතර, අපේ කණ්ඩායම දිගටම වර්ධනය විය. නව චෙක්පත් එකතු කර ඇත.

අපි හිතුවා: වැළැක්විය හැකි නම් වැරදි කරන්නේ ඇයි? ඒ වගේම තමයි ඔවුන් ක්‍රියාත්මක කළේ ස්ථිතික කේත විශ්ලේෂණය. අපි ඇන්ඩ්රොයිඩ් SDK හි ඇතුළත් කර ඇති ලින්ට් සමඟ ආරම්භ කළෙමු. නමුත් ඒ වන විට ඔහු Kotlin කේතය සමඟ වැඩ කරන්නේ කෙසේදැයි නොදැන සිටි අතර, අපි දැනටමත් Kotlin හි ලියා ඇති අයදුම්පත්රයෙන් 75% කි. එමනිසා, ගොඩනඟන ලද ඒවා ලින්ට් එකට එකතු කරන ලදී Android Studio පරීක්ෂා කරයි.

මෙය සිදු කිරීම සඳහා, අපට බොහෝ විකෘති කිරීම් සිදු කිරීමට සිදු විය: ඇන්ඩ්‍රොයිඩ් ස්ටුඩියෝව ගෙන, එය ඩොකර් තුළ ඇසුරුම් කර, එය සැබෑ ලැප්ටොප් එකක ක්‍රියාත්මක වන බව සිතන පරිදි, එය අථත්‍ය මොනිටරයක් ​​සමඟ CI මත ධාවනය කරන්න. නමුත් එය සාර්ථක විය.

අපි ගොඩක් ලියන්න පටන් ගත්තෙත් මේ කාලෙ තමයි උපකරණ පරීක්ෂණ සහ ක්රියාත්මක කරන ලදී තිරපිටපත් පරීක්ෂාව. මෙය වෙනම කුඩා දසුනක් සඳහා යොමු තිර රුවක් උත්පාදනය කරන විට වන අතර, පරීක්ෂණය සමන්විත වන්නේ දර්ශනයෙන් තිර රුවක් ගැනීම සහ එය සම්මත සෘජු පික්සලය සමඟ පික්සලයෙන් සංසන්දනය කිරීමෙනි. විෂමතාවයක් තිබේ නම්, එයින් අදහස් වන්නේ පිරිසැලසුම කොතැනක හෝ වැරදී ඇති බවයි හෝ මෝස්තරවල යම් දෙයක් වැරදියි.

නමුත් උපකරණ පරීක්ෂණ සහ තිරපිටපත් පරීක්ෂණ උපාංග මත ධාවනය කළ යුතුය: ඉමුලේටර් මත හෝ සැබෑ උපාංග මත. පරීක්ෂණ ගොඩක් ඇති බවත්, ඒවා නිතර නිතර ධාවනය වන බවත් සැලකිල්ලට ගනිමින්, සම්පූර්ණ ගොවිපලක් අවශ්ය වේ. ඔබේම ගොවිපලක් ආරම්භ කිරීම ශ්‍රම ශක්තියෙන් වැඩියි, එබැවින් අපි සූදානම් කළ විකල්පයක් සොයා ගත්තෙමු - Firebase Test Lab.

Firebase Test Lab

Firebase Google නිෂ්පාදනයක් වන නිසා එය තෝරා ගන්නා ලදී, එනම් එය විශ්වාසදායක විය යුතු අතර කිසිදා මිය නොයෑමට ඉඩ ඇත. මිල ගණන් සාධාරණයි: සැබෑ උපාංගයක ක්‍රියාකාරීත්වයේ පැයකට $5, ඉමුලේටරයක ක්‍රියාකාරිත්වයේ පැයකට $1.

Firebase Test Lab අපගේ CI වෙත ක්‍රියාත්මක කිරීමට ආසන්න වශයෙන් සති තුනක් ගත විය.

නමුත් කණ්ඩායම දිගටම වර්ධනය වූ අතර, ෆයර්බේස්, අවාසනාවකට මෙන්, අපව පහත් කිරීමට පටන් ගත්තේය. එකල ඔහුට එස්.එල්.ඒ. සමහර විට Firebase අපට අවශ්‍ය උපාංග සංඛ්‍යාව පරීක්ෂණ සඳහා නොමිලේ ලැබෙන තෙක් බලා සිටීමට සැලැස්වූ අතර අපට අවශ්‍ය පරිදි ඒවා වහාම ක්‍රියාත්මක කිරීම ආරම්භ කළේ නැත. පෝලිමේ රැඳී සිටීමට පැය භාගයක් දක්වා ගත විය, එය ඉතා දිගු වේලාවකි. සෑම PR එකකම උපකරණ පරීක්ෂණ ක්‍රියාත්මක විය, ප්‍රමාදයන් සැබවින්ම සංවර්ධනය මන්දගාමී විය, පසුව මාසික බිල්පත වට මුදලක් සමඟ පැමිණියේය. පොදුවේ ගත් කල, කණ්ඩායම ප්‍රමාණවත් ලෙස වර්ධනය වී ඇති බැවින් Firebase අතහැර නිවස තුළ වැඩ කිරීමට තීරණය විය.

Docker + Python + bash

අපි Docker ගෙන, emulators එයට පුරවා, Python හි සරල වැඩසටහනක් ලිව්වෙමු, එය නියම මොහොතේ නිවැරදි අනුවාදයේ අවශ්‍ය ඉමුලේටර් සංඛ්‍යාව ආරම්භ කර අවශ්‍ය විට ඒවා නවත්වයි. සහ, ඇත්ත වශයෙන්ම, බැෂ් ස්ක්‍රිප්ට් කිහිපයක් - ඒවා නොමැතිව අපි කොහිද?

අපේම පරීක්ෂණ පරිසරයක් නිර්මාණය කිරීමට සති පහක් ගත විය.

එහි ප්‍රතිඵලයක් වශයෙන්, සෑම ඇදීමේ ඉල්ලීමක් සඳහාම පුළුල් ඒකාබද්ධ-අවහිර කිරීමේ චෙක්පත් ලැයිස්තුවක් තිබුණි:

• ARK එකලස් කිරීම;
• ජූනිට් පරීක්ෂණ;
• ලින්ට්;
• Android Studio චෙක්පත්;
• උපකරණ පරීක්ෂණ;
• තිරපිටපත් පරීක්ෂණ.

මෙය සිදුවිය හැකි බොහෝ බිඳවැටීම් වළක්වා ඇත. තාක්‍ෂණිකව සෑම දෙයක්ම ක්‍රියාත්මක විය, නමුත් සංවර්ධකයින් පැමිණිලි කළේ ප්‍රති results ල සඳහා බලා සිටීම ඉතා දිගු බවයි.

කොච්චර දිග වැඩිද? අපි Bitbucket සහ TeamCity වෙතින් දත්ත විශ්ලේෂණ පද්ධතියට උඩුගත කර එය අවබෝධ කර ගත්තෙමු සාමාන්ය පොරොත්තු කාලය විනාඩි 45 යි. එනම්, සංවර්ධකයෙකු, ඇදීමේ ඉල්ලීමක් විවෘත කරන විට, ගොඩනැගීමේ ප්රතිඵල සඳහා සාමාන්යයෙන් විනාඩි 45 ක් බලා සිටියි. මගේ මතය අනුව, මෙය බොහෝ ය, ඔබට එසේ වැඩ කළ නොහැක.

ඇත්ත වශයෙන්ම, අපි අපගේ සියලු ඉදිකිරීම් වේගවත් කිරීමට තීරණය කළා.

අපි වේගවත් කරමු

ඉදි කිරීම් බොහෝ විට පෝලිමක සිටින බව දකිමු, අපි මුලින්ම කරන්නේ එයයි තවත් දෘඩාංග මිලදී ගත්තා - පුළුල් සංවර්ධනය සරලම වේ. ගොඩනැඟිලි පෝලිම් තැබීම නැවැත්වූ නමුත් පොරොත්තු කාලය සුළු වශයෙන් අඩු විය, මන්ද සමහර චෙක්පත් ඉතා දිගු කාලයක් ගත විය.

වැඩි කාලයක් ගතවන චෙක්පත් ඉවත් කිරීම

අපගේ අඛණ්ඩ ඒකාබද්ධතාවයට මෙවැනි දෝෂ සහ ගැටළු අල්ලා ගත හැක.

• යන්නේ නැහැ. පරස්පර වෙනස්කම් හේතුවෙන් යමක් ගොඩනඟා නැති විට CI හට සම්පාදන දෝෂයක් අල්ලා ගත හැක. මම දැනටමත් පවසා ඇති පරිදි, කිසිවෙකුට කිසිවක් එක්රැස් කළ නොහැක, සංවර්ධනය නතර වේ, සෑම කෙනෙකුම කලබල වේ.
• හැසිරීමේ දෝෂයක්. උදාහරණයක් ලෙස, යෙදුම ගොඩනඟන විට, නමුත් ඔබ බොත්තමක් එබූ විට බිඳ වැටේ, හෝ බොත්තම කිසිසේත් එබී නැත. එවැනි දෝෂයක් පරිශීලකයා වෙත ළඟා විය හැකි නිසා මෙය නරක ය.
• පිරිසැලසුමේ දෝෂයක්. උදාහරණයක් ලෙස, බොත්තමක් ක්ලික් කර ඇත, නමුත් පික්සල 10 ක් වමට ගෙන ගොස් ඇත.
• තාක්ෂණික ණය වැඩිවීම.

මෙම ලැයිස්තුව බැලීමෙන් පසුව, පළමු කරුණු දෙක පමණක් තීරණාත්මක බව අපට වැටහුණි. අපි මුලින්ම එවැනි ගැටළු අල්ලා ගැනීමට අවශ්යයි. පිරිසැලසුමෙහි දෝෂ සැලසුම්-සමාලෝචන අදියරේදී සොයාගනු ලබන අතර එවිට පහසුවෙන් නිවැරදි කළ හැක. තාක්ෂණික ණය සමඟ ගනුදෙනු කිරීම සඳහා වෙනම ක්‍රියාවලියක් සහ සැලසුමක් අවශ්‍ය වේ, එබැවින් අපි එය ඇදීමේ ඉල්ලීමක් මත පරීක්ෂා නොකිරීමට තීරණය කළෙමු.

මෙම වර්ගීකරණය මත පදනම්ව, අපි සම්පූර්ණ චෙක්පත් ලැයිස්තුව සොලවන්නෙමු. ලින්ට්ව හරස් කළා සහ එහි දියත් කිරීම එක රැයකින් කල් දැමීය: එය ව්‍යාපෘතියේ කොපමණ ගැටලු තිබේද යන්න පිළිබඳ වාර්තාවක් ඉදිරිපත් කරනු ඇත. තාක්ෂණික ණය සමඟ වෙන වෙනම වැඩ කිරීමට අපි එකඟ විය, සහ Android Studio චෙක්පත් සම්පූර්ණයෙන්ම අත්හැර දමා ඇත. ධාවන පරීක්ෂණ සඳහා ඩොකර් හි ඇන්ඩ්‍රොයිඩ් ස්ටුඩියෝ සිත්ගන්නාසුළුයි, නමුත් සහය දීමේදී බොහෝ කරදර ඇති කරයි. ඇන්ඩ්‍රොයිඩ් ස්ටූඩියෝ අනුවාද සඳහා ඕනෑම යාවත්කාලීන කිරීමක් යනු තේරුම්ගත නොහැකි දෝෂ සමඟ අරගලයකි. පුස්තකාලය එතරම් ස්ථායී නොවීම සහ ව්‍යාජ ධනාත්මක කරුණු තිබූ නිසා තිරපිටපත් පරීක්ෂණ සඳහා සහාය වීමද අපහසු විය. පිරික්සුම් ලැයිස්තුවෙන් තිරපිටපත් පරීක්ෂණ ඉවත් කර ඇත.

ප්රතිඵලයක් වශයෙන්, අපට ඉතිරි වූයේ:

• ARK එකලස් කිරීම;
• ජූනිට් පරීක්ෂණ;
• උපකරණ පරීක්ෂණ.

Gradle දුරස්ථ හැඹිලිය

දැඩි චෙක්පත් නොමැතිව, සියල්ල යහපත් විය. නමුත් පරිපූර්ණත්වයට සීමාවක් නැත!

අපගේ යෙදුම දැනටමත් ග්‍රැඩ්ල් මොඩියුල 150 කට පමණ බෙදා ඇත. Gradle remote cache සාමාන්‍යයෙන් මෙම අවස්ථාවේදී හොඳින් ක්‍රියා කරයි, එබැවින් අපි එය උත්සාහ කිරීමට තීරණය කළෙමු.

Gradle remote cache යනු එක් එක් මොඩියුලවල තනි කාර්යයන් සඳහා කෞතුක වස්තු හැඹිලිගත කළ හැකි සේවාවකි. Gradle, ඇත්ත වශයෙන්ම කේතය සම්පාදනය කරනවා වෙනුවට, දුරස්ථ හැඹිලියට තට්ටු කර යමෙකු දැනටමත් මෙම කාර්යය ඉටු කර ඇත්දැයි විමසීමට HTTP භාවිතා කරයි. ඔව් නම්, එය හුදෙක් ප්රතිඵලය බාගත කරයි.

Gradle විසින් Docker රූපයක් සපයන නිසා Gradle දුරස්ථ හැඹිලිය ධාවනය කිරීම පහසුය. අපි පැය තුනකින් මේක කරන්න සමත් වුණා.

ඔබට කළ යුතුව තිබුණේ ඩොකර් දියත් කර ව්‍යාපෘතියේ එක් පේළියක් ලිවීමයි. නමුත් එය ඉක්මනින් දියත් කළ හැකි වුවද, සියල්ල හොඳින් ක්‍රියාත්මක වීමට සෑහෙන කාලයක් ගතවනු ඇත.

පහත දැක්වෙන්නේ හැඹිලි මග හැරුණු ප්‍රස්ථාරයයි.

ආරම්භයේදීම, හැඹිලි මගහැරීම් ප්‍රතිශතය 65 ක් පමණ විය. සති තුනකට පසු, මෙම අගය 20% දක්වා වැඩි කිරීමට අපට හැකි විය. ඇන්ඩ්‍රොයිඩ් යෙදුම එකතු කරන කාර්යයන් අමුතු සංක්‍රාන්ති පරායත්තතා ඇති බව පෙනී ගියේය, එම නිසා ග්‍රැඩ්ල්ට හැඹිලිය මග හැරී ඇත.

හැඹිලිය සම්බන්ධ කිරීමෙන්, අපි ගොඩනැගීම බෙහෙවින් වේගවත් කළෙමු. නමුත් එකලස් කිරීමට අමතරව, උපකරණ පරීක්ෂණ ද ඇති අතර, ඔවුන් බොහෝ කාලයක් ගත වේ. සමහර විට සෑම ඇදීමේ ඉල්ලීමක් සඳහාම සියලුම පරීක්ෂණ ධාවනය කිරීමට අවශ්‍ය නොවේ. සොයා ගැනීමට, අපි බලපෑම් විශ්ලේෂණය භාවිතා කරමු.

බලපෑම් විශ්ලේෂණය

ඇදීමේ ඉල්ලීමක් මත, අපි git diff එකතු කර වෙනස් කරන ලද Gradle මොඩියුල සොයා ගනිමු.

වෙනස් වූ මොඩියුල සහ ඒවා මත රඳා පවතින සියලුම මොඩියුල පරීක්ෂා කරන උපකරණ පරීක්ෂණ පමණක් ධාවනය කිරීම අර්ථවත් කරයි. අසල්වැසි මොඩියුල සඳහා පරීක්ෂණ ධාවනය කිරීමේ තේරුමක් නැත: එහි කේතය වෙනස් වී නැති අතර කිසිවක් බිඳ දැමිය නොහැක.

උපකරණ පරීක්ෂණ එතරම් සරල නැත, මන්ද ඒවා ඉහළ මට්ටමේ යෙදුම් මොඩියුලයේ පිහිටා තිබිය යුතුය. එක් එක් පරීක්ෂණය අයත් වන්නේ කුමන මොඩියුලයටද යන්න තේරුම් ගැනීමට අපි බයිට්කේත විශ්ලේෂණය සමඟ හූරිස්ටික්ස් භාවිතා කළෙමු.

උපකරණ පරීක්ෂණවල ක්‍රියාකාරිත්වය උත්ශ්‍රේණිගත කිරීම සඳහා ඔවුන් සම්බන්ධ වූ මොඩියුල පමණක් පරීක්ෂා කිරීමට සති අටක් පමණ ගත විය.

පරීක්ෂණ කඩිනම් කිරීමේ ක්‍රියාමාර්ග සාර්ථකව ක්‍රියාත්මක වී ඇත. මිනිත්තු 45 සිට අපි 15 දක්වා ඉහළ ගියා. ගොඩනැගීම සඳහා පැය හතරෙන් එකක් බලා සිටීම දැනටමත් සාමාන්ය දෙයක්.

නමුත් දැන් සංවර්ධකයින් පැමිණිලි කිරීමට පටන් ගෙන ඇත්තේ කුමන ගොඩනැඟිලි දියත් කරන්නේද, ලොගය දැකිය යුත්තේ කොතැනින්ද, ගොඩනැගීම රතු වන්නේ ඇයි, කුමන පරීක්ෂණය අසාර්ථකද යන්නද ඔවුන්ට නොතේරෙන බවයි.

ප්‍රතිපෝෂණ සමඟ ඇති ගැටළු සංවර්ධනය මන්දගාමී කරයි, එබැවින් අපි එක් එක් PR පිළිබඳ පැහැදිලි සහ සවිස්තරාත්මක තොරතුරු සැපයීමට සහ හැකිතාක් ගොඩනැගීමට උත්සාහ කළෙමු. අපි Bitbucket හි PR වෙත අදහස් දැක්වීමෙන් ආරම්භ කළෙමු, කුමන ගොඩනැගීම අසාර්ථක වූයේද සහ ඇයිද යන්න සඳහන් කරමින්, සහ Slack හි ඉලක්කගත පණිවිඩ ලිවීය. අවසානයේදී, අපි දැනට ක්‍රියාත්මක වන සියලුම ගොඩනැගීම් ලැයිස්තුවක් සහ ඒවායේ තත්ත්වය: පෝලිම්ගත, ධාවනය, බිඳවැටුණු හෝ සම්පූර්ණ කර ඇති පිටුව සඳහා PR උපකරණ පුවරුවක් නිර්මාණය කළෙමු. ඔබට ගොඩනැගීම මත ක්ලික් කර එහි ලොගයට යා හැකිය.

සවිස්තරාත්මක ප්‍රතිපෝෂණ සඳහා සති හයක් ගත විය.

සැලසුම්

අපි මෑත ඉතිහාසයට යමු. ප්‍රතිපෝෂණ ගැටළුව නිරාකරණය කිරීමෙන් පසු අපි නව මට්ටමකට පැමිණියෙමු - අපි අපගේම ඉමුලේටර් ගොවිපලක් තැනීමට තීරණය කළෙමු. බොහෝ පරීක්ෂණ සහ ඉමුලේටර් ඇති විට, ඒවා කළමනාකරණය කිරීමට අපහසු වේ. එහි ප්‍රතිඵලයක් වශයෙන්, අපගේ සියලුම ඉමුලේටර් නම්‍යශීලී සම්පත් කළමනාකරණයක් සහිත k8s පොකුරට මාරු විය.

ඊට අමතරව තවත් සැලසුම් තිබේ.

• ආපසු ලින්ට් (සහ වෙනත් ස්ථිතික විශ්ලේෂණය). අපි දැනටමත් මෙම දිශාවට වැඩ කරමින් සිටිමු.
• PR blocker එකක සියල්ල ධාවනය කරන්න අන්තයේ සිට අවසානය දක්වා පරීක්ෂණ සියලුම SDK අනුවාද මත.

ඉතින්, අපි Avito හි අඛණ්ඩ ඒකාබද්ධතාවයේ වර්ධනයේ ඉතිහාසය සොයාගෙන ඇත. දැන් මට අත්දැකීම් සහිත දෘෂ්ටි කෝණයකින් උපදෙස් කිහිපයක් දීමට අවශ්යයි.

ඉඟි

මට එක උපදෙසක් දෙන්න පුළුවන් නම් ඒක මෙහෙමයි.

කරුණාකර shell scripts සමඟ ප්‍රවේශම් වන්න!

Bash යනු ඉතා නම්‍යශීලී සහ බලවත් මෙවලමකි, එය පිටපත් ලිවීමට ඉතා පහසු සහ වේගවත් වේ. නමුත් ඔබට එය සමඟ උගුලකට වැටිය හැකි අතර, අවාසනාවකට මෙන්, අපි එයට වැටුණෙමු.

ඒ සියල්ල ආරම්භ වූයේ අපගේ ගොඩනැගීමේ යන්ත්‍රවල ක්‍රියාත්මක වන සරල ස්ක්‍රිප්ට් වලින්:

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

නමුත්, ඔබ දන්නා පරිදි, කාලයත් සමඟ සෑම දෙයක්ම වර්ධනය වන අතර වඩාත් සංකීර්ණ වේ - අපි එක් ස්ක්‍රිප්ට් එකක් තවත් එකකින් ධාවනය කරමු, එහි පරාමිති කිහිපයක් යමු - අවසානයේ අපට ශ්‍රිතයක් ලිවීමට සිදු වූයේ අප දැන් කුමන මට්ටමේ බැෂ් කැදැල්ලක් පිළිවෙළකට තබා ඇත්ද යන්න තීරණය කරයි. අවශ්‍ය උපුටා දැක්වීම් ඇතුළු කිරීමට, සියල්ල ආරම්භ කිරීමට.

එවැනි ස්ක්‍රිප්ට් සංවර්ධනය සඳහා ශ්‍රම පිරිවැය ඔබට සිතාගත හැකිය. මෙම උගුලට හසු නොවන ලෙස මම ඔබට උපදෙස් දෙමි.

ප්රතිස්ථාපනය කළ හැක්කේ කුමක්ද?

• ඕනෑම ස්ක්‍රිප්ටින් භාෂාවක්. වෙත ලියන්න Python හෝ Kotlin Script එය ක්‍රමලේඛනය මිස ස්ක්‍රිප්ට් නොවන නිසා වඩාත් පහසුයි.
• නැතහොත් පෝරමයේ ඇති සියලුම ගොඩනැගීමේ තර්කනය විස්තර කරන්න අභිරුචි gradle කාර්යයන් ඔබේ ව්යාපෘතිය සඳහා.

අපි දෙවන විකල්පය තෝරා ගැනීමට තීරණය කළ අතර, දැන් අපි සියලු bash ස්ක්‍රිප්ට් ක්‍රමානුකූලව මකා දමමින් අභිරුචි ග්‍රැඩල් කාර්යයන් රාශියක් ලියමු.

ඉඟිය #2: යටිතල පහසුකම් කේතය තුළ ගබඩා කරන්න.

Continuous Integration සැකසුම Jenkins හෝ TeamCity යනාදී UI අතුරුමුහුණතෙහි නොව කෙලින්ම ව්‍යාපෘති ගබඩාවේ පෙළ ගොනු ආකාරයෙන් ගබඩා කර ඇති විට එය පහසු වේ. මෙය අනුවාද හැකියාව ලබා දෙයි. වෙනත් ශාඛාවක කේතය ආපසු හැරවීම හෝ ගොඩනැගීම අපහසු නොවනු ඇත.

ස්ක්‍රිප්ට් ව්‍යාපෘතියක ගබඩා කළ හැක. පරිසරය සමඟ කුමක් කළ යුතුද?

ඉඟිය #3: ඩොකර්ට පරිසරය සමඟ උදව් කළ හැක.

එය නිසැකවම ඇන්ඩ්‍රොයිඩ් සංවර්ධකයින්ට උදව් වනු ඇත; 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 ඉංජිනේරුවන්ගේ ජීවිතය බෙහෙවින් පහසු කරයි. ඇන්ඩ්‍රොයිඩ්-එස්ඩීකේ ඩොකර් වෙත තල්ලු කිරීම තරමක් පහසු ය, නමුත් ඉමුලේටර් සමඟ එය ටිකක් අපහසු වේ: ඔබට ටිකක් වෙහෙස මහන්සි වී වැඩ කිරීමට සිදුවනු ඇත (නැතහොත් නිමි එක නැවත GitHub වෙතින් බාගන්න).

ඉඟි අංක 4: පරීක්ෂණ සිදු කරනු ලබන්නේ පරීක්ෂණ සඳහා නොව මිනිසුන් සඳහා බව අමතක නොකරන්න.

ඉක්මන් සහ, වඩාත්ම වැදගත් ලෙස, සංවර්ධකයින් සඳහා පැහැදිලි ප්‍රතිපෝෂණය ඉතා වැදගත් වේ: කැඩී ගිය දේ, කුමන පරීක්ෂණය අසාර්ථක වූයේද, මට ගොඩනැගීම් ලොගය දැකිය හැක්කේ කොතැනින්ද.

ඉඟිය #5: අඛණ්ඩ ඒකාබද්ධතාවය වර්ධනය කිරීමේදී ප්‍රායෝගික වන්න.

ඔබට වළක්වා ගැනීමට අවශ්‍ය දෝෂ මොනවාද, කොපමණ සම්පත්, කාලය සහ පරිගණක කාලය වැය කිරීමට ඔබ කැමතිද යන්න පැහැදිලිව තේරුම් ගන්න. බොහෝ කාලයක් ගත වන චෙක්පත්, උදාහරණයක් ලෙස, එක රැයකින් කල් දැමිය හැකිය. ඒවායින් ඉතා වැදගත් නොවන වැරදි අල්ලා ගන්නා ඒවා සම්පූර්ණයෙන්ම අත්හැරිය යුතුය.

ඉඟිය #6: සූදානම් කළ මෙවලම් භාවිතා කරන්න.

ක්ලවුඩ් CI සපයන සමාගම් බොහොමයක් දැන් තිබේ.

කුඩා කණ්ඩායම් සඳහා මෙය හොඳ විසඳුමකි. ඔබට කිසිම දෙයකට සහය දැක්වීමට අවශ්‍ය නැත, සුළු මුදලක් ගෙවන්න, ඔබේ යෙදුම ගොඩනඟා උපකරණ පරීක්ෂණ පවා ක්‍රියාත්මක කරන්න.

ඉඟිය #7: විශාල කණ්ඩායමක් තුළ, ගෘහස්ථ විසඳුම් වඩා ලාභදායී වේ.

නමුත් ඉක්මනින් හෝ පසුව, කණ්ඩායම වර්ධනය වන විට, ගෘහස්ථ විසඳුම් වඩාත් ලාභදායී වනු ඇත. මේ තීරණ වල එක ප්‍රශ්නයක් තියෙනවා. ආර්ථික විද්‍යාවේ ප්‍රතිලාභ අඩු කිරීමේ නීතියක් ඇත: ඕනෑම ව්‍යාපෘතියක, එක් එක් පසු දියුණුව වඩ වඩාත් දුෂ්කර වන අතර වැඩි වැඩියෙන් ආයෝජන අවශ්‍ය වේ.

ආර්ථික විද්‍යාව අඛණ්ඩ ඒකාබද්ධතාවය ඇතුළුව අපගේ මුළු ජීවිතයම විස්තර කරයි. අපගේ අඛණ්ඩ ඒකාබද්ධතාවයේ සංවර්ධනයේ එක් එක් අදියර සඳහා මම ශ්‍රම පිරිවැය පිළිබඳ කාලසටහනක් ගොඩනඟා ගත්තෙමි.

ඕනෑම දියුණුවක් වඩ වඩාත් දුෂ්කර වෙමින් පවතින බව පැහැදිලිය. මෙම ප්‍රස්ථාරය දෙස බලන විට, කණ්ඩායම් ප්‍රමාණයේ වර්ධනයට අනුකූලව අඛණ්ඩ ඒකාබද්ධතාවය වර්ධනය කළ යුතු බව ඔබට වැටහෙනු ඇත. පුද්ගලයන් දෙදෙනෙකුගෙන් යුත් කණ්ඩායමක් සඳහා අභ්‍යන්තර ඉමුලේටර් ගොවිපලක් සංවර්ධනය කිරීම සඳහා දින 50ක් වැය කිරීම සාමාන්‍ය අදහසකි. නමුත් ඒ සමඟම, විශාල කණ්ඩායමක් සඳහා, අඛණ්ඩ ඒකාබද්ධ කිරීම කිසිසේත් නොකිරීම ද නරක අදහසකි, මන්ද ඒකාබද්ධ කිරීමේ ගැටළු, සන්නිවේදනය නිවැරදි කිරීම යනාදිය. එය තවත් වැඩි කාලයක් ගත වනු ඇත.

අපි පටන් ගත්තේ මිනිස්සු මිල අධික නිසා, වැරදි කරන නිසා සහ කම්මැලි නිසා ස්වයංක්‍රීයකරණය අවශ්‍යයි කියන අදහසින්. නමුත් මිනිසුන් ද ස්වයංක්‍රීය වේ. එමනිසා, එකම ගැටළු සියල්ලම ස්වයංක්රීයකරණයට අදාළ වේ.

• ස්වයංක්රීයකරණය මිල අධිකයි. කම්කරු කාලසටහන මතක තබා ගන්න.
• ස්වයංක්‍රීයකරණය සම්බන්ධයෙන් ගත් කල, මිනිසුන් වැරදි කරයි.
• සමහර විට එය ස්වයංක්‍රීය කිරීමට ඉතා කම්මැලි ය, මන්ද සෑම දෙයක්ම එලෙස ක්‍රියාත්මක වේ. වෙනත් කිසිවක් වැඩිදියුණු කරන්නේ ඇයි, මේ සියලු අඛණ්ඩ ඒකාබද්ධ කිරීම් ඇයි?

නමුත් මට සංඛ්‍යාලේඛන තිබේ: එක්රැස්වීම් වලින් 20% ක් තුළ දෝෂ හසු වේ. මෙය අපගේ සංවර්ධකයින් කේතය දුර්වල ලෙස ලියන නිසා නොවේ. මක්නිසාද යත් තමන් යම් වැරැද්දක් කළහොත් එය සංවර්ධනයෙන් අවසන් නොවන බවත් එය ස්වයංක්‍රීය චෙක්පත් මගින් අල්ලා ගන්නා බවත් සංවර්ධකයින් විශ්වාස කරන බැවිනි. ඒ අනුව, සංවර්ධකයින්ට දේශීයව යමක් ධාවනය කර පරීක්ෂා කරනවාට වඩා කේත සහ රසවත් දේවල් ලිවීමට වැඩි කාලයක් ගත කළ හැකිය.

අඛණ්ඩ ඒකාබද්ධතාවය පුහුණු කරන්න. නමුත් මධ්යස්ථව.

මාර්ගය වන විට, නිකොලායි නෙස්ටරොව් විසින්ම විශිෂ්ට වාර්තා ලබා දෙනවා පමණක් නොව, වැඩසටහන් කමිටුවේ සාමාජිකයෙකි. AppsConf සහ ඔබ වෙනුවෙන් අර්ථවත් කථා සූදානම් කිරීමට අන් අයට උපකාර කරයි. මීළඟ සම්මන්ත්‍රණ වැඩසටහනේ සම්පූර්ණත්වය සහ ප්‍රයෝජනය මාතෘකා මගින් තක්සේරු කළ හැක කාලසටහන. සහ විස්තර සඳහා, අප්‍රේල් 22-23 දිනවල Infospace වෙත පැමිණෙන්න.

මූලාශ්රය: www.habr.com