වාර්තාව සමහර DevOps භාවිතයන් ගැන කතා කරනු ඇත, නමුත් සංවර්ධකයෙකුගේ දෘෂ්ටි කෝණයෙන්. සාමාන්යයෙන්, DevOps හා සම්බන්ධ වන සියලුම ඉංජිනේරුවන්ට දැනටමත් ඔවුන්ගේ තීරය යටතේ වසර කිහිපයක පරිපාලන පළපුරුද්ද ඇත. නමුත් මෙහි සංවර්ධකයාට තැනක් නොමැති බව මින් අදහස් නොවේ. බොහෝ විට, සංවර්ධකයින් “දවසේ ඊළඟ හදිසි විවේචනාත්මක දෝෂය” නිවැරදි කිරීමට කාර්යබහුල වන අතර ඔවුන්ට DevOps ක්ෂේත්රය දෙස ඉක්මන් බැල්මක් හෙළීමටවත් වෙලාවක් නැත. කතුවරයාගේ අවබෝධය අනුව, DevOps යනු, පළමුව, සාමාන්‍ය බුද්ධියයි. දෙවනුව, එය වඩාත් ඵලදායී වීමට අවස්ථාවක්. ඔබ සංවර්ධකයෙක් නම්, සාමාන්‍ය බුද්ධියක් ඇත්නම් සහ කණ්ඩායම් ක්‍රීඩකයෙකු ලෙස වඩාත් ඵලදායී වීමට අවශ්ය නම්, මෙම වාර්තාව ඔබ වෙනුවෙන් වේ.
මට මාව හඳුන්වා දීමට ඉඩ දෙන්න, කාමරයේ මාව නොදන්නා අය සිටින බව මම සම්පූර්ණයෙන්ම පිළිගනිමි. මගේ නම Anton Boyko, මම Microsoft Azure MVP කෙනෙක්. MVP යනු කුමක්ද? මෙය Model-View-Presenter වේ. Model-View-Presenter හරියටම මමයි.
මීට අමතරව, මම දැනට Ciklum හි විසඳුම් ගෘහ නිර්මාණ ශිල්පියාගේ තනතුර දරයි. මෑතකදී මම එවැනි ලස්සන වසමක් මිලදී ගත් අතර, මම සාමාන්යයෙන් ඉදිරිපත් කිරීම් වලදී පෙන්වන මගේ විද්‍යුත් තැපෑල යාවත්කාලීන කළෙමි. ඔබට මට ලිවිය හැක: me [dog] byokoant.pro. ඔබට ප්‍රශ්න සමඟ මට විද්‍යුත් තැපැල් කළ හැක. මම සාමාන්යයෙන් ඒවාට උත්තර දෙනවා. එකම දෙය නම් දේශපාලනය සහ ආගම යන මාතෘකා දෙකකට අදාළ ඊමේල් මගින් ප්‍රශ්න ලැබීමට මම අකමැති වීමයි. ඔබට අනෙක් සියල්ල ගැන මට විද්‍යුත් තැපෑලෙන් ලිවිය හැකිය. යම් කාලයක් ගත වනු ඇත, මම පිළිතුරු දෙන්නෙමි.
ඔබ ගැන වචන කිහිපයක්:
- මම මේ ක්ෂේත්‍රයට ඇවිත් දැන් අවුරුදු 10ක් වෙනවා.
- මම Microsoft ආයතනයේ වැඩ කළා.
- මම 2014 දී කොතැනක හෝ ආරම්භ කළ යුක්රේන Azure ප්‍රජාවේ ආරම්භක පියා වෙමි. අපි තවමත් එය ඇති අතර එය සංවර්ධනය කරමින් සිටිමු.
- අපි යුක්රේනයේ පවත්වනු ලබන Azure සමුළුවේ නිර්මාතෘවරයාගේ පියා ද මම වෙමි.
- Kyiv හි Global Azure Bootcamp සංවිධානය කිරීමටද මම උදව් කරමි.
- මම කිව්වා වගේ මම Microsoft Azure MVP කෙනෙක්.
- මම නිතරම සම්මන්ත්‍රණවල කතා කරනවා. මම සම්මන්ත්‍රණවල කතා කිරීමට ඇත්තෙන්ම කැමතියි. පහුගිය අවුරුද්දේ මට 40 වතාවක් විතර රඟපාන්න පුළුවන් වුණා. ඔබ යුක්රේනය, බෙලරුසියාව, පෝලන්තය, බල්ගේරියාව, ස්වීඩනය, ඩෙන්මාර්කය, නෙදර්ලන්තය, ස්පාඤ්ඤය හරහා ගමන් කරන්නේ නම් හෝ යුරෝපයේ වෙනත් රටක් ලබා දෙන්නේ නම් හෝ ගන්නේ නම්, ඔබ ප්‍රවාහයේ වලාකුළු තේමාවක් ඇති සම්මන්ත්‍රණයකට යන විට, එය බොහෝ දුරට ඉඩ ඇත. ඔබට මා කථිකයන්ගේ ලැයිස්තුවේ දැකිය හැකිය.
- මමත් Star Trek රසිකයෙක්.
අපි Agenda ගැන ටිකක් කතා කරමු. අපගේ න්‍යාය පත්‍රය ඉතා සරල ය:
- අපි DevOps යනු කුමක්ද යන්න ගැන කතා කරමු. මෙය වැදගත් වන්නේ මන්දැයි අපි කතා කරමු. මීට පෙර, DevOps යනු ඔබ ඔබේ ජීව දත්ත පත්‍රයේ ලියා ඇති මූලික පදයක් වන අතර වහාම +$500 වැටුපක් ලබා ගන්නා ලදී. දැන් ඔබට ඔබේ වැටුපට ඩොලර් 500 ක් ලබා ගැනීම සඳහා උදාහරණයක් ලෙස, ඔබේ ජීව දත්ත පත්‍රයේ බ්ලොක්චේන් ලිවිය යුතුය.
- ඊට පස්සේ, අපි මේ මොකක්ද කියලා ටිකක් තේරුම් ගත්තාම, අපි DevOps practices මොනවද කියලා කතා කරමු. නමුත් පොදුවේ DevOps හි සන්දර්භය තුළ එතරම් නොවේ, නමුත් සංවර්ධකයින්ට උනන්දුවක් දැක්විය හැකි එම DevOps භාවිතයන් ගැන. ඔවුන් ඔබට උනන්දුවක් දැක්විය හැක්කේ මන්දැයි මම ඔබට කියමි. ඔබ මෙය කිසිසේත් කළ යුත්තේ ඇයි සහ එය ඔබට අඩු වේදනාවක් අත්විඳීමට උපකාරී වන්නේ කෙසේද යන්න මම ඔබට කියමි.
බොහෝ අය පෙන්වන සාම්ප්රදායික පින්තූරයක්. බොහෝ ව්‍යාපෘතිවල සිදුවන්නේ මෙයයි. අපගේ මෘදුකාංගයට සහාය දක්වන සංවර්ධන සහ මෙහෙයුම් දෙපාර්තමේන්තු ඇති විට මෙය සිදු වේ. තවද මෙම දෙපාර්තමේන්තු එකිනෙකා සමඟ සන්නිවේදනය නොකරයි.
සමහර විට, ඔබට DevOps සහ මෙහෙයුම් දෙපාර්තමේන්තු තුළ එය එතරම් පැහැදිලිව දැනීමට නොහැකි නම්, ඔබට Dev සහ QA දෙපාර්තමේන්තු සමඟ සාදෘශ්‍යයක් ඇඳිය හැකිය. සොෆ්ට්වෙයාර් ඩිවලොප් කරන අයත් ඉන්නවා, ඩිවලොපර්ස්ලාගේ පැත්තෙන් බැලුවත් නරක QA අයත් ඉන්නවා. උදාහරණයක් ලෙස, මම මගේ අපූරු කේතය ගබඩාවට භාර දෙමි, එහි වාඩි වී සිටින සමහර පාදඩයෙක් මෙම කේතය මට ආපසු ලබා දී ඔබේ කේතය නරක යැයි පවසයි.
මේ සියල්ල සිදුවන්නේ මිනිසුන් එකිනෙකා සමඟ සන්නිවේදනය නොකරන බැවිනි. ඔවුන් සමහර පැකේජ, සමහර යෙදුම් වැරදි වැටහීමේ බිත්තියක් හරහා එකිනෙකාට විසි කර ඒවා සමඟ යමක් කිරීමට උත්සාහ කරති.
DevOps සංස්කෘතිය විනාශ කිරීමට සැලසුම් කර ඇත්තේ හරියටම මෙම බිත්තියයි, i.e. මිනිසුන්ට එකිනෙකා සමඟ සන්නිවේදනය කිරීමට බල කරන අතර අවම වශයෙන් ව්‍යාපෘතියේ විවිධ පුද්ගලයින් කරන්නේ කුමක්ද සහ ඔවුන්ගේ කාර්යය වැදගත් වන්නේ මන්දැයි තේරුම් ගන්න.
තවද අපි DevOps ගැන කතා කරන විට, ව්යාපෘතිය අඛණ්ඩ ඒකාබද්ධතාවයක් ඇති විට DevOps බව යමෙක් ඔබට කියනු ඇත; ව්යාපෘතිය "කේතය ලෙස යටිතල පහසුකම්" ක්‍රියාවට නංවන්නේ නම්, DevOps යැයි යමෙක් කියනු ඇත; DevOps සඳහා වන පළමු පියවර විශේෂාංග ශාඛා කිරීම, විශේෂාංග කොඩි බව යමෙකු පවසනු ඇත.
මූලික වශයෙන්, මේ සියල්ල තමන්ගේම ආකාරයෙන් සත්ය වේ. නමුත් මේවා අපට ඇති අවසාන භාවිතයන් පමණි. මෙම පරිචයන් වෙත යාමට පෙර, ඔබේ ව්‍යාපෘතියේ, ඔබේ සමාගම තුළ Dev-Ops ක්‍රමවේදය ක්රියාත්මක කිරීමේ අදියර 3 පෙන්වන මෙම විනිවිදකය දෙස බැලීමට මම යෝජනා කරමි.
මෙම ස්ලයිඩයට දෙවන නිල නොවන නමක් ද ඇත. DevOps හි Musketeers 3 කුමක්දැයි සොයා ගැනීමට ඔබට අන්තර්ජාලයෙන් සෙවිය හැක. ඔබට මෙම ලිපිය සොයා ගැනීමට හැකි වනු ඇත. ඇයි මස්කටියර්ස් 3? එය පහත සඳහන් වේ: පුද්ගලයන්, ක්රියාවලි සහ නිෂ්පාදන, i.e. PPP - Porthos, Porthos සහ Porthos. මෙන්න DevOps වල Musketeers 3 දෙනා. මෙය වැදගත් වන්නේ ඇයි සහ එයින් අදහස් කරන්නේ කුමක්ද යන්න මෙම ලිපිය වඩාත් විස්තරාත්මකව විස්තර කරයි.
ඔබ DevOps සංස්කෘතියක් ක්රියාත්මක කිරීම ආරම්භ කරන විට, එය පහත අනුපිළිවෙලින් ක්රියාත්මක කිරීම ඉතා වැදගත් වේ.
මුලදී ඔබ මිනිසුන් සමඟ කතා කළ යුතුය. ඒවගේම එය කුමක්ද සහ එයින් යම් ප්‍රතිලාභ ලබා ගන්නේ කෙසේද යන්න ඔබ මිනිසුන්ට පැහැදිලි කළ යුතුය.
අපේ සමුළුව හඳුන්වන්නේ DotNet Fest කියලා. සංවිධායකයින් මට පැවසූ පරිදි, අපි මෙහි ප්රධාන වශයෙන් සංවර්ධකයින්ගේ ප්‍රේක්ෂක පිරිසකට ආරාධනා කළෙමු, එබැවින් ශාලාවේ සිටින බොහෝ දෙනා සංවර්ධනයට සම්බන්ධ යැයි මම බලාපොරොත්තු වෙමි.
අපි මිනිසුන් ගැන කතා කරමු, සංවර්ධකයින්ට දිනපතා කිරීමට අවශ්ය දේ ගැන අපි කතා කරමු. ඔවුන්ට වඩාත්ම අවශ්ය වන්නේ කුමක්ද? ඔවුන්ට නව කේතයක් ලිවීමට, නව විකෘති රාමු භාවිතා කිරීමට, නව විශේෂාංග නිර්මාණය කිරීමට අවශ්‍යයි. සංවර්ධකයින්ට අවම වශයෙන් අවශ්ය වන්නේ කුමක්ද? පැරණි දෝෂ නිවැරදි කරන්න. ඔබ මා සමඟ එකඟ වන බව මම විශ්වාස කරමි. සංවර්ධකයින්ට අවශ්ය වන්නේ මෙයයි. ඔවුන්ට නව විශේෂාංග ලිවීමට අවශ්‍යයි, ඔවුන්ට දෝෂ නිවැරදි කිරීමට අවශ්ය නැත.
විශේෂිත සංවර්ධකයෙකු නිපදවන දෝෂ ගණන රඳා පවතින්නේ ඔහුගේ දෑත් කෙතරම් කෙළින්ද යන්න සහ ඔහුගේ උරහිස් වලින් කොපමණ ප්‍රමාණයක් වර්ධනය වනවාද යන්න මත මිස ඔහුගේ බට් සාක්කු වලින් නොවේ. කෙසේ වෙතත්, අපට විශාල ව්‍යාපෘතියක් ඇති විට, සමහර විට සිදුවන්නේ සෑම දෙයක්ම නිරීක්ෂණය කිරීමට නොහැකි වීමයි, එබැවින් වඩාත් ස්ථාවර සහ උසස් තත්ත්වයේ කේතයක් ලිවීමට අපට උපකාරී වන ප්‍රවේශයන් කිහිපයක් භාවිතා කිරීම අපට සතුටක් වනු ඇත.
QAs වලට වැඩිපුරම අවශ්ය කුමක්ද? ඒ අය හෝල් එකේ ඉන්නවද දන්නේ නෑ. මට QA එකක් අවශ්ය බව පැවසීම මට අපහසුය, මන්ද මම කිසි දිනෙක එසේ වී නැත. ඒවගේම කොල්ලන්ට කිසිම වරදක් නෑ, මම කවදාවත් එහෙම නොකරන බව මම විශ්වාස කරනවා කියලා කියනු ඇත. නමුත් මම ඔවුන්ගේ වැඩ තේරුමක් නැති වැඩක් නැති දෙයක් ලෙස සලකන නිසා නොව, මෙම කාර්යය කාර්යක්ෂමව කළ හැකි පුද්ගලයෙකු ලෙස මා නොසලකන නිසා මම එය කිරීමට උත්සාහ නොකරමි. නමුත් මට තේරෙන විදිහට, QA වැඩිපුරම කැමති නැති දේ උදේ වැඩට යනවා, නිරතුරුවම යම් ආකාරයක ප්‍රතිගාමී පරීක්ෂණ පවත්වමින්, ඔවුන් සංවර්ධකයින්ට 3 කට පෙර වාර්තා කළ එම දෝෂ මතට ගොස් මෙසේ පැවසීම: “ඔබ කවදාද? , Monsieur D 'Artagnan, මෙම දෝෂය නිවැරදි කරන්න.' Monsieur D'Artagnan ඔහුට පිළිතුරු දෙයි: "ඔව්, ඔව්, ඔව්, මම දැනටමත් එය නිවැරදි කර ඇත." ඒවගේම මම එක බග් එකක් හදල 5ක් හදපු එක කොහොමද වෙන්නේ.
නිෂ්පාදනයේදී මෙම විසඳුමට සහය දක්වන පුද්ගලයින්ට මෙම විසඳුම දෝෂ නොමැතිව ක්‍රියා කිරීමට අවශ්ය වේ, එවිට සෑම සිකුරාදා දිනකම සාමාන්‍ය මිනිසුන් බාර් එකට යන විට සේවාදායකය නැවත ආරම්භ කිරීමට අවශ්ය නොවේ. සංවර්ධකයින් සිකුරාදා යොදවා ඇත, පරිපාලකයින් සෙනසුරාදා දක්වා වාඩි වී, මෙම යෙදවීම වැඩි කර නිවැරදි කිරීමට උත්සාහ කරති.
ඔවුන් එකම ගැටළු විසඳීම අරමුණු කරගත් බව ඔබ මිනිසුන්ට පැහැදිලි කරන විට, ඔබට ක්‍රියාවලීන් විධිමත් කිරීමට ඉදිරියට යා හැකිය. එය ඉතා වැදගත්. ඇයි? මක්නිසාද යත් අපි “විධිමත්කරණය” යැයි පවසන විට, ඔබේ ක්‍රියාවලීන් අවම වශයෙන් කොතැනක හෝ තුවායක් මත සිදුවන ආකාරය විස්තර කිරීම ඔබට වැදගත් වේ. උදාහරණයක් ලෙස, ඔබ QA පරිසරයකට හෝ නිෂ්පාදන පරිසරයකට යොදවන්නේ නම්, එය සැමවිටම සිදුවන්නේ මෙම අනුපිළිවෙලට බව ඔබ තේරුම් ගත යුතුය; මෙම අදියරේදී අපි ක්රියාත්මක කරමු, උදාහරණයක් ලෙස, ස්වයංක්‍රීය ඒකක පරීක්ෂණ සහ UI පරීක්ෂණ. යෙදවීමෙන් පසුව, අපි යෙදවීම හොඳින් හෝ දුර්වල ලෙස සිදු වූවාද යන්න පරීක්ෂා කරමු. නමුත් ඔබ නිෂ්පාදනයට යොදවන විට නැවත නැවතත් කළ යුතු ක්‍රියා ලැයිස්තුවක් ඔබට දැනටමත් තිබේ.
ඔබේ ක්රියාවලි විධිමත් වූ විට පමණක්, ඔබ මෙම ක්‍රියාවලීන් ස්වයංක්‍රීය කිරීමට උපකාරී වන නිෂ්පාදන තෝරා ගැනීමට පටන් ගනී.
අවාසනාවකට මෙන්, මෙය බොහෝ විට ප්‍රතිලෝමව සිදුවන බව මම දකිමි. කවුරුහරි "DevOps" යන වචනය ඇසුණු වහාම, ඔවුන් වහාම Jenkins ස්ථාපනය කිරීමට යෝජනා කරයි, මන්ද ඔවුන් Jenkins ස්ථාපනය කළ වහාම ඔවුන්ට DevOps ඇති බව විශ්වාස කරන බැවිනි. ඔවුන් ජෙන්කින්ස් ස්ථාපනය කර, ජෙන්කින්ස් වෙබ් අඩවියේ “කොහොමද” ලිපි කියවා, මෙම ලිපිවලට ක්රියාවලි පුරවා ගැනීමට උත්සාහ කළහ, පසුව මිනිසුන් වෙත පැමිණ මිනිසුන්ට නැමී, ඔබ එය මේ ආකාරයෙන් කළ යුතු බව පොත පවසන බව පවසති. ඉතින් අපි ඒක මේ විදියට කරනවා.
ජෙන්කින්ස් නරක මෙවලමක් බව නොවේ. මම එහෙම දෙයක් කියන්න අදහස් කරන්නේ නැහැ. නමුත් මෙය නිෂ්පාදන වලින් එකක් පමණි. තවද ඔබ භාවිතා කරන නිෂ්පාදනය ඔබේ අවසාන තීරණය විය යුතු අතර, කිසිසේත්ම ඔබේ පළමු තීරණය විය යුතුය. ඔබේ නිෂ්පාදනය සංස්කෘතිය සහ ප්‍රවේශයන් ක්රියාත්මක කිරීම මගින් මෙහෙයවිය යුතු නොවේ. මෙය තේරුම් ගැනීම ඉතා වැදගත් වේ, ඒ නිසා මම මෙම විනිවිදකයේ වැඩි කාලයක් ගත කර මේ සියල්ල මෙතරම් කාලයක් පැහැදිලි කරමි.
අපි පොදුවේ DevOps භාවිතයන් ගැන කතා කරමු. ඒවා කුමක් ද? කුමක්ද වෙනස? ඒවා අත්හදා බලන්නේ කෙසේද? ඒවා වැදගත් වන්නේ ඇයි?
ඔබ අසා ඇති පළමු භාවිතය අඛණ්ඩ ඒකාබද්ධතාවය ලෙස හැඳින්වේ. සමහර විට ව්‍යාපෘතියේ සිටින කෙනෙකුට අඛණ්ඩ ඒකාබද්ධතාව (CI) තිබේ.
ලොකුම ගැටලුව නම් බොහෝ විට මම පුද්ගලයෙකුගෙන් අසන විට: "ඔබට ව්‍යාපෘතියේ CI තිබේද?" සහ ඔහු කියයි: "ඔව්", එවිට මම ඔහු කරන්නේ කුමක්දැයි විමසූ විට, ඔහු මට සම්පූර්ණ ස්වයංක්‍රීය ක්‍රියාවලිය විස්තර කරයි. මෙය සම්පූර්ණයෙන්ම සත්ය නොවේ.
ඇත්ත වශයෙන්ම, CI භාවිතා කිරීම අරමුණු කර ඇත්තේ විවිධ පුද්ගලයින් ලියන කේතය යම් ආකාරයක තනි කේත පදනමකට ඒකාබද්ධ කිරීමයි. එච්චරයි.
CI සමඟින්, සාමාන්යයෙන් වෙනත් භාවිතයන් ඇත - එනම් අඛණ්ඩ යෙදවීම, මුදා හැරීම කළමනාකරණය, නමුත් අපි ඒ ගැන පසුව කතා කරමු.
CI විසින්ම අපට පවසන්නේ විවිධ පුද්ගලයින් කේතය ලියන අතර මෙම කේතය තනි කේත පදනමකට අඛණ්ඩව ඒකාබද්ධ කළ යුතු බවයි.
මෙය අපට ලබා දෙන්නේ කුමක්ද සහ එය වැදගත් වන්නේ ඇයි? අපිට DotNet තියෙනවා නම් ඒක හොඳයි, ඒක compile කරපු language එකක්, අපිට අපේ application එක compile කරන්න පුළුවන්. එය සම්පාදනය කරන්නේ නම්, මෙය දැනටමත් හොඳ සලකුණකි. මෙය තවමත් කිසිවක් අදහස් නොකෙරේ, නමුත් අපට අවම වශයෙන් සම්පාදනය කළ හැකි පළමු හොඳ සලකුණ එයයි.
එවිට අපට පරීක්ෂණ කිහිපයක් ක්රියාත්මක කළ හැකිය, එයද වෙනම භාවිතයකි. පරීක්ෂණ සියල්ලම කොළ පාටයි - මෙය දෙවන හොඳ සලකුණයි. නමුත් නැවතත්, මෙය කිසිවක් අදහස් නොවේ.
නමුත් ඔබ මෙය කරන්නේ ඇයි? අද මම කතා කරන සියලුම භාවිතයන් ආසන්න වශයෙන් එකම අගයක් ගනී, එනම් ආසන්න වශයෙන් එකම ප්‍රතිලාභ සහ මනිනු ලබන්නේ ද ආසන්න වශයෙන් එකම ආකාරයකින් ය.
පළමුව, එය ඔබට බෙදා හැරීම වේගවත් කිරීමට ඉඩ සලසයි. බෙදා හැරීම වේගවත් කිරීමට මෙය ඔබට ඉඩ දෙන්නේ කෙසේද? අපි අපේ කේත පදනමේ නව වෙනස්කම් කිහිපයක් සිදු කරන විට, අපට වහාම මෙම කේතය සමඟ යමක් කිරීමට උත්සාහ කළ හැකිය. බ්‍රහස්පතින්දා එනකම් අපි ඉන්නේ නැහැ මොකද බ්‍රහස්පතින්දා අපි ඒක QA පරිසරයට නිකුත් කරනවා, අපි ඒක මෙතනම සහ මෙතනම කරනවා.
මම ඔබට මගේ ජීවිතයේ එක් දුක්බර කතාවක් කියන්නම්. එය බොහෝ කලකට පෙර, මම තවමත් තරුණ හා කඩවසම් විය. දැන් මම දැනටමත් තරුණ, ලස්සන හා බුද්ධිමත්, නිහතමානී ය. කාලෙකට කලින් මම ව්‍යාපෘතියක හිටියා. අපට සංවර්ධකයින් 30 දෙනෙකුගෙන් පමණ විශාල කණ්ඩායමක් සිටියා. ඒ වගේම අපිට වසර 10ක් පමණ දියුණු වූ විශාල, විශාල ව්‍යවසාය ව්‍යාපෘතියක් තිබුණා. ඒ වගේම අපිට විවිධ ශාඛා තිබුණා. ගබඩාවේ අපට සංවර්ධකයින් ඇවිද ගිය ශාඛාවක් තිබුණි. නිෂ්පාදනයේ පවතින කේතයේ අනුවාදය ප්‍රදර්ශනය කරන ශාඛාවක් තිබුණි.
නිෂ්පාදන ශාඛාව සංවර්ධකයින්ට ලබා ගත හැකි ශාඛාවට වඩා මාස 3 ක් පිටුපසින් විය. මෙමගින් කුමක් වෙයිද? ඒ කියන්නේ මට කොහේ හරි බග් එකක් ආපු ගමන්ම ඩිවලොපර්ස්ලාගේ වරදින් නිෂ්පාදනයට යන නිසා, ඒ අය ඒකට ඉඩ දීපු නිසා, ඒ අය බලපු නිසා QA එකේ වරද නිසා මේකෙන් අදහස් වෙන්නේ මට ලැබෙන එකක් නම් නිෂ්පාදනය සඳහා hotfix සඳහා කාර්යය, එවිට මට මාස 3කට පෙර මගේ කේත වෙනස් කිරීම් ආපසු හැරවිය යුතුය. මාස 3කට කලින් තිබ්බ දේ මතක තියාගෙන එතන හදාගන්න බලන්න ඕනේ.
ඔබ තවමත් මෙම අත්දැකීම ලබා නොමැති නම්, ඔබට එය ඔබගේ නිවසේ ව්‍යාපෘතියට උත්සාහ කළ හැකිය. ප්රධාන දෙය නම්, එය වාණිජ එකක් මත උත්සාහ නොකරන්න. කේත පේළි කිහිපයක් ලියන්න, මාස හයකට ඒවා අමතක කරන්න, ඉන්පසු ආපසු පැමිණ එම කේත රේඛා මොනවාද සහ ඔබට ඒවා නිවැරදි කිරීමට හෝ ප්‍රශස්ත කිරීමට හැකි ආකාරය ඉක්මනින් පැහැදිලි කිරීමට උත්සාහ කරන්න. එය ඉතා උද්වේගකර අත්දැකීමකි.
අපට අඛණ්ඩ ඒකාබද්ධ කිරීමේ පුහුණුවක් තිබේ නම්, මම මගේ කේතය ලියා ඇති වහාම ස්වයංක්‍රීය මෙවලම් ගණනාවක් සමඟ එය පරීක්ෂා කිරීමට මෙය අපට ඉඩ සලසයි. මෙය මට සම්පූර්ණ පින්තූරය ලබා නොදෙනු ඇත, නමුත් කෙසේ වෙතත්, එය අවම වශයෙන් අවදානම් කිහිපයක් ඉවත් කරනු ඇත. කිසියම් විභව දෝෂයක් තිබේ නම්, මම දැන් ඒ ගැන දැන ගන්නෙමි, එනම් වචනාර්ථයෙන් මිනිත්තු කිහිපයකින්. මට මාස 3ක් ආපසු හැරවීමට අවශ්ය නොවනු ඇත. මට විනාඩි 2ක් ආපසු හැරවීමට අවශ්ය වනු ඇත. හොඳ කෝපි යන්ත්‍රයකට මිනිත්තු 2 කින් කෝපි පෙරීමට පවා කාලය නැත, එබැවින් එය ඉතා සිසිල් ය.
මෙය එක් එක් ව්‍යාපෘතියේ කාලයෙන් කාලයට නැවත නැවතත් කළ හැකි අගයක් ඇත, i.e. ඔබ එය සකස් කළ එක පමණක් නොවේ. ඔබට ප්‍රායෝගික දෙකම නැවත කළ හැකි අතර ඔබ ව්‍යාපෘතියට කරන සෑම නව වෙනසක් සඳහාම CI නැවත නැවතත් සිදු කෙරේ. ඔබේ කණ්ඩායම වඩාත් කාර්යක්ෂමව ක්‍රියා කරන නිසා සම්පත් ප්‍රශස්ත කිරීමට මෙය ඔබට ඉඩ සලසයි. ඔබ මාස 3 කට පෙර වැඩ කළ කේතයෙන් දෝෂයක් ඔබ වෙත පැමිණෙන තත්වයක් තවදුරටත් ඔබට ඇති නොවේ. ඔබ වාඩි වී පළමු පැය දෙක ගත කරන විට ඔබට තවදුරටත් සන්දර්භය මාරු කිරීමක් සිදු නොවනු ඇත, එවිට සිදු වූ දේ තේරුම් ගැනීමට සහ ඔබ යමක් නිවැරදි කිරීමට පෙර සන්දර්භයේ සාරය වෙත පිවිසීමට උත්සාහ කරයි.
මෙම පුරුද්දේ සාර්ථකත්වය හෝ අසාර්ථකත්වය මැනිය හැක්කේ කෙසේද? අපි CI ව්‍යාපෘතියේ ක්රියාත්මක කළ දේ ඔබ ලොකු ලොක්කාට වාර්තා කළහොත්, ඔහුට බ්ලා බ්ලා බ්ලා ඇහෙනවා. අපි එය ක්රියාත්මක කළා, හරි, නමුත් ඇයි, එය අපට ගෙන ආවේ කුමක්ද, අපි එය මනින්නේ කෙසේද, අපි එය කෙතරම් නිවැරදිව හෝ වැරදි ලෙස ක්රියාත්මක කරන්නේද?
පළමුවැන්න නම්, CI වලට ස්තූතිවන්ත වන්නට, අපගේ කේතය වඩාත් ස්ථායී විය හැකි නිසා අපට වැඩි වැඩියෙන් සහ බොහෝ විට නිශ්චිතව යෙදවිය හැක. එලෙසම, අපගේ දෝෂයක් සොයා ගැනීමට ඇති කාලය අඩු වන අතර මෙම දෝෂය නිවැරදි කිරීමට ගතවන කාලය හරියටම අඩු වන්නේ අපට පද්ධතියෙන් පිළිතුරක් මෙතැනින් සහ මේ මොහොතේ ලැබෙන නිසා අපගේ කේතයේ ඇති වැරැද්ද කුමක්ද යන්නයි.
අපට ඇති තවත් පරිචයක් නම් බොහෝ විට CI පරිචය සමඟ එන Automation Testing practice වේ. ඔවුන් අත්වැල් බැඳගෙන යනවා.
මෙහිදී තේරුම් ගැනීමට වැදගත් වන්නේ කුමක්ද? අපගේ පරීක්ෂණ වෙනස් බව තේරුම් ගැනීම වැදගත්ය. තවද සෑම ස්වයංක්‍රීය පරීක්ෂණයක්ම තමන්ගේම ගැටළු විසඳීම අරමුණු කර ගෙන ඇත. උදාහරණයක් ලෙස, අපට මොඩියුලයක් වෙන වෙනම පරීක්ෂා කිරීමට ඉඩ සලසන ඒකක පරීක්ෂණ තිබේ, i.e. එය රික්තකයක ක්‍රියා කරන්නේ කෙසේද? මේක හොඳයි.
විවිධ මොඩියුල එකිනෙකා සමඟ ඒකාබද්ධ වන ආකාරය තේරුම් ගැනීමට අපට ඉඩ සලසන ඒකාබද්ධතා පරීක්ෂණ ද අප සතුව ඇත. ඒකත් හොඳයි.
UI සමඟ වැඩ කිරීම පාරිභෝගිකයා විසින් නියම කර ඇති ඇතැම් අවශ්‍යතා සපුරාලන ආකාරය පරීක්ෂා කිරීමට අපට ඉඩ සලසන UI ස්වයංක්‍රීයකරණ පරීක්ෂණ අපට තිබිය හැක.
ඔබ ධාවනය කරන නිශ්චිත පරීක්ෂණ ඔබ ඒවා කොපමණ වාරයක් ධාවනය කරයිද යන්න බලපෑ හැකිය. ඒකක පරීක්ෂණ සාමාන්යයෙන් කෙටි හා කුඩා ලියා ඇත. තවද ඒවා නිතිපතා දියත් කළ හැකිය.
අපි UI ස්වයංක්‍රීයකරණ පරීක්ෂණ ගැන කතා කරන්නේ නම්, ඔබේ ව්යාපෘතිය කුඩා නම් හොඳයි. ඔබේ UI ස්වයංක්‍රීය පරීක්ෂණ සඳහා ප්‍රමාණවත් කාලයක් ගත විය හැක. නමුත් සාමාන්යයෙන් UI ස්වයංක්‍රීයකරණ පරීක්ෂණයක් යනු විශාල ව්‍යාපෘතියකදී පැය කිහිපයක් ගතවන දෙයකි. ඒ වගේම පැය කිහිපයක් නම් හොඳයි. එකම දේ හැම බිල්ඩ් එකකටම ඒවා දුවන එකේ තේරුමක් නෑ. රාත්රියේදී ඒවා ක්රියාත්මක කිරීම අර්ථවත් කරයි. ඒ වගේම හැමෝම උදේ වැඩට ආවම: පරීක්ෂකයින් සහ සංවර්ධකයින් යන දෙකම, අපි රාත්‍රියේ UI autotest ධාවනය කර මෙම ප්‍රතිඵල ලබා ගත් බවට ඔවුන්ට යම් ආකාරයක වාර්තාවක් ලැබුණි. තවද මෙහිදී, ඔබේ නිෂ්පාදනය යම් අවශ්‍යතා සපුරාලන්නේ දැයි පරීක්ෂා කරන සේවාදායකයෙකුගේ පැයක වැඩ කොටසක් එම QA ඉංජිනේරුවෙකුගේ පැයකට වඩා බෙහෙවින් ලාභදායී වනු ඇත, ඔහු ආහාර සහ ස්තුතිය සඳහා වැඩ කරන Junior QA ඉංජිනේරුවෙකු වුවද. සියල්ලටම වඩා, යන්ත්‍ර ක්‍රියාකාරිත්වය පැයක් ලාභදායී වනු ඇත. ඒ සඳහා ආයෝජනය කිරීම අර්ථවත් වන්නේ එබැවිනි.
මම වැඩ කරමින් සිටි තවත් ව්‍යාපෘතියක් තිබේ. මෙම ව්යාපෘතිය සඳහා අපට සති දෙකක ස්ප්‍රින්ට් තිබුණා. මෙම ව්යාපෘතිය විශාල, මූල්ය අංශය සඳහා වැදගත් වූ අතර, වැරදීමක් සිදු කළ නොහැකි විය. සති දෙකක ස්ප්‍රින්ට් එකකින් පසුව, සංවර්ධන චක්‍රය පරීක්ෂණ ක්‍රියාවලියකින් අනුගමනය කරන ලද අතර එය තවත් සති 4 ක් ගත විය. ඛේදවාචකයේ පරිමාණය සිතා ගැනීමට උත්සාහ කරන්න. අපි සති දෙකක් සඳහා කේතය ලියන්නෙමු, පසුව අපි එය ala CodeFreeze කරන්නෙමු, එය යෙදුමේ නව අනුවාදයකට ඇසුරුම් කර එය පරීක්ෂකයින් වෙත ගෙන යන්නෙමු. පරීක්ෂකයින් තවත් සති 4 ක් සඳහා එය පරීක්ෂා කරයි, i.e. ඔවුන් එය පරීක්ෂා කරන අතරතුර, ඔවුන් සඳහා තවත් අනුවාද දෙකක් සකස් කිරීමට අපට කාලය තිබේ. මේක ඇත්තටම දුක හිතෙන කේස් එකක්.
තවද ඔබට වඩාත් ඵලදායි වීමට අවශ්ය නම්, ඔබට ස්වයංක්‍රීය පරීක්ෂණ ක්‍රම ක්රියාත්මක කිරීම අර්ථවත් බව අපි ඔවුන්ට පැවසුවෙමු, මන්ද මෙතැනදී ඔබට රිදවන්නේ මෙයයි.
අඛණ්ඩ යෙදවීම පුහුණු කරන්න. නියමයි, ඔයා හදලා ඉවරයි. මෙය දැනටමත් හොඳයි. ඔබගේ කේතය සම්පාදනය කර ඇත. දැන් මේ ගොඩනැගීම යම් පරිසරයක් මත යෙදවීම හොඳයි. සංවර්ධකයින් සඳහා පරිසරයක කියමු.
එය වැදගත් වන්නේ ඇයි? පළමුව, ඔබ යෙදවීමේ ක්‍රියාවලිය සමඟම ඔබ කෙතරම් සාර්ථක දැයි බැලිය හැක. මට මෙවැනි ව්‍යාපෘති හමු වී ඇත, මම ඇසූ විට: “ඔබ යෙදුමේ නව අනුවාදයක් යොදවන්නේ කෙසේද?”, පිරිමි ළමයින් මට කියනවා: “අපි එය එකලස් කර එය zip ලේඛනාගාරයකට අසුරමු. අපි එය පරිපාලක වෙත තැපෑලෙන් යවමු. පරිපාලක මෙම සංරක්ෂිතය බාගත කර පුළුල් කරයි. සේවාදායකයා නව අනුවාදය ලබා ගන්නා ලෙස මුළු කාර්යාලයම යාච්ඤා කිරීමට පටන් ගනී.
අපි සරල දෙයකින් පටන් ගනිමු. උදාහරණයක් ලෙස, ඔවුන්ට CSS ලේඛනාගාරයට දැමීමට අමතක වී හෝ java-script ගොනු නාමයේ හැෂ් ටැගය වෙනස් කිරීමට අමතක විය. තවද අපි සේවාදායකයට ඉල්ලීමක් කරන විට, බ්‍රව්සරය සිතන්නේ එය දැනටමත් මෙම java-script ගොනුව ඇති බවත් එය බාගත නොකිරීමට තීරණය කරන බවත්ය. පැරණි අනුවාදයක් තිබුණි, යමක් අතුරුදහන් විය. පොදුවේ, බොහෝ ගැටලු ඇති විය හැක. එබැවින්, අඛණ්ඩ යෙදවීමේ භාවිතය මඟින් ඔබ පිරිසිදු විමර්ශන රූපයක් ගෙන එය සම්පූර්ණයෙන්ම පිරිසිදු නව පරිසරයකට උඩුගත කළහොත් කුමක් සිදුවේද යන්න පරීක්ෂා කිරීමට ඔබට ඉඩ සලසයි. මෙය කොතැනට දැයි ඔබට දැක ගත හැකිය.
එසේම, ඔබ එකිනෙකා අතර කේතය අනුකලනය කරන විට, i.e. විධානය අතර, මෙය ඔබට UI මත පෙනෙන ආකාරය බැලීමටද ඉඩ සලසයි.
වැනිලා ජාවා-ස්ක්‍රිප්ට් විශාල ප්‍රමාණයක් භාවිතා කරන විට ඇති වන එක් ගැටළුවක් නම්, සංවර්ධකයින් දෙදෙනෙකු කවුළුව වස්තුවේ එකම නම සහිත විචල්‍යයක් හදිසියේ ප්‍රකාශ කිරීමයි. එවිට, ඔබේ වාසනාව මත රඳා පවතී. ජාවා ස්ක්‍රිප්ට් ගොනුව දෙවනුව පිටතට ඇද දැමුවහොත් අනෙකාගේ වෙනස්කම් උඩින් ලියයි. එය ද ඉතා උද්යෝගිමත් ය. ඔබ ඇතුල් වන්න: එක් දෙයක් එක් පුද්ගලයෙකුට වැඩ කරයි, තවත් දෙයක් තවත් කෙනෙකුට වැඩ නොකරයි. ඒවගේම නිෂ්පාදනයෙන් සියල්ල එළියට එන විට එය "පුදුම" වේ.
අප සතුව ඇති මීළඟ පරිචය වන්නේ ස්වයංක්‍රීය ප්‍රතිසාධන ක්‍රමයයි, එනම් යෙදුමේ පෙර අනුවාදයට පෙරළීම.
සංවර්ධකයින් සඳහා මෙය වැදගත් වන්නේ ඇයි? පරිගණක විශාල වූ සහ වැඩසටහන් කුඩා වූ 90 ගණන්වල ඈත, ඈත XNUMX ගණන්වල මතක ඇති අය තවමත් සිටිති. වෙබ් සංවර්ධනය සඳහා එකම මාර්ගය PHP හරහා විය. එය එසේ වුවද PHP නරක භාෂාවක් බව නොවේ.
නමුත් ගැටලුව වෙනස් විය. අපි අපේ php අඩවියේ නව අනුවාදයක් යෙදවූ විට, අපි එය යෙදුවේ කෙසේද? බොහෝ විට අපි Far Manager හෝ වෙනත් දෙයක් විවෘත කළෙමු. තවද මෙම ගොනු FTP වෙත උඩුගත කර ඇත. අපට කුඩා, කුඩා දෝෂයක් ඇති බව අපට හදිසියේම වැටහුණි, උදාහරණයක් ලෙස, අපට අර්ධ කෝලයක් තැබීමට හෝ දත්ත සමුදාය සඳහා මුරපදය වෙනස් කිරීමට අමතක වී ඇති අතර, දත්ත සමුදාය සඳහා මුරපදයක් ඇත, එය දේශීය සත්කාරකයේ ඇත. අපි ඉක්මනින් FTP වෙත සම්බන්ධ වීමට සහ එහි ඇති ගොනු සංස්කරණය කිරීමට තීරණය කරමු. මෙය ගින්නක් පමණි! 90 දශකයේ ජනප්‍රිය වූයේ මෙයයි.
නමුත්, ඔබ දින දර්ශනය දෙස බැලුවේ නැත්නම්, 90 දශකය මීට වසර 30 කට පමණ පෙරය. දැන් සෑම දෙයක්ම ටිකක් වෙනස් ලෙස සිදුවෙමින් පවතී. ඔවුන් ඔබට පවසන විට ඛේදවාචකයේ පරිමාණය සිතා ගැනීමට උත්සාහ කරන්න: “අපි නිෂ්පාදනයට යෙදෙව්වා, නමුත් එහි යමක් වැරදී ඇත. මෙන්න ඔබේ FTP පිවිසුම සහ මුරපදය, නිෂ්පාදනයට සම්බන්ධ වී ඉක්මනින් එය නිවැරදි කරන්න. ඔබ චක් නොරිස් නම්, මෙය සාර්ථක වනු ඇත. එසේ නොවේ නම්, ඔබ එක් දෝෂයක් නිවැරදි කළහොත්, ඔබ තවත් 10ක් සෑදීමේ අවදානමක් ඇත. පෙර අනුවාදයට පෙරළීමේ මෙම පුරුද්ද ඔබට බොහෝ දේ ලබා ගැනීමට ඉඩ සලසයි.
යම් ආකාරයක නරක දෙයක් කොතැනක හෝ ප්‍රෝඩාවට පත් වුවද, එය නරක ය, නමුත් මාරාන්තික නොවේ. ඔබට ඔබ සතුව ඇති පෙර අනුවාදය වෙත ආපසු යා හැක. එම පාරිභාෂිතය තුළ එය වටහා ගැනීම පහසු නම්, එය උපස්ථයක් ලෙස හඳුන්වන්න. ඔබට මෙම පෙර අනුවාදය වෙත ආපසු යා හැකි අතර, පරිශීලකයින්ට තවමත් ඔබේ නිෂ්පාදනය සමඟ වැඩ කිරීමට හැකි වනු ඇති අතර, ඔබට ප්‍රමාණවත් බෆර කාලයක් ඇත. ඔබට සන්සුන්ව, ඉක්මන් නොවී, මේ සියල්ල රැගෙන දේශීයව පරීක්ෂා කර, එය නිවැරදි කර, පසුව නව අනුවාදයක් උඩුගත කළ හැකිය. මෙය කිරීම ඇත්තෙන්ම අර්ථවත් කරයි.
දැන් අපි කලින් පුරුදු දෙක කෙසේ හෝ ඒකාබද්ධ කිරීමට උත්සාහ කරමු. අපිට Release Management කියලා තුන්වෙනි එකක් ලැබෙනවා.
Continuous Deployment එක ගැන සම්භාව්‍ය ස්වරූපයෙන් කතා කරනකොට අපි කියනවා repository එකෙන් යම් ශාඛාවකින් code ඇදලා compile කරලා deploy කරන්න ඕන කියලා. අපිටත් එහෙම පරිසරයක් තියෙනවා නම් හොඳයි. පරිසරයන් කිහිපයක් තිබේ නම්, මෙයින් අදහස් කරන්නේ එකම කැපවීමකින් වුවද අපි සෑම විටම කේතය ඇද ගත යුතු බවයි. අපි එය සෑම විටම පිටතට ඇද දමමු, අපි එය සෑම විටම ගොඩනඟමු, අපි එය නව පරිසරයකට යොදවන්නෙමු. පළමුව, මෙය කාලයයි, මන්ද ව්‍යාපෘතියක් තැනීමට, ඔබට විශාල එකක් තිබේ නම් සහ 90 දශකයේ සිට පැමිණියේ නම්, එයට පැය කිහිපයක් ගත විය හැකිය.
ඊට අමතරව තවත් දුකක් තියෙනවා. ඔබ ගොඩනඟන විට, එකම යන්ත්‍රයක වුවද, ඔබ එකම ප්‍රභවයන් ගොඩනඟනු ඇත, මෙම යන්ත්‍රය පසුගිය ගොඩනැගීමේදී තිබූ තත්වයේම පවතින බවට ඔබට තවමත් සහතිකයක් නොමැත.
අපි හිතමු කවුරුහරි ඇවිත් ඔබ වෙනුවෙන් DotNet යාවත්කාලීන කළා, එහෙමත් නැත්නම්, යම් කෙනෙක් යමක් මකා දැමීමට තීරණය කළා කියලා. එතකොට ඔයාලට cognitive dissonance තියෙනවා සති දෙකකට කලින් මේ කමිට් එකෙන් අපි බිල්ඩ් එකක් හැදුවා සේරම හරි ගියා, ඒත් දැන් පේන්නේ එකම මැෂින් එකයි, කමිට් එකයි, කෝඩ් එකයි අපි හදන්න හදනවා, ඒත් වැඩ කරන්නේ නෑ කියලා. . ඔබ මෙය සමඟ දිගු කලක් කටයුතු කරනු ඇති අතර එය ඔබ එය වටහා ගන්නා කරුණක් නොවේ. අවම වශයෙන්, ඔබ ඔබේ ස්නායු ගොඩක් නරක් වනු ඇත.
එබැවින්, නිදහස් කළමණාකරණ පරිචය මඟින් කෞතුක භාණ්ඩ ගබඩාවක් හෝ ගැලරියක් හෝ පුස්තකාලයක් ලෙස හැඳින්වෙන අතිරේක සාරාංශයක් හඳුන්වා දීමට යෝජනා කරයි. ඔබට අවශ්ය ඕනෑම දෙයක් එය අමතන්න.
ප්රධාන අදහස නම්, අපට යම් ආකාරයක කැපවීමක් ඇති වූ වහාම, අපගේ විවිධ පරිසරයන් වෙත යෙදවීමට අප සූදානම් ශාඛාවක, අපි මෙම කැපවීමෙන් අයදුම්පත් එකතු කර මෙම යෙදුම සඳහා අපට අවශ්ය සියල්ල, අපි එය ඇසුරුම් කරමු. zip ලේඛනාගාරයක් තුළට ගෙන එය විශ්වාසදායක ගබඩාවක සුරකින්න. තවද මෙම ගබඩාවෙන් අපට ඕනෑම අවස්ථාවක මෙම zip සංරක්ෂිතය ලබා ගත හැක.
එවිට අපි එය ගෙන එය ස්වයංක්‍රීයව dev පරිසරයට යොදවන්නෙමු. අපි එහි දුවන්නෙමු, සියල්ල හොඳ නම්, අපි වේදිකාවට යොදවන්නෙමු. සියල්ල හොඳින් නම්, අපි එකම ලේඛනාගාරය නිෂ්පාදනය සඳහා යොදවන්නෙමු, එකම ද්විමය, හරියටම එක් වරක් සම්පාදනය කරන්න.
මීට අමතරව, අපට මෙවැනි ගැලරියක් ඇති විට, එය පෙර අනුවාදයට ආපසු යාම ගැන කතා කළ විට අවසාන විනිවිදකයේ අප ආමන්ත්‍රණය කළ අවදානම් ආමන්ත්‍රණය කිරීමට ද එය උපකාරී වේ. ඔබ අහම්බෙන් යමක් වැරදි ලෙස යෙදවූයේ නම්, ඔබට සැම විටම මෙම ගැලරියෙන් වෙනත් ඕනෑම පෙර අනුවාදයක් ගෙන එය මෙම පරිසරයට ඒ ආකාරයෙන්ම ඉවත් කළ හැක. යමක් වැරදුනහොත් පෙර අනුවාදයට පහසුවෙන් ආපසු යාමට මෙය ඔබට ඉඩ සලසයි.
තවත් විශිෂ්ට පිළිවෙතක් තිබේ. අපි අපගේ යෙදුම් පෙර අනුවාදයකට ආපසු හරවන විට, මෙයින් අදහස් කරන්නේ අපට පෙර අනුවාදයේ යටිතල පහසුකම් ද අවශ්ය බව ඔබ සහ මම සියල්ලෝම තේරුම් ගනිමු.
Virtual infrastructure ගැන කතා කරනකොට ගොඩක් අය හිතන්නේ මේක ඇඩ්මින්ලා සෙට් කරන දෙයක් කියලා. ඔබට ඔබේ යෙදුමේ නව අනුවාදයක් පරීක්ෂා කිරීමට අවශ්ය නව සේවාදායකයක් ලබා ගැනීමට අවශ්ය නම්, ඔබ පරිපාලකයින්ට හෝ devops වෙත ටිකට් පතක් ලිවිය යුතුය. Devops මේ සඳහා සති 3ක් ගතවේ. සති 3 කට පසු ඔවුන් ඔබට කියනු ඇත, අපි ඔබ වෙනුවෙන් අථත්‍ය යන්ත්‍රයක් ස්ථාපනය කර ඇති අතර, එක් හරයක්, ගිගාබයිට් දෙකක RAM සහ ඩොට්නෙට් නොමැතිව වින්ඩෝස් සේවාදායකයක් සමඟ. ඔබ කියනවා: "නමුත් මට DotNet අවශ්ය විය." ඔවුන්: "හරි, සති 3කින් ආපහු එන්න."
අදහස වන්නේ යටිතල ව්‍යුහය කේත භාවිතයන් ලෙස භාවිතා කිරීමෙන්, ඔබට ඔබේ අතථ්‍ය යටිතල ව්‍යුහය තවත් සම්පතක් ලෙස සැලකිය හැකිය.
සමහර විට, ඔබගෙන් කවුරුහරි DotNet හි යෙදුම් සංවර්ධනය කරන්නේ නම්, ඔබ Entity Framework නම් පුස්තකාලයක් ගැන අසා ඇති. එන්ටිටි ෆ්‍රේම්වර්ක් යනු මයික්‍රොසොෆ්ට් ක්‍රියාකාරීව තල්ලු කරන එක් ප්‍රවේශයක් බව ඔබ අසා ඇති. දත්ත සමුදායක් සමඟ වැඩ කිරීම සඳහා, මෙය Code First ලෙස හඳුන්වන ප්රවේශයකි. මෙය ඔබ ඔබේ දත්ත සමුදාය දෙස බැලීමට අවශ්ය ආකාරය කේතයෙන් විස්තර කරන විටය. ඉන්පසු ඔබ යෙදුම යොදවන්න. එය දත්ත සමුදායට සම්බන්ධ කරයි, එහි ඇති වගු සහ නැති වගු එයම තීරණය කරයි, සහ ඔබට අවශ්ය සියල්ල නිර්මාණය කරයි.
ඔබේ යටිතල පහසුකම් සමඟද ඔබට එය කළ හැකිය. ඔබට ව්‍යාපෘතියක් සඳහා දත්ත සමුදායක් අවශ්‍යද යන්න හෝ ව්‍යාපෘතියක් සඳහා ඔබට වින්ඩෝස් සේවාදායකයක් අවශ්‍යද යන්න අතර වෙනසක් නැත. ඒක සම්පතක් විතරයි. ඔබට මෙම සම්පත නිර්මාණය කිරීම ස්වයංක්‍රීය කළ හැකිය, ඔබට මෙම සම්පතේ වින්‍යාසය ස්වයංක්‍රීය කළ හැකිය. ඒ අනුව, ඔබට යම් නව සංකල්පයක්, නව ප්‍රවේශයක් පරීක්ෂා කිරීමට අවශ්ය සෑම අවස්ථාවකම, ඔබට devops වෙත ටිකට් පතක් ලිවීමට අවශ්ය නොවනු ඇත, ඔබට සරලවම සූදානම් කළ සැකිලි වලින්, සූදානම් කළ ස්ක්‍රිප්ට් වලින් හුදකලා යටිතල පහසුකම් යෙදවිය හැකිය. ඔබේ සියලු අත්හදා බැලීම් තිබේ. ඔබට මෙය මකා දැමීමට, ප්‍රතිඵල කිහිපයක් ලබා ගැනීමට සහ ඒ පිළිබඳව වැඩිදුර වාර්තා කිරීමට හැකිය.
මීළඟ භාවිතය, පවතින සහ වැදගත්, නමුත් ස්වල්ප දෙනෙක් භාවිතා කරන, යෙදුම් කාර්ය සාධන අධීක්ෂණය වේ.
Application Performance Monitoring ගැන මට කියන්න ඕන වුනේ එක දෙයක් විතරයි. මෙම පිළිවෙතෙහි වඩාත්ම වැදගත් වන්නේ කුමක්ද? Application Performance Monitoring යනු මහල් නිවාසයක් අලුත්වැඩියා කිරීමට සමාන දෙයකි. මෙය අවසාන තත්වයක් නොවේ, එය ක්රියාවලියකි. ඔබ එය නිතිපතා කළ යුතුය.
හොඳ ආකාරයකින්, සෑම ගොඩනැගීමකම පාහේ යෙදුම් කාර්ය සාධන අධීක්ෂණය සිදු කිරීම හොඳ වනු ඇත, නමුත්, ඔබ තේරුම් ගත් පරිදි, මෙය සැමවිටම කළ නොහැකි ය. එහෙත්, අවම වශයෙන්, සෑම නිකුතුවක් සඳහාම එය සිදු කළ යුතුය.
එය වැදගත් වන්නේ ඇයි? මන්ද ඔබ හදිසියේම කාර්ය සාධනයේ පහත වැටීමක් අත්විඳින්නේ නම්, ඒ මන්දැයි ඔබ පැහැදිලිව තේරුම් ගත යුතුය. ඔබේ කණ්ඩායමට සති දෙකක ස්ප්‍රින්ට් තිබේ නම්, අවම වශයෙන් සෑම සති දෙකකට වරක්වත්, ඔබ පැහැදිලිව ස්ථාවර ප්‍රොසෙසරයක්, RAM, තැටි ආදිය ඇති වෙනම සේවාදායකයකට ඔබේ යෙදුම යෙදවිය යුතුය. එම කාර්ය සාධන පරීක්ෂණ ක්රියාත්මක කරන්න. . එහි ප්‍රතිඵලය ඔබට ලැබෙනවා. එය පෙර ස්ප්‍රින්ට් එකට වඩා වෙනස් වී ඇති ආකාරය බලන්න.
ඒවගේම යම් තැනක ඇද වැටීම තියුනු ලෙස පහත වැටී ඇති බව ඔබ සොයා ගන්නේ නම්, එයින් අදහස් වන්නේ එය පසුගිය සති දෙක තුළ සිදු වූ වෙනස්කම් නිසා බවයි. මෙමඟින් ඔබට ගැටලුව හඳුනා ගැනීමට සහ වඩා වේගයෙන් විසඳා ගැනීමට ඉඩ සලසයි. නැවතත්, මේවා ඔබ එය කෙතරම් සාර්ථකව කළාද යන්න මැනිය හැකි දළ වශයෙන් එකම ප්‍රමිතික වේ.
අපට ඇති මීළඟ පරිචය වන්නේ වින්යාස කළමනාකරණ පුහුණුවයි. මෙය බැරෑරුම් ලෙස සලකන අය ඉතා ස්වල්ප දෙනෙක් සිටිති. නමුත් මාව විශ්වාස කරන්න, මෙය ඇත්තෙන්ම ඉතා බරපතල දෙයක්.
පසුගිය දිනක හාස්‍යජනක කතාවක් ඇති විය. යාලුවනේ මා ළඟට ඇවිත් කිව්වා: "අපගේ අයදුම්පතේ ආරක්ෂක විගණනයක් කිරීමට අපට උදව් කරන්න." අපි දිගු වේලාවක් එකට කේතය දෙස බැලුවෙමු, ඔවුන් මට යෙදුම ගැන කිව්වා, රූප සටහන් ඇඳලා. සහ එකතු හෝ අඩු සෑම දෙයක්ම තාර්කික, තේරුම්ගත හැකි, ආරක්ෂිත, නමුත් එකක් තිබුනා නමුත්! ඔවුන්ගේ මූලාශ්‍ර පාලනයේ වින්යාස ගොනු, IP දත්ත සමුදාය සමඟින් නිෂ්පාදනය කරන ලද ඒවා, මෙම දත්ත සමුදායන් වෙත සම්බන්ධ වීම සඳහා පිවිසුම් සහ මුරපද ආදිය ඇතුළත් විය.
මම මෙසේ කියමි: “යාලුවනේ, හරි, ඔබ ඔබේ නිෂ්පාදන පරිසරය ෆයර්වෝලයකින් වසා ඇත, නමුත් ඔබට නිෂ්පාදන දත්ත ගබඩාව සඳහා පිවිසුම් සහ මුරපදය මූලාශ්‍ර පාලනය තුළම තිබීම සහ ඕනෑම සංවර්ධකයෙකුට එය කියවිය හැකි වීම දැනටමත් විශාල ආරක්ෂක අවදානමකි. . තවද ඔබගේ යෙදුම කේත දෘෂ්ටි කෝණයකින් කෙතරම් සුපිරි ආරක්ෂිත වුවත්, ඔබ එය මූලාශ්‍ර පාලනයේ තැබුවහොත්, ඔබ කිසිවිටෙක කොතැනකවත් කිසිදු විගණනයක් සමත් නොවනු ඇත. ඒකයි මම කතා කරන්නේ.
වින්යාස කළමනාකරණය. විවිධ පරිසරවල අපට විවිධ වින්‍යාසයන් තිබිය හැක. උදාහරණයක් ලෙස, QA, demo, නිෂ්පාදන පරිසරය ආදිය සඳහා දත්ත සමුදායන් සඳහා අපට විවිධ පිවිසුම් සහ මුරපද තිබිය හැක.
මෙම වින්‍යාසය ද ස්වයංක්‍රීය කළ හැක. එය සෑම විටම යෙදුමෙන් වෙන් විය යුතුය. ඇයි? ඔබ යෙදුම එක් වරක් ගොඩනඟා, පසුව ඔබ එවැනි සහ එවැනි IP හෝ එවැනි සහ එවැනි IP එකක් හරහා SQL සේවාදායකයට සම්බන්ධ වන්නේද යන්න යෙදුම ගණන් නොගන්නා නිසා, එය එලෙසම ක්‍රියා කළ යුතුය. ඒ නිසා, හදිස්සියේම ඔයාලාගෙන් කෙනෙක් තවම code එකේ connection string එක hardcoding කරන්නේ නම්, මතක තියාගන්න මම ඔයාව හොයාගෙන ඔයා මාත් එක්ක එකම project එකක ඉන්නවා නම් ඔයාට දඬුවම් කරන්නම් කියලා. මෙය සැමවිටම වෙනම වින්‍යාසයක තබා ඇත, උදාහරණයක් ලෙස, web.config හි.
තවද මෙම වින්‍යාසය දැනටමත් වෙන වෙනම කළමනාකරණය කර ඇත, එනම් සංවර්ධකයෙකුට සහ පරිපාලකයෙකුට පැමිණ එකම කාමරයක වාඩි විය හැකි මොහොත මෙයයි. සංවර්ධකයාට මෙසේ පැවසිය හැකිය: "බලන්න, මෙන්න මගේ යෙදුමේ ද්විමය. ඔවුන් වැඩ කරනවා. යෙදුමට වැඩ කිරීමට දත්ත සමුදායක් අවශ්ය වේ. මෙන්න බයිනරි වලට එහා පැත්තේ ෆයිල් එකක් තියෙනවා. මෙම ගොනුවේ, මෙම ක්ෂේත්රය පිවිසුම සඳහා වගකිව යුතු වේ, මෙය මුරපදය සඳහා, මෙය IP සඳහා වේ. එය ඕනෑම තැනක යොදවන්න." තවද එය පරිපාලකයාට සරල සහ පැහැදිලිය. මෙම වින්‍යාසය කළමනාකරණය කිරීමෙන් ඔහුට එය සැබවින්ම ඕනෑම තැනක යෙදවිය හැක.
ඒ වගේම මම කතා කරන්න කැමති අන්තිම පුරුද්ද වලාකුළු වලට ගොඩක් සම්බන්ධ පුරුද්දක්. ඔබ වලාකුළෙහි වැඩ කරන්නේ නම් එය උපරිම බලපෑමක් ඇති කරයි. මෙය ඔබගේ පරිසරය ස්වයංක්‍රීයව ඉවත් කිරීමකි.
මම දන්නවා මම වැඩ කරන කණ්ඩායම්වල කිහිප දෙනෙක් මේ සමුළුවේ ඉන්නවා. මම වැඩ කරන සියලුම කණ්ඩායම් සමඟ, අපි මෙම පුහුණුව භාවිතා කරමු.
ඇයි? ඇත්ත වශයෙන්ම, සෑම සංවර්ධකයෙකුටම 24/7 ක්‍රියා කරන අථත්‍ය යන්ත්‍රයක් තිබේ නම් එය ඉතා හොඳ වනු ඇත. නමුත් සමහර විට මෙය ඔබට ප්‍රවෘත්තියක් විය හැකිය, සමහර විට ඔබ අවධානය යොමු නොකළ නමුත් සංවර්ධකයාම 24/7 ක්‍රියා නොකරයි. සංවර්ධකයෙකු සාමාන්යයෙන් දිනකට පැය 8 ක් වැඩ කරයි. ඔහු වේලාසනින් වැඩට පැමිණියද, ඔහු ජිම් එකට යන අතරතුර විශාල දිවා ආහාරය ගනී. සංවර්ධකයා ඇත්ත වශයෙන්ම මෙම සම්පත් භාවිතා කරන විට එය දිනකට පැය 12 ක් වීමට ඉඩ දෙන්න. අපගේ ව්‍යවස්ථාවට අනුව සතියකට දින 5න් 7ක් වැඩ කරන දින ලෙස සැලකේ.
ඒ අනුව සතියේ දිනවල මෙම යන්ත්‍රය පැය 24ක් ක්‍රියා නොකර පැය 12ක් පමණක් ක්‍රියා කළ යුතු අතර සති අන්තයේ මෙම යන්ත්‍රය කිසිසේත්ම ක්‍රියා නොකළ යුතුය. සෑම දෙයක්ම ඉතා සරල බව පෙනේ, නමුත් මෙහි පැවසීමට වැදගත් වන්නේ කුමක්ද? මෙම මූලික කාලසටහනට අනුව මෙම සරල භාවිතය ක්රියාත්මක කිරීමෙන්, මෙම පරිසරයන් නඩත්තු කිරීමේ පිරිවැය 70% කින් අඩු කිරීමට ඔබට ඉඩ සලසයි, එනම් ඔබ ඔබේ dev, QA, demo, පරිසරයේ මිල ගෙන එය 3 න් බෙදුවා.
ප්රශ්නය වන්නේ, ඉතිරි මුදල් සමඟ කුමක් කළ යුතුද? උදාහරණයක් ලෙස, සංවර්ධකයින් ඔවුන් දැනටමත් නොමැති නම් ReSharper මිලදී ගත යුතුය. නැත්නම් කොක්ටේල් පාටියක් ගන්න. ඔබට මීට පෙර dev සහ QA යන දෙකම තෘප්තිමත් කළ එක් පරිසරයක් තිබුනේ නම්, එය එයයි, දැන් ඔබට හුදකලා වන විවිධ ඒවා 3 ක් සෑදිය හැකි අතර මිනිසුන් එකිනෙකාට බාධා නොකරනු ඇත.
අඛණ්ඩ කාර්ය සාධනය මැනීම සහිත විනිවිදකය සම්බන්ධයෙන්, ව්‍යාපෘතියේ දත්ත ගබඩාවේ වාර්තා 1 ක් තිබුනේ නම්, මාස දෙකකට පසුව මිලියනයක් තිබේ නම්, කාර්ය සාධනය සැසඳිය හැක්කේ කෙසේද? ඇයි සහ කාර්ය සාධනය මැනීමේ කාරණය කුමක්ද යන්න තේරුම් ගන්නේ කෙසේද?
මෙය හොඳ ප්‍රශ්නයකි, මන්ද ඔබ සැමවිටම එකම සම්පත් මත කාර්ය සාධනය මැනිය යුතුය. එනම්, ඔබ නව කේතයක් නිකුත් කරයි, ඔබ නව කේතයේ කාර්ය සාධනය මනිනු ඇත. උදාහරණයක් ලෙස, ඔබට විවිධ කාර්ය සාධන අවස්ථා පරීක්ෂා කිරීමට අවශ්ය වේ, පරිශීලකයින් 1 ක් සිටින සහ දත්ත සමුදායේ ප්‍රමාණය ගිගාබයිට් 000 ක් වන සැහැල්ලු බරක් මත යෙදුම ක්‍රියා කරන ආකාරය පරීක්ෂා කිරීමට ඔබට අවශ්ය යැයි සිතමු. ඔබ එය මැන බලා අංක ලබා ගත්තා. ඊළඟට අපි තවත් දර්ශනයක් ගනිමු. උදාහරණයක් ලෙස, පරිශීලකයින් 5 ක්, දත්ත සමුදායේ විශාලත්වය 5 ටෙරාබයිට්. ප්‍රතිඵල ලැබිලා අපි ඒවා මතක් කළා.
මෙහි වැදගත් වන්නේ කුමක්ද? මෙහි ඇති වැදගත්ම දෙය නම් දර්ශනය, දත්ත පරිමාව, එකවර භාවිතා කරන්නන් සංඛ්‍යාව යනාදිය මත පදනම්ව, ඔබට යම් සීමාවන් කරා දිව යා හැකිය. උදාහරණයක් ලෙස, ජාල කාඩ්පතක සීමාවට හෝ දෘඪ තැටියක සීමාවට හෝ ප්රොසෙසර් හැකියාවන්ගේ සීමාවට. ඔබ තේරුම් ගැනීමට වැදගත් වන්නේ මෙයයි. විවිධ අවස්ථා වලදී ඔබ යම් සීමාවන් කරා දිව යයි. අනික ගහනකොට ගණන් තේරුම් ගන්න ඕන.
අපි විශේෂ පරීක්ෂණ පරිසරයක් තුළ කාර්ය සාධනය මැනීම ගැන කතා කරනවාද? එනම් මෙය නිෂ්පාදනයක් නොවේද?
ඔව්, මෙය නිෂ්පාදනයක් නොවේ, මෙය පරීක්ෂණ පරිසරයකි, එය ඔබට පෙර මිනුම් සමඟ සැසඳිය හැකි වන පරිදි සෑම විටම සමාන වේ.
තේරුනා ස්තුතියි!
ප්‍රශ්න නැත්නම් ඉවර කරන්න පුළුවන් කියලා හිතනවා. ඔයාට ස්තූතියි!
මූලාශ්රය: www.habr.com