DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය

1 කොටස: Web/Android

අදහස් දැක්වීම්: මෙම ලිපිය මුල් ලිපියේ රුසියානු භාෂාවට පරිවර්තනයකි “DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. "මුල සිට පරීක්ෂණ ස්වයංක්‍රීය යටිතල පහසුකම් ගොඩනැගීම." කෙසේ වෙතත්, රුසියානු භාෂාවට පරිවර්තනය කිරීමේදී අර්ථය විකෘති වීම වළක්වා ගැනීම සඳහා සියලුම නිදර්ශන, සබැඳි, උපුටා දැක්වීම් සහ නියමයන් මුල් භාෂාවෙන් සංරක්ෂණය කර ඇත. මම ඔබට සතුටින් ඉගෙනීමට ප්‍රාර්ථනා කරමි!

DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය

දැනට, DevOps විශේෂත්වය තොරතුරු තාක්ෂණ කර්මාන්තයේ වැඩිම ඉල්ලුමක් ඇති එකකි. ඔබ ජනප්‍රිය රැකියා සෙවුම් අඩවි විවෘත කර වැටුප් අනුව පෙරහන් කළහොත්, DevOps සම්බන්ධ රැකියා ලැයිස්තුවේ ඉහළින්ම ඇති බව ඔබට පෙනෙනු ඇත. කෙසේ වෙතත්, මෙය ප්‍රධාන වශයෙන් 'ජ්‍යෙෂ්ඨ' තනතුරකට යොමු වන බව වටහා ගැනීම වැදගත් වන අතර, එයින් ඇඟවෙන්නේ අපේක්ෂකයාට ඉහළ මට්ටමේ කුසලතා, තාක්‍ෂණය සහ මෙවලම් පිළිබඳ දැනුමක් ඇති බවයි. මෙය නිෂ්පාදනයේ අඛණ්ඩ ක්‍රියාකාරිත්වය හා සම්බන්ධ ඉහළ වගකීමක් සමඟ ද පැමිණේ. කෙසේ වෙතත්, අපි DevOps යනු කුමක්දැයි අමතක කිරීමට පටන් ගත්තෙමු. මුලදී, එය විශේෂිත පුද්ගලයෙකු හෝ දෙපාර්තමේන්තුවක් නොවීය. අපි මෙම පදයේ නිර්වචන සොයන්නේ නම්, ක්‍රමවේදය, භාවිතයන්, සංස්කෘතික දර්ශනය, සංකල්ප සමූහය, යනාදී බොහෝ ලස්සන හා නිවැරදි නාම පද අපට හමුවනු ඇත.

මගේ විශේෂීකරණය පරීක්ෂණ ස්වයංක්‍රීය ඉංජිනේරුවෙකු (QA ස්වයංක්‍රීය ඉංජිනේරුවෙකු) වේ, නමුත් එය ස්වයංක්‍රීය පරීක්ෂණ ලිවීම හෝ පරීක්ෂණ රාමු ගෘහ නිර්මාණ ශිල්පය සංවර්ධනය කිරීම සමඟ පමණක් සම්බන්ධ නොවිය යුතු බව මම විශ්වාස කරමි. 2020 දී ස්වයංක්‍රීය යටිතල පහසුකම් පිළිබඳ දැනුම ද අත්‍යවශ්‍ය වේ. මෙය ඔබට ස්වයංක්‍රීය ක්‍රියාවලිය ඔබ විසින්ම සංවිධානය කිරීමට ඉඩ සලසයි, පරීක්ෂණ ධාවනයේ සිට ඔබගේ ඉලක්ක වලට අනුකූලව සියලුම පාර්ශවකරුවන්ට ප්‍රතිඵල ලබා දීම දක්වා. එහි ප්‍රතිඵලයක් වශයෙන්, කාර්යය ඉටු කිරීමට DevOps කුසලතා අත්‍යවශ්‍ය වේ. මේ සියල්ල හොඳයි, නමුත්, අවාසනාවකට, ගැටලුවක් තිබේ (spoiler: මෙම ලිපිය මෙම ගැටලුව සරල කිරීමට උත්සාහ කරයි) කාරණය වන්නේ DevOps අමාරුයි. ඒවගේම මේක පැහැදිලියි, මොකද කරන්න පහසු දෙයක් සඳහා සමාගම් විශාල මුදලක් ගෙවන්නේ නැහැ... DevOps ලෝකයේ, ප්‍රගුණ කළ යුතු මෙවලම්, නියමයන් සහ භාවිතයන් විශාල ප්‍රමාණයක් තිබෙනවා. වෘත්තීය ජීවිතය ආරම්භයේදී මෙය විශේෂයෙන් දුෂ්කර වන අතර සමුච්චිත තාක්ෂණික අත්දැකීම් මත රඳා පවතී.

DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය
මූලාශ්රය: http://maximelanciauxbi.blogspot.com/2017/04/devops-tools.html

මෙන්න අපි බොහෝ විට ආරම්භක කොටස සමඟ අවසන් කර මෙම ලිපියේ අරමුණ කෙරෙහි අවධානය යොමු කරමු. 

මෙම ලිපිය කුමක් ගැනද?

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

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

මෙම ලිපියේ නොමැති දේ

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

මෙය සිදු කරනුයේ: 

  • මෙම ද්රව්ය විවිධ මූලාශ්රවල (ලේඛන, පොත්, වීඩියෝ පාඨමාලා) සොයා ගැනීම ඉතා පහසුය;
  • අපි ගැඹුරට යාමට පටන් ගන්නේ නම්, අපට මෙම ලිපියේ කොටස් 10, 20, 30 ලිවීමට සිදුවනු ඇත (සැලසුම් 2-3 අතර);
  • එකම අරමුණු සාක්ෂාත් කර ගැනීම සඳහා ඔබට වෙනත් මෙවලම් භාවිතා කිරීමට අවශ්‍ය විය හැකි බැවින් මට ඔබේ කාලය නාස්ති කිරීමට අවශ්‍ය නැත.

පුහුණු වන්න

මෙම තොරතුරු සෑම පාඨකයෙකුටම ප්‍රයෝජනවත් වීමටත්, කියවා අමතක කර දැමීමටත් මම ඇත්තෙන්ම කැමතියි. ඕනෑම අධ්‍යයනයක දී, පුහුණුව ඉතා වැදගත් අංගයකි. මේ සඳහා මම සූදානම් කර ඇත මුල සිටම සියල්ල කරන්නේ කෙසේද යන්න පිළිබඳ පියවරෙන් පියවර උපදෙස් සහිත GitHub ගබඩාව. ඔබ ක්‍රියාත්මක කරන විධානවල රේඛා සිහිකල්පනාවෙන් තොරව පිටපත් නොකරන බවට වග බලා ගැනීම සඳහා ඔබ බලා සිටින ගෙදර වැඩද ඇත.

සැලැස්ම

පියවර
තාක්ෂණ
මෙවලම්

1
දේශීය ධාවනය (වෙබ් / ඇන්ඩ්‍රොයිඩ් ආදර්ශන පරීක්ෂණ සූදානම් කර එය දේශීයව ධාවනය කරන්න) 
Node.js, Selenium, Appium

2
අනුවාද පාලන පද්ධති 
Git

3
බහාලුම්කරණය
ඩොකර්, සෙලේනියම් ග්‍රිඩ්, සෙලිනොයිඩ් (වෙබ්, ඇන්ඩ්‍රොයිඩ්)

4
CI/CD
Gitlab CI

5
වලාකුළු වේදිකා
Google වලාකුළු වේදිකාව

6
වාද්‍ය වෘන්දය
කුබර්නෙට්ස්

7
කේතයක් ලෙස යටිතල පහසුකම් (IaC)
ටෙරාෆෝම්, ඇන්සිබල්

එක් එක් කොටසෙහි ව්යුහය

ආඛ්‍යානය පැහැදිලිව තබා ගැනීම සඳහා, එක් එක් කොටස පහත දළ සටහනට අනුව විස්තර කෙරේ:

  • තාක්ෂණය පිළිබඳ කෙටි විස්තරයක්,
  • ස්වයංක්‍රීය යටිතල පහසුකම් සඳහා වටිනාකම,
  • යටිතල පහසුකම්වල වත්මන් තත්ත්වය පිළිබඳ නිදර්ශනය,
  • අධ්යයනය සඳහා සබැඳි,
  • සමාන මෙවලම්.

1. දේශීයව පරීක්ෂණ පවත්වන්න

තාක්ෂණය පිළිබඳ කෙටි විස්තරයක්

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

කෙසේ වෙතත්, ස්වයංක්‍රීය මෙවලම් ලෙස, මම පිළිවෙලින් වෙබ් වේදිකා සඳහා Selenium WebDriver සහ Android වේදිකාව සඳහා Appium භාවිතා කිරීම නිර්දේශ කරමි, මන්ද ඊළඟ පියවරේදී අපි මෙම මෙවලම් සමඟ විශේෂයෙන් ක්‍රියා කිරීමට ගැලපෙන පරිදි සකස් කරන ලද Docker පින්තූර භාවිතා කරමු. එපමණක් නොව, රැකියා අවශ්‍යතා ගැන සඳහන් කරමින්, මෙම මෙවලම් වෙළඳපොලේ වැඩිම ඉල්ලුමක් පවතී.

ඔබ දැක ඇති පරිදි, අපි සලකන්නේ වෙබ් සහ ඇන්ඩ්‍රොයිඩ් පරීක්ෂණ පමණි. අවාසනාවකට, iOS සම්පූර්ණයෙන්ම වෙනස් කතාවකි (ඇපල් ස්තුතියි). IOS සම්බන්ධ විසඳුම් සහ භාවිතයන් ඉදිරි කොටස්වල ප්‍රදර්ශනය කිරීමට මම අදහස් කරමි.

ස්වයංක්රීය යටිතල පහසුකම් සඳහා වටිනාකම

යටිතල පහසුකම් ඉදිරිදර්ශනයකින්, දේශීයව ධාවනය කිරීම කිසිදු වටිනාකමක් ලබා නොදේ. ඔබ පරීක්ෂා කරන්නේ දේශීය බ්‍රව්සර් සහ සිමියුලේටර්වල දේශීය යන්ත්‍රය මත පරීක්ෂණ ක්‍රියාත්මක වන බව පමණි. නමුත් ඕනෑම අවස්ථාවක, මෙය අවශ්ය ආරම්භක ලක්ෂ්යයකි.

යටිතල පහසුකම්වල වත්මන් තත්ත්වය පිළිබඳ නිදර්ශනය

DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය

ගවේෂණය කිරීමට සබැඳි

සමාන මෙවලම්

  • Selenium/Appium පරීක්ෂණ සමඟින් ඔබ කැමති ඕනෑම ක්‍රමලේඛන භාෂාවක්;
  • ඕනෑම පරීක්ෂණ;
  • ඕනෑම ටෙස්ට් ධාවකයෙක්.

2. අනුවාද පාලන පද්ධති (Git)

තාක්ෂණය පිළිබඳ කෙටි විස්තරයක්

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

ස්වයංක්රීය යටිතල පහසුකම් සඳහා වටිනාකම

මෙහිදී ඔබට සාධාරණ ප්‍රශ්නයක් ඇසිය හැකිය: “ඇයි ඔහු අපට Git ගැන කියන්නේ? හැමෝම මෙය දන්නා අතර එය සංවර්ධන කේතය සහ ස්වයංක්‍රීය පරීක්ෂණ කේතය සඳහා භාවිතා කරයි. ඔබ සම්පුර්ණයෙන්ම නිවැරදි වනු ඇත, නමුත් මෙම ලිපියෙන් අපි යටිතල පහසුකම් ගැන කතා කරන අතර මෙම කොටස 7 වන කොටස සඳහා පෙරදසුනක් ලෙස ක්‍රියා කරයි: "යටිතල පහසුකම් කේතය ලෙස (IaC)". අපට, මෙයින් අදහස් කරන්නේ පරීක්ෂණ ඇතුළු සමස්ත යටිතල පහසුකම් කේත ආකාරයෙන් විස්තර කර ඇති බවයි, එබැවින් අපට එයට අනුවාද පද්ධති යෙදිය හැකි අතර සංවර්ධන සහ ස්වයංක්‍රීය කේතය සඳහා සමාන ප්‍රතිලාභ ලබා ගත හැකිය.

අපි පියවර 7 හි IaC වඩාත් විස්තරාත්මකව බලමු, නමුත් දැන් පවා ඔබට දේශීය ගබඩාවක් සෑදීමෙන් Git දේශීයව භාවිතා කිරීම ආරම්භ කළ හැකිය. අපි යටිතල පහසුකම් සඳහා දුරස්ථ ගබඩාවක් එකතු කරන විට විශාල පින්තූරය පුළුල් වනු ඇත.

යටිතල පහසුකම්වල වත්මන් තත්ත්වය පිළිබඳ නිදර්ශනය

DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය

ගවේෂණය කිරීමට සබැඳි

සමාන මෙවලම්

3. බහාලුම්කරණය (ඩොකර්)

තාක්ෂණය පිළිබඳ කෙටි විස්තරයක්

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

පරිණාමයේ මීළඟ අදියර වූයේ අතථ්‍ය යන්ත්‍ර (VMs) වන අතර එමඟින් භාවිතයට නොගත් සම්පත් මත මුදල් නාස්ති කිරීමේ ගැටලුව විසඳා ඇත. මෙම තාක්‍ෂණය මගින් සම්පූර්ණයෙන්ම හුදකලා ඉඩක් වෙන්කරමින් එකම සේවාදායකයක් තුළ යෙදුම් එකිනෙකින් ස්වාධීනව ක්‍රියාත්මක කිරීමට හැකි විය. එහෙත්, අවාසනාවකට මෙන්, ඕනෑම තාක්ෂණයකට එහි අවාසි ඇත. VM එකක් ධාවනය කිරීම සඳහා සම්පූර්ණ මෙහෙයුම් පද්ධතියක් අවශ්‍ය වන අතර, CPU, RAM, ගබඩා කිරීම සහ OS මත පදනම්ව බලපත්‍ර පිරිවැය සැලකිල්ලට ගත යුතුය. මෙම සාධක පැටවීමේ වේගයට බලපාන අතර අතේ ගෙන යා හැකි අපහසුතා ඇති කරයි.

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

ඇත්ත වශයෙන්ම, බහාලුම් තාක්ෂණය අලුත් දෙයක් නොවන අතර එය මුලින්ම හඳුන්වා දුන්නේ 70 දශකයේ අගභාගයේදීය. ඒ දවස්වල බොහෝ පර්යේෂණ, වර්ධනයන් සහ උත්සාහයන් සිදු කරන ලදී. නමුත් මෙම තාක්ෂණය අනුවර්තනය කර ජනතාවට පහසුවෙන් ප්‍රවේශ විය හැකි ලෙස සකස් කළේ ඩොකර් විසිනි. වර්තමානයේ කන්ටේනර් ගැන කතා කරන විට බොහෝ අවස්ථාවලදී අපි අදහස් කරන්නේ ඩොකර් යන්නයි. අපි Docker බහාලුම් ගැන කතා කරන විට, අපි ලිනක්ස් බහාලුම් අදහස් කරමු. බහාලුම් ධාවනය කිරීම සඳහා අපට වින්ඩෝස් සහ මැකෝස් පද්ධති භාවිතා කළ හැකිය, නමුත් මෙම අවස්ථාවේ දී අතිරේක තට්ටුවක් දිස්වන බව තේරුම් ගැනීම වැදගත්ය. උදාහරණයක් ලෙස, Mac හි ඩොකර් සැහැල්ලු Linux VM තුළ බහාලුම් නිහඬව ධාවනය කරයි. බහාලුම් තුළ ඇන්ඩ්‍රොයිඩ් ඉමුලේටර් ධාවනය කිරීම ගැන සාකච්ඡා කරන විට අපි මෙම මාතෘකාවට ආපසු යන්නෙමු, එබැවින් මෙහි වඩාත් විස්තරාත්මකව සාකච්ඡා කළ යුතු ඉතා වැදගත් සූක්ෂ්මතාවයක් තිබේ.

ස්වයංක්රීය යටිතල පහසුකම් සඳහා වටිනාකම

බහාලුම්කරණය සහ ඩොකර් සිසිල් බව අපි සොයා ගත්තෙමු. ස්වයංක්‍රීයකරණයේ සන්දර්භය තුළ මෙය බලමු, මන්ද සෑම මෙවලමක් හෝ තාක්‍ෂණයක් ගැටළුවක් විසඳීමට අවශ්‍ය වේ. UI පරීක්ෂණවල සන්දර්භය තුළ පරීක්ෂණ ස්වයංක්‍රීයකරණයේ පැහැදිලි ගැටළු අපි ගෙනහැර දක්වමු:

  • Selenium සහ විශේෂයෙන්ම Appium ස්ථාපනය කිරීමේදී පරායත්තතා විශාල සංඛ්යාවක්;
  • බ්‍රව්සර්, සිමියුලේටර් සහ ධාවක අනුවාද අතර අනුකූලතා ගැටළු;
  • සමාන්තර ධාවනය සඳහා විශේෂයෙන් වැදගත් වන බ්‍රව්සර්/සිමියුලේටර් සඳහා හුදකලා ඉඩක් නොමැතිකම;
  • ඔබට එකවර බ්‍රව්සර් 10, 50, 100 හෝ 1000 ක් ධාවනය කිරීමට අවශ්‍ය නම් කළමනාකරණය කිරීමට සහ නඩත්තු කිරීමට අපහසුය.

නමුත් Selenium වඩාත්ම ජනප්‍රිය ස්වයංක්‍රීය මෙවලම වන අතර Docker වඩාත් ජනප්‍රිය බහාලුම් මෙවලම වන බැවින්, ඉහත සඳහන් ගැටළු විසඳීම සඳහා ප්‍රබල මෙවලමක් නිර්මාණය කිරීමට යමෙකු ඒවා ඒකාබද්ධ කිරීමට උත්සාහ කිරීම පුදුම විය යුතු නැත. එවැනි විසඳුම් වඩාත් විස්තරාත්මකව සලකා බලමු. 

ඩොකර්හි සෙලේනියම් ජාලකය

මෙම මෙවලම බහු යන්ත්‍රවල බහු බ්‍රව්සර් ධාවනය කිරීම සහ මධ්‍යම කේන්ද්‍රස්ථානයකින් ඒවා කළමනාකරණය කිරීම සඳහා සෙලේනියම් ලෝකයේ වඩාත්ම ජනප්‍රිය වේ. ආරම්භ කිරීමට, ඔබ අවම වශයෙන් කොටස් 2ක් ලියාපදිංචි කළ යුතුය: Hub සහ Node(s). Hub යනු පරීක්ෂණ වලින් සියලුම ඉල්ලීම් ලබා ගන්නා මධ්‍යම නෝඩයක් වන අතර ඒවා සුදුසු නෝඩ් වෙත බෙදා හරිනු ලැබේ. එක් එක් නෝඩ් සඳහා අපට නිශ්චිත වින්‍යාසයක් වින්‍යාසගත කළ හැකිය, උදාහරණයක් ලෙස, අපේක්ෂිත බ්‍රව්සරය සහ එහි අනුවාදය නියම කිරීමෙන්. කෙසේ වෙතත්, අපි තවමත් ගැළපෙන බ්‍රව්සර් ධාවක ගැන සැලකිලිමත් විය යුතු අතර ඒවා අපේක්ෂිත නෝඩ් වල ස්ථාපනය කළ යුතුය. මෙම හේතුව නිසා, Linux OS හි ස්ථාපනය කළ නොහැකි බ්‍රව්සර් සමඟ වැඩ කිරීමට අවශ්‍ය විට හැර, Selenium ජාලය එහි පිරිසිදු ස්වරූපයෙන් භාවිතා නොවේ. අනෙකුත් සියලුම අවස්ථාවන් සඳහා, සැලකිය යුතු ලෙස නම්‍යශීලී සහ නිවැරදි විසඳුමක් වනුයේ Selenium grid Hub සහ Nodes ධාවනය කිරීමට Docker රූප භාවිතා කිරීමයි. දැනටමත් ස්ථාපනය කර ඇති බ්‍රව්සර් සහ ධාවකවල අනුකූල අනුවාද සමඟ අපට අවශ්‍ය රූපය තෝරා ගත හැකි බැවින් මෙම ප්‍රවේශය නෝඩ් කළමනාකරණය බෙහෙවින් සරල කරයි.

ස්ථාවරත්වය පිළිබඳ සෘණාත්මක සමාලෝචන තිබියදීත්, විශේෂයෙන්ම නෝඩ් විශාල සංඛ්‍යාවක් සමාන්තරව ක්‍රියාත්මක වන විට, සෙලේනියම් ග්‍රිඩ් තවමත් සෙලේනියම් පරීක්ෂණ සමාන්තරව ක්‍රියාත්මක කිරීම සඳහා වඩාත් ජනප්‍රිය මෙවලම වේ. මෙම මෙවලමෙහි විවිධ වැඩිදියුණු කිරීම් සහ වෙනස් කිරීම් විවිධ බාධක වලට එරෙහිව සටන් කරන විවෘත මූලාශ්‍රවල නිරන්තරයෙන් දිස්වන බව සැලකිල්ලට ගැනීම වැදගත්ය.

වෙබ් සඳහා Selenoid

මෙම මෙවලම සෙලේනියම් ලෝකයේ ඉදිරි ගමනක් වන අතර එය පෙට්ටියෙන් පිටත ක්‍රියා කරන අතර බොහෝ ස්වයංක්‍රීය ඉංජිනේරුවන්ගේ ජීවිතය වඩාත් පහසු කර ඇත. පළමුවෙන්ම, මෙය සෙලේනියම් ජාලයේ තවත් වෙනස් කිරීමක් නොවේ. ඒ වෙනුවට, සංවර්ධකයින් විසින් Golang හි Selenium Hub හි සම්පූර්ණයෙන්ම නව අනුවාදයක් නිර්මාණය කරන ලද අතර, විවිධ බ්‍රව්සර් සඳහා සැහැල්ලු ඩොකර් රූප සමඟ ඒකාබද්ධව, පරීක්ෂණ ස්වයංක්‍රීයකරණයේ වර්ධනයට උත්තේජනයක් ලබා දුන්නේය. එපමනක් නොව, Selenium Grid සම්බන්ධයෙන්, අපි අවශ්ය සියලුම බ්රවුසර සහ ඒවායේ අනුවාදයන් කල්තියා තීරණය කළ යුතුය, එක් බ්රවුසරයක් සමඟ පමණක් වැඩ කිරීමේදී ගැටළුවක් නොවේ. නමුත් බහුවිධ සහය දක්වන බ්‍රව්සර් සම්බන්ධයෙන් ගත් කල, එහි 'ඉල්ලුම මත බ්‍රව්සරය' විශේෂාංගයට ස්තූතිවන්ත වන පරිදි සෙලිනොයිඩ් අංක එකේ විසඳුමයි. අපට අවශ්‍ය වන්නේ බ්‍රව්සර් සමඟ අවශ්‍ය පින්තූර කල්තියා බාගත කර සෙලිනොයිඩ් අන්තර්ක්‍රියා කරන වින්‍යාස ගොනුව යාවත්කාලීන කිරීමයි. Selenoid හට පරීක්ෂණ වලින් ඉල්ලීමක් ලැබුණු පසු, එය අවශ්ය බ්රවුසරය සමඟ අවශ්ය බහාලුම ස්වයංක්රීයව දියත් කරනු ඇත. පරීක්ෂණය අවසන් වූ විට, Selenoid කන්ටේනරය ඉවත් කර, අනාගත ඉල්ලීම් සඳහා සම්පත් නිදහස් කරයි. මෙම ප්‍රවේශය සෙලේනියම් ග්‍රිඩ් වලදී අපට නිතර හමුවන 'නෝඩ් ක්ෂය වීමේ' ප්‍රසිද්ධ ගැටලුව සම්පූර්ණයෙන්ම ඉවත් කරයි.

එහෙත්, අහෝ, සෙලෙනොයිඩ් තවමත් රිදී උණ්ඩයක් නොවේ. අපට 'බ්‍රවුසරය ඉල්ලුම මත' විශේෂාංගය ලැබී ඇත, නමුත් 'ඉල්ලුම මත සම්පත්' විශේෂාංගය තවමත් නොමැත. Selenoid භාවිතා කිරීමට, අපි එය භෞතික දෘඪාංග මත හෝ VM මත යෙදවිය යුතුය, එයින් අදහස් කරන්නේ කොපමණ සම්පත් වෙන් කළ යුතුද යන්න අප කලින් දැන සිටිය යුතු බවයි. බ්‍රව්සර් 10ක්, 20ක් හෝ 30ක් සමාන්තරව ක්‍රියාත්මක වන කුඩා ව්‍යාපෘති සඳහා මෙය ගැටලුවක් නොවන බව මම අනුමාන කරමි. නමුත් අපට 100, 500, 1000 හෝ ඊට වැඩි අවශ්ය නම්? මෙතරම් සම්පත් ප්‍රමාණයක් නිරතුරුව නඩත්තු කිරීම හා ගෙවීම තේරුමක් නැත. මෙම ලිපියේ 5 සහ 6 වගන්තිවල, අපි ඔබට පරිමාණය කිරීමට ඉඩ සලසන විසඳුම් සාකච්ඡා කරනු ඇත, එමගින් සමාගම් පිරිවැය සැලකිය යුතු ලෙස අඩු කරයි.

Android සඳහා Selenoid

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

මෙම මෙවලමෙහි negative ණාත්මක පැති ගැන කතා කිරීමට මම ඇත්තෙන්ම කැමති නැත, මන්ද මම එයට ඇත්තෙන්ම කැමතියි. නමුත් තවමත්, වෙබ් ස්වයංක්‍රීයකරණයට අදාළ වන සහ පරිමාණය සමඟ සම්බන්ධ වන එකම අවාසි ඇත. මීට අමතරව, අපි පළමු වරට මෙවලම සකස් කරන්නේ නම් පුදුමයට පත් විය හැකි තවත් එක් සීමාවක් ගැන කතා කළ යුතුය. Android රූප ධාවනය කිරීමට, අපට කැදලි අථත්‍යකරණ සහාය සහිත භෞතික යන්ත්‍රයක් හෝ VM අවශ්‍ය වේ. කෙසේද යන්න මාර්ගෝපදේශය තුළ, Linux VM එකක මෙය සක්‍රීය කරන්නේ කෙසේදැයි මම නිරූපණය කරමි. කෙසේ වෙතත්, ඔබ macOS පරිශීලකයෙකු නම් සහ Selenoid දේශීයව යෙදවීමට අවශ්‍ය නම්, මෙය Android පරීක්ෂණ ධාවනය කිරීමට නොහැකි වනු ඇත. නමුත් ඔබට සැම විටම ලිනක්ස් වීඑම් එකක් දේශීයව 'කැදලි අථත්‍යකරණය' වින්‍යාස කර සෙලිනොයිඩ් යෙදවිය හැක.

යටිතල පහසුකම්වල වත්මන් තත්ත්වය පිළිබඳ නිදර්ශනය

මෙම ලිපියේ සන්දර්භය තුළ, අපි යටිතල පහසුකම් නිදර්ශනය කිරීමට මෙවලම් 2 ක් එකතු කරන්නෙමු. මේවා වෙබ් පරීක්ෂණ සඳහා Selenium ජාලකය සහ Android පරීක්ෂණ සඳහා Selenoid වේ. GitHub නිබන්ධනයේදී, වෙබ් පරීක්ෂණ ක්‍රියාත්මක කිරීමට Selenoid භාවිතා කරන්නේ කෙසේදැයි මම ඔබට පෙන්වන්නම්. 

DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය

ගවේෂණය කිරීමට සබැඳි

සමාන මෙවලම්

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

4.CI/CD

තාක්ෂණය පිළිබඳ කෙටි විස්තරයක්

අඛණ්ඩ ඒකාබද්ධ කිරීමේ භාවිතය සංවර්ධනයේ දී බෙහෙවින් ජනප්‍රිය වන අතර අනුවාද පාලන පද්ධති සමඟ සමාන වේ. එසේ තිබියදී පාරිභාෂිතයේ ව්‍යාකූලත්වයක් ඇති බව මට හැඟේ. මෙම ඡේදයේ මගේ දෘෂ්ටි කෝණයෙන් මෙම තාක්ෂණයේ වෙනස් කිරීම් 3 ක් විස්තර කිරීමට මම කැමතියි. අන්තර්ජාලයේ ඔබ විවිධ අර්ථකථන සහිත ලිපි බොහොමයක් සොයා ගනු ඇත, ඔබේ මතය වෙනස් නම් එය සම්පූර්ණයෙන්ම සාමාන්ය දෙයක්. වැදගත්ම දෙය නම් ඔබ ඔබේ සගයන් සමඟ එකම පිටුවක සිටීමයි.

එබැවින්, නියමයන් 3 ක් ඇත: CI - අඛණ්ඩ ඒකාබද්ධ කිරීම, CD - අඛණ්ඩ බෙදාහැරීම සහ නැවතත් CD - අඛණ්ඩ යෙදවීම. (පහතින් මම මෙම නියමයන් ඉංග්‍රීසියෙන් භාවිතා කරමි) සෑම වෙනස් කිරීමක්ම ඔබේ සංවර්ධන නල මාර්ගයට අමතර පියවර කිහිපයක් එක් කරයි. නමුත් වචනය අඛණ්ඩව (අඛණ්ඩ) වැදගත්ම දෙයයි. මෙම සන්දර්භය තුළ, අපි අදහස් කරන්නේ ආරම්භයේ සිට අවසානය දක්වා බාධාවකින් හෝ අතින් මැදිහත් වීමකින් තොරව සිදුවන දෙයක්. මෙම සන්දර්භය තුළ CI & CD සහ CD දෙස බලමු.

  • අඛණ්ඩ ඒකාබද්ධතාවය මෙය පරිණාමයේ ආරම්භක පියවරයි. සේවාදායකයට නව කේතයක් ඉදිරිපත් කිරීමෙන් පසු, අපගේ වෙනස්කම් නිවැරදි බවට ඉක්මන් ප්‍රතිපෝෂණ ලැබීමට අපි බලාපොරොත්තු වෙමු. සාමාන්‍යයෙන්, CI හි ධාවනය වන ස්ථිතික කේත විශ්ලේෂණ මෙවලම් සහ ඒකක/අභ්‍යන්තර API පරීක්ෂණ ඇතුළත් වේ.මෙමගින් අපට අපගේ කේතය පිළිබඳ තොරතුරු තත්පර කිහිපයක්/විනාඩි කිහිපයක් ඇතුළත ලබා ගැනීමට ඉඩ සලසයි.
  • අඛණ්ඩ භාරදීම අපි අනුකලනය/UI පරීක්ෂණ ක්‍රියාත්මක කරන වඩාත් දියුණු පියවරකි. කෙසේ වෙතත්, මෙම අදියරේදී අපට CI සමඟ තරම් ඉක්මනින් ප්රතිඵල නොලැබේ. පළමුව, මෙම වර්ගයේ පරීක්ෂණ සම්පූර්ණ කිරීමට වැඩි කාලයක් ගතවේ. දෙවනුව, දියත් කිරීමට පෙර, අපි අපගේ වෙනස්කම් පරීක්ෂණ/වේදිකා පරිසරයට යෙදවිය යුතුය. එපමණක් නොව, අපි ජංගම සංවර්ධනය ගැන කතා කරන්නේ නම්, අපගේ යෙදුම ගොඩනැගීමට අමතර පියවරක් දිස්වේ.
  • අඛණ්ඩ යෙදවීම පෙර අදියරේදී සියලුම පිළිගැනීමේ පරීක්ෂණ සමත් වී ඇත්නම්, නිෂ්පාදනයට අපගේ වෙනස්කම් ස්වයංක්‍රීයව මුදා හරින බව උපකල්පනය කරයි. මීට අමතරව, නිකුත් කිරීමේ අදියරෙන් පසු, ඔබට නිෂ්පාදනය පිළිබඳ දුම් පරීක්ෂණ ධාවනය කිරීම සහ උනන්දුවක් දක්වන ප්‍රමිතික එකතු කිරීම වැනි විවිධ අදියරයන් සැකසිය හැකිය. අඛණ්ඩ යෙදවීම කළ හැක්කේ ස්වයංක්‍රීය පරීක්ෂණ මගින් හොඳ ආවරණයක් සහිතව පමණි. පරීක්ෂා කිරීම ඇතුළුව කිසියම් අතින් මැදිහත්වීමක් අවශ්‍ය නම්, මෙය තවදුරටත් නොවේ අඛණ්ඩව (අඛණ්ඩව). එවිට අපට කිව හැක්කේ අපගේ නල මාර්ගය අඛණ්ඩව බෙදා හැරීමේ පරිචයට පමණක් අනුකූල වන බවයි.

ස්වයංක්රීය යටිතල පහසුකම් සඳහා වටිනාකම

මෙම කොටසේදී, අපි අන්තයේ සිට අවසානය දක්වා UI පරීක්ෂණ ගැන කතා කරන විට, එයින් අදහස් වන්නේ අප අපගේ වෙනස්කම් සහ ආශ්‍රිත සේවා පරිසරය පරීක්ෂා කිරීම සඳහා යෙදවිය යුතු බව පැහැදිලි කළ යුතුය. අඛණ්ඩ ඒකාබද්ධ කිරීම - මෙම ක්‍රියාවලිය මෙම කාර්යය සඳහා අදාළ නොවන අතර අවම වශයෙන් අඛණ්ඩ බෙදාහැරීමේ පරිචයන් ක්‍රියාත්මක කිරීමට අප සැලකිලිමත් විය යුතුය. අපි ඒවා නිෂ්පාදනයේදී ධාවනය කිරීමට යන්නේ නම් UI පරීක්ෂණවල සන්දර්භය තුළ අඛණ්ඩ යෙදවීම අර්ථවත් කරයි.

අපි ගෘහ නිර්මාණ ශිල්පය වෙනස් කිරීම පිළිබඳ නිදර්ශනය දෙස බැලීමට පෙර, මට GitLab CI ගැන වචන කිහිපයක් පැවසීමට අවශ්‍යයි. අනෙකුත් CI/CD මෙවලම් මෙන් නොව, GitLab දුරස්ථ ගබඩාවක් සහ තවත් බොහෝ අමතර විශේෂාංග සපයයි. මේ අනුව, GitLab CI වලට වඩා වැඩි ය. එයට මූලාශ්‍ර කේත කළමනාකරණය, Agile කළමනාකරණය, CI/CD නල මාර්ග, ලොග් කිරීමේ මෙවලම් සහ කොටුවෙන් පිටත ප්‍රමිතික එකතු කිරීම ඇතුළත් වේ. GitLab ගෘහ නිර්මාණ ශිල්පය Gitlab CI/CD සහ GitLab Runner වලින් සමන්විත වේ. මෙන්න නිල වෙබ් අඩවියෙන් කෙටි විස්තරයක්:

Gitlab CI/CD යනු API සහිත වෙබ් යෙදුමක් වන අතර එය දත්ත සමුදායක් තුළ එහි තත්වය ගබඩා කරයි, ව්‍යාපෘති/ගොඩනැගීම් කළමනාකරණය කරයි සහ පරිශීලක අතුරුමුහුණතක් සපයයි. GitLab Runner යනු ගොඩනැගීම් ක්‍රියාවලි කරන යෙදුමකි. එය වෙන වෙනම යෙදවිය හැකි අතර API හරහා GitLab CI/CD සමඟ ක්‍රියා කරයි. ධාවනය වන පරීක්ෂණ සඳහා ඔබට Gitlab උදාහරණය සහ ධාවකය යන දෙකම අවශ්‍ය වේ.

යටිතල පහසුකම්වල වත්මන් තත්ත්වය පිළිබඳ නිදර්ශනය

DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය

ගවේෂණය කිරීමට සබැඳි

සමාන මෙවලම්

5. වලාකුළු වේදිකා

තාක්ෂණය පිළිබඳ කෙටි විස්තරයක්

මෙම කොටසේදී අපි 'public clouds' නම් ජනප්‍රිය ප්‍රවණතාවක් ගැන කතා කරමු. ඉහත විස්තර කර ඇති අථත්‍යකරණ සහ බහාලුම්කරණ තාක්‍ෂණයන් සපයන අතිවිශාල ප්‍රතිලාභ තිබියදීත්, අපට තවමත් පරිගණක සම්පත් අවශ්‍ය වේ. සමාගම් මිල අධික සේවාදායකයන් මිලදී ගැනීම හෝ දත්ත මධ්‍යස්ථාන කුලියට ගනී, නමුත් මේ අවස්ථාවේ දී අපට අවශ්‍ය සම්පත් කොපමණද, අපි ඒවා 24/7 භාවිතා කරන්නේද සහ කුමන අරමුණු සඳහාද යන්න ගණනය කිරීම් (සමහර විට යථාර්ථවාදී නොවන) සිදු කිරීම අවශ්‍ය වේ. උදාහරණයක් ලෙස, නිෂ්පාදනය සඳහා XNUMX/XNUMX ක්‍රියාත්මක වන සේවාදායකයක් අවශ්‍ය වේ, නමුත් වැඩ කරන වේලාවෙන් පිටත පරීක්ෂා කිරීම සඳහා අපට සමාන සම්පත් අවශ්‍යද? එය සිදු කරනු ලබන පරීක්ෂණ වර්ගය මත ද රඳා පවතී. උදාහරණයක් ලෙස ඊළඟ දවසේ ප්‍රතිඵල ලබා ගැනීම සඳහා අපි වැඩ නොකරන වේලාවන් තුළ ක්‍රියාත්මක කිරීමට සැලසුම් කරන බර/ආතති පරීක්ෂණ වේ. නමුත් නියත වශයෙන්ම XNUMX/XNUMX සේවාදායක ලබා ගැනීමේ හැකියාව අන්තයේ සිට අවසානය දක්වා ස්වයංක්‍රීය පරීක්ෂණ සඳහා අවශ්‍ය නොවන අතර විශේෂයෙන් අතින් පරීක්ෂණ පරිසරයන් සඳහා නොවේ. එවැනි තත්වයන් සඳහා, ඉල්ලුම මත අවශ්ය තරම් සම්පත් ලබා ගැනීම, ඒවා භාවිතා කිරීම සහ ඒවා තවදුරටත් අවශ්ය නොවන විට ගෙවීම නතර කිරීම හොඳය. එපමණක් නොව, මූසික ක්ලික් කිරීම් කිහිපයක් කිරීමෙන් හෝ ස්ක්‍රිප්ට් කිහිපයක් ක්‍රියාත්මක කිරීමෙන් ඒවා ක්ෂණිකව ලබා ගැනීම ඉතා හොඳ වනු ඇත. පොදු වලාකුළු භාවිතා කරන්නේ මෙයයි. අපි අර්ථ දැක්වීම දෙස බලමු:

“Public cloud යනු තෙවන පාර්ශ්ව සපයන්නන් විසින් පොදු අන්තර්ජාලය හරහා පිරිනමන පරිගණක සේවා ලෙස අර්ථ දක්වා ඇති අතර, ඒවා භාවිතා කිරීමට හෝ මිලදී ගැනීමට කැමති ඕනෑම කෙනෙකුට ඒවා ලබා ගත හැක. ඒවා නොමිලේ හෝ ඉල්ලුම මත විකුණනු ලැබිය හැකි අතර, පාරිභෝගිකයින්ට ඔවුන් පරිභෝජනය කරන CPU චක්‍ර, ගබඩා කිරීම හෝ කලාප පළල සඳහා එක් භාවිතයකට පමණක් ගෙවීමට ඉඩ සලසයි."

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

ස්වයංක්රීය යටිතල පහසුකම් සඳහා වටිනාකම

අන්තයේ සිට අවසානය දක්වා UI පරීක්ෂණ සඳහා අපට අවශ්‍ය විශේෂිත සම්පත් මොනවාද? මූලික වශයෙන් මේවා බ්‍රව්සර් සහ ඉමුලේටර් ධාවනය කිරීම සඳහා අථත්‍ය යන්ත්‍ර හෝ පොකුරු (අපි ඊළඟ කොටසේ කුබර්නෙට්ස් ගැන කතා කරමු). අපට එකවර ක්‍රියාත්මක කිරීමට අවශ්‍ය බ්‍රව්සර් සහ ඉමුලේටර් ප්‍රමාණය වැඩි වන තරමට CPU සහ මතකය අවශ්‍ය වන අතර ඒ සඳහා අපට ගෙවීමට සිදුවන මුදල වැඩි වේ. මේ අනුව, පරීක්ෂණ ස්වයංක්‍රීයකරණයේ සන්දර්භය තුළ ඇති පොදු වලාකුළු අපට ඉල්ලුම මත බ්‍රව්සර්/ඉමුලේටර් විශාල සංඛ්‍යාවක් (100, 200, 1000...) ක්‍රියාත්මක කිරීමට, පරීක්ෂණ ප්‍රතිඵල හැකි ඉක්මනින් ලබා ගැනීමට සහ එවැනි උමතු සම්පත්-දැඩි සඳහා ගෙවීම නතර කිරීමට ඉඩ සලසයි. බලය. 

වඩාත්ම ජනප්‍රිය වලාකුළු සපයන්නන් වන්නේ Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP) ය. කෙසේද යන්න මාර්ගෝපදේශය GCP භාවිතා කරන ආකාරය පිළිබඳ උදාහරණ සපයයි, නමුත් පොදුවේ ඔබ ස්වයංක්‍රීයකරණ කාර්යයන් සඳහා භාවිතා කරන්නේ කුමක් ද යන්න ගැටළුවක් නොවේ. ඒවා සියල්ලම ආසන්න වශයෙන් එකම ක්‍රියාකාරිත්වය සපයයි. සාමාන්‍යයෙන්, සැපයුම්කරුවෙකු තෝරා ගැනීම සඳහා, කළමනාකරණය සමාගමේ සමස්ත යටිතල පහසුකම් සහ ව්‍යාපාරික අවශ්‍යතා කෙරෙහි අවධානය යොමු කරයි, එය මෙම ලිපියේ විෂය පථයෙන් ඔබ්බට ය. ස්වයංක්‍රීය ඉංජිනේරුවන් සඳහා, Souce Labs, BrowserStack, BitBar වැනි පරීක්ෂණ අරමුණු සඳහා විශේෂයෙන් වලාකුළු වේදිකා භාවිතය සමඟ වලාකුළු සපයන්නන්ගේ භාවිතය සංසන්දනය කිරීම වඩාත් සිත්ගන්නාසුළු වනු ඇත. එහෙනම් අපිත් කරමු! මගේ මතය අනුව, සෝස් ලැබ් යනු වඩාත් ප්‍රසිද්ධ වලාකුළු පරීක්ෂණ ගොවිපලයි, ඒ නිසා මම එය සංසන්දනය කිරීමට භාවිතා කළෙමි. 

ස්වයංක්‍රීය කිරීමේ අරමුණු සඳහා GCP එදිරිව සෝස් විද්‍යාගාර:

අපි හිතමු අපිට web tests 8ක් සහ Android tests 8ක් එකවර ක්‍රියාත්මක කරන්න ඕන කියලා. මේ සඳහා අපි GCP භාවිතා කර සෙලිනොයිඩ් සමඟ අථත්‍ය යන්ත්‍ර 2 ක් ධාවනය කරමු. පළමු එකේ අපි බ්‍රව්සර් සමඟ බහාලුම් 8 ක් ඔසවන්නෙමු. දෙවැන්නෙහි ඉමුලේටර් සහිත බහාලුම් 8 ක් ඇත. අපි මිල ගණන් දෙස බලමු:  

DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය
Chrome සමඟ එක් බහාලුමක් ධාවනය කිරීමට, අපට අවශ්‍ය වේ n1-සම්මත-1 මෝටර් රථ. Android සම්බන්ධයෙන් එය එසේ වනු ඇත n1-සම්මත-4 එක් ඉමුලේටරයක් ​​සඳහා. ඇත්ත වශයෙන්ම, වඩාත් නම්‍යශීලී සහ ලාභදායී ක්‍රමයක් වන්නේ CPU/Memory සඳහා නිශ්චිත පරිශීලක අගයන් සැකසීමයි, නමුත් මේ මොහොතේ සෝස් රසායනාගාර සමඟ සැසඳීම සඳහා මෙය වැදගත් නොවේ.

සහ සෝස් ලැබ් භාවිතා කිරීම සඳහා ගාස්තු මෙන්න:

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

අවශ්ය සම්පත්
මාසිකව
වැඩ කරන පැය(පෙ.ව. 8 - ප.ව. 8)
වැඩ කරන පැය+ පූර්වගාමී

වෙබ් සඳහා GCP
n1-සම්මත-1 x 8 = n1-සම්මත-8
$194.18
දින 23 * පැය 12 * 0.38 = $ 104.88 
දින 23 * පැය 12 * 0.08 = $ 22.08

වෙබ් සඳහා සෝස් රසායනාගාර
අතථ්‍ය Cloud8 සමාන්තර පරීක්ෂණ
$1.559
-
-

Android සඳහා GCP
n1-සම්මත-4 x 8: n1-සම්මත-16
$776.72
දින 23 * පැය 12 * 1.52 = $ 419.52 
දින 23 * පැය 12 * 0.32 = $ 88.32

Android සඳහා සෝස් රසායනාගාර
Real Device Cloud 8 සමාන්තර පරීක්ෂණ
$1.999
-
-

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

Preemptible VM යනු ඔබට සාමාන්‍ය අවස්ථාවන්ට වඩා වැඩි මිලකට නිර්මාණය කර ධාවනය කළ හැකි අවස්ථාවකි. කෙසේ වෙතත්, වෙනත් කාර්යයන් සඳහා එම සම්පත් වෙත ප්‍රවේශය අවශ්‍ය නම්, Compute Engine විසින් මෙම අවස්ථා අවසන් කිරීමට (පූර්වගාමී) කළ හැක. පූර්වාපේක්‍ෂා කළ හැකි අවස්ථා වන්නේ අතිරික්ත පරිගණක එන්ජින් ධාරිතාවය, එබැවින් ඒවායේ ඇති හැකියාව භාවිතය අනුව වෙනස් වේ.

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

සහ එය තවමත් අවසන් නැත! ඇත්ත වශයෙන්ම, කිසිවෙකු විවේකයකින් තොරව පැය 12 ක් පරීක්ෂණ පවත්වන බව මට විශ්වාසයි. එසේ නම්, ඔබට අවශ්‍ය නොවන විට අතථ්‍ය යන්ත්‍ර ස්වයංක්‍රීයව ආරම්භ කර නැවැත්විය හැකිය. සැබෑ භාවිත කාලය දිනකට පැය 6 දක්වා අඩු කළ හැක. එවිට අපගේ කාර්යයේ සන්දර්භය තුළ ගෙවීම බ්‍රව්සර් 11 ක් සඳහා මසකට ඩොලර් 8 දක්වා අඩු වේ. මේක අපූරුයි නේද? නමුත් මෙම තත්ත්වයන් මෘදුකාංගය තුළ සැපයිය හැකි සහ හැසිරවිය හැකි වුවද, පෙරදැමිය හැකි යන්ත්‍ර සමඟ අප ප්‍රවේශම් විය යුතු අතර බාධා කිරීම් සහ අස්ථාවරත්වය සඳහා සූදානම් විය යුතුය. එය වටිනවා!

නමුත් මම කිසිසේත් කියන්නේ නැහැ 'කිසිවිටක වලාකුළු පරීක්ෂණ ගොවිපල භාවිතා නොකරන්න' කියා. ඔවුන්ට වාසි ගණනාවක් තිබේ. පළමුවෙන්ම, මෙය හුදෙක් අතථ්‍ය යන්ත්‍රයක් පමණක් නොව, කොටුවෙන් පිටත ක්‍රියාකාරීත්වයේ කට්ටලයක් සහිත සම්පූර්ණ පරීක්ෂණ ස්වයංක්‍රීයකරණ විසඳුමකි: දුරස්ථ ප්‍රවේශය, ලඝු-සටහන්, තිරපිටපත්, වීඩියෝ පටිගත කිරීම, විවිධ බ්‍රව්සර් සහ භෞතික ජංගම උපාංග. බොහෝ අවස්ථාවන්හිදී, මෙය අත්යවශ්ය චික් විකල්පයක් විය හැකිය. පොදු වලාකුළු වලට ලිනක්ස්/වින්ඩෝස් පද්ධති පමණක් ලබා දිය හැකි විට, IOS ස්වයංක්‍රීයකරණය සඳහා පරීක්ෂණ වේදිකාවන් විශේෂයෙන් ප්‍රයෝජනවත් වේ. නමුත් අපි පහත ලිපි වලින් iOS ගැන කතා කරමු. සෑම විටම තත්වය දෙස බැලීම සහ කාර්යයන් වලින් ආරම්භ කිරීම මම නිර්දේශ කරමි: සමහර අවස්ථාවලදී පොදු වලාකුළු භාවිතා කිරීම වඩා ලාභදායී හා වඩා කාර්යක්ෂම වන අතර අනෙක් අය පරීක්ෂණ වේදිකා අනිවාර්යයෙන්ම වියදම් කළ මුදල වටී.

යටිතල පහසුකම්වල වත්මන් තත්ත්වය පිළිබඳ නිදර්ශනය

DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය

ගවේෂණය කිරීමට සබැඳි

සමාන මෙවලම්:

6. වාද්‍ය වෘන්දය

තාක්ෂණය පිළිබඳ කෙටි විස්තරයක්

මට ශුභාරංචියක් තිබේ - අපි ලිපියේ අවසානයට ආසන්නයි! මේ මොහොතේ, අපගේ ස්වයංක්‍රීය යටිතල ව්‍යුහය වෙබ් සහ ඇන්ඩ්‍රොයිඩ් පරීක්ෂණ වලින් සමන්විත වන අතර, අපි GitLab CI හරහා සමාන්තරව, Docker-සක්‍රීය මෙවලම් භාවිතා කරමින් ධාවනය කරමු: Selenium grid සහ Selenoid. එපමනක් නොව, අපි බ්‍රව්සර් සහ ඉමුලේටර් සහිත බහාලුම් සංග්‍රහ කිරීමට GCP හරහා සාදන ලද අතථ්‍ය යන්ත්‍ර භාවිතා කරමු. පිරිවැය අඩු කිරීම සඳහා, අපි මෙම අථත්‍ය යන්ත්‍ර ඉල්ලුම මත පමණක් ආරම්භ කරන අතර පරීක්ෂණ සිදු නොවන විට ඒවා නවත්වන්නෙමු. අපගේ යටිතල පහසුකම් වැඩිදියුණු කළ හැකි වෙනත් යමක් තිබේද? පිළිතුර ඔව්! Kubernetes (K8s) හමුවන්න!

පළමුව, orchestration, cluster සහ Kubernetes යන වචන එකිනෙක සම්බන්ධ වන්නේ කෙසේදැයි බලමු. ඉහළ මට්ටමක, වාද්‍ය වෘන්දය යනු යෙදුම් යෙදවීම සහ කළමනාකරණය කරන පද්ධතියයි. පරීක්ෂණ ස්වයංක්‍රීයකරණය සඳහා, එවැනි බහාලුම් යෙදවුම් වන්නේ Selenium grid සහ Selenoid වේ. Docker සහ K8s එකිනෙකට අනුපූරක වේ. පළමුවැන්න යෙදුම් යෙදවීම සඳහා, දෙවැන්න වාද්‍ය වෘන්දය සඳහා භාවිතා වේ. අනෙක් අතට, K8s යනු පොකුරකි. පොකුරේ කාර්යය වන්නේ VMs නෝඩ් ලෙස භාවිතා කිරීමයි, එමඟින් ඔබට විවිධ ක්‍රියාකාරීත්වය, වැඩසටහන් සහ සේවාවන් එක් සේවාදායකයක් (පොකුරු) තුළ ස්ථාපනය කිරීමට ඉඩ සලසයි. කිසියම් නෝඩයක් අසමත් වුවහොත්, අපගේ යෙදුමේ බාධාවකින් තොරව ක්‍රියාත්මක වීම සහතික කරන අනෙකුත් නෝඩ් ලබා ගනී. මෙයට අමතරව, K8s පරිමාණය සම්බන්ධ වැදගත් ක්‍රියාකාරීත්වයක් ඇත, එයට ස්තූතිවන්ත වන පරිදි අපි භාරය සහ සීමාවන් මත පදනම්ව ප්‍රශස්ත සම්පත් ප්‍රමාණය ස්වයංක්‍රීයව ලබා ගනිමු.

ඇත්ත වශයෙන්ම, මුල සිටම Kubernetes අතින් යෙදවීම කිසිසේත්ම සුළුපටු කාර්යයක් නොවේ. "Kubernetes The Hard Way" යන සුප්‍රසිද්ධ මඟ පෙන්වීම සඳහා මම සබැඳියක් තබමි, ඔබ කැමති නම්, ඔබට එය පුහුණු කළ හැකිය. එහෙත්, වාසනාවකට මෙන්, විකල්ප ක්රම සහ මෙවලම් තිබේ. පහසුම ක්‍රමය නම් GCP හි Google Kubernetes Engine (GKE) භාවිතා කිරීමයි, එමඟින් ඔබට ක්ලික් කිරීම් කිහිපයකින් සූදානම් කළ පොකුරක් ලබා ගැනීමට ඉඩ සලසයි. ඉගෙනීම ආරම්භ කිරීම සඳහා මෙම ප්‍රවේශය භාවිතා කිරීම මම නිර්දේශ කරමි, අභ්‍යන්තර සංරචක එකට ඒකාබද්ධ කළ යුතු ආකාරය ඉගෙන ගැනීම වෙනුවට ඔබේ කාර්යයන් සඳහා K8s භාවිතා කරන්නේ කෙසේදැයි ඉගෙන ගැනීමට එය ඔබට අවධානය යොමු කිරීමට ඉඩ සලසයි. 

ස්වයංක්රීය යටිතල පහසුකම් සඳහා වටිනාකම

K8s සපයන සැලකිය යුතු විශේෂාංග කිහිපයක් දෙස බලමු:

  • යෙදුම් යෙදවීම: VM වෙනුවට බහු-නෝඩ් පොකුරක් භාවිතා කිරීම;
  • ගතික පරිමාණය: ඉල්ලුම මත පමණක් භාවිතා කරන සම්පත්වල පිරිවැය අඩු කරයි;
  • ස්වයං-සුව කිරීම: කරල් ස්වයංක්‍රීයව ප්‍රතිසාධනය කිරීම (එහි ප්‍රති result ලයක් ලෙස බහාලුම් ද ප්‍රතිස්ථාපනය වේ);
  • අක්‍රිය කාලයකින් තොරව යාවත්කාලීන කිරීම් සහ වෙනස්කම් ආපසු හැරවීම: මෙවලම්, බ්‍රව්සර් සහ ඉමුලේටර් යාවත්කාලීන කිරීම වත්මන් පරිශීලකයින්ගේ කාර්යයට බාධා නොකරයි

නමුත් K8s තවමත් රිදී උණ්ඩයක් නොවේ. අප සලකා බලන මෙවලම්වල සන්දර්භය තුළ ඇති සියලුම වාසි සහ සීමාවන් තේරුම් ගැනීමට (Selenium grid, Selenoid), අපි K8s හි ව්‍යුහය කෙටියෙන් සාකච්ඡා කරමු. පොකුරේ නෝඩ් වර්ග දෙකක් අඩංගු වේ: මාස්ටර් නෝඩ් සහ වර්කර්ස් නෝඩ්. ප්‍රධාන නෝඩ් කළමනාකරණය, යෙදවීම සහ කාලසටහන් තීරණ සඳහා වගකිව යුතුය. වර්කර්ස් නෝඩ් යනු යෙදුම් ධාවනය වන ස්ථානයයි. නෝඩ් වල බහාලුම් ධාවන කාල පරිසරයක් ද අඩංගු වේ. අපගේ නඩුවේදී, මෙය බහාලුම් ආශ්‍රිත මෙහෙයුම් සඳහා වගකිව යුතු Docker වේ. නමුත් උදාහරණයක් ලෙස විකල්ප විසඳුම් ද තිබේ බහාලුම්. පරිමාණය හෝ ස්වයං-සුව කිරීම බහාලුම්වලට සෘජුවම අදාළ නොවන බව වටහා ගැනීම වැදගත්ය. මෙය ක්‍රියාත්මක කරනු ලබන්නේ කරල් ගණන එකතු කිරීම/අඩු කිරීමෙනි, එහි අනෙක් අතට බහාලුම් අඩංගු වේ (සාමාන්‍යයෙන් කරල් එකකට එක් බහාලුමක්, නමුත් කාර්යය අනුව තවත් තිබිය හැක). ඉහළ මට්ටමේ ධූරාවලිය සමන්විත වන්නේ සේවක නෝඩ් වලින් වන අතර, එහි ඇතුළත කරල් ඇත, ඇතුළත බහාලුම් ඔසවා ඇත.

පරිමාණ කිරීමේ විශේෂාංගය ප්‍රධාන වන අතර පොකුරු නෝඩ් තටාකයක් තුළ ඇති නෝඩ් දෙකටම සහ නෝඩයක් තුළ ඇති කරල් දෙකටම යෙදිය හැකිය. නෝඩ් සහ කරල් දෙකටම අදාළ වන පරිමාණය වර්ග 2 ක් ඇත. පළමු වර්ගය තිරස් වේ - පරිමාණය සිදු වන්නේ නෝඩ්/පොඩ් ගණන වැඩි කිරීමෙනි. මෙම වර්ගය වඩාත් යෝග්ය වේ. දෙවන වර්ගය, ඒ අනුව, සිරස් වේ. පරිමාණය සිදු කරනු ලබන්නේ නෝඩ් / කරල් වල ප්‍රමාණය වැඩි කිරීම මිස ඒවායේ සංඛ්‍යාව වැඩි කිරීමෙනි.

දැන් අපි අපගේ මෙවලම් ඉහත නියමවල සන්දර්භය තුළ බලමු.

සෙලේනියම් ජාලය

කලින් සඳහන් කළ පරිදි, සෙලේනියම් ජාලය ඉතා ජනප්රිය මෙවලමක් වන අතර, එය බහාලුම් කර ඇති බව පුදුමයක් නොවේ. එබැවින්, K8s තුළ Selenium ජාලය යෙදවිය හැකි බව පුදුමයක් නොවේ. මෙය කරන්නේ කෙසේද යන්න පිළිබඳ උදාහරණයක් නිල K8s ගබඩාවෙන් සොයාගත හැකිය. සුපුරුදු පරිදි, මම කොටස අවසානයේ සබැඳි අමුණමි. මීට අමතරව, කෙසේද යන්න මාර්ගෝපදේශය Terraform හි මෙය කරන්නේ කෙසේදැයි පෙන්වයි. බ්‍රව්සර් බහාලුම් අඩංගු කරල් ගණන පරිමාණය කරන්නේ කෙසේද යන්න පිළිබඳ උපදෙස් ද ඇත. නමුත් K8s හි සන්දර්භය තුළ ස්වයංක්රීය පරිමාණ ශ්රිතය තවමත් සම්පූර්ණයෙන්ම පැහැදිලි කාර්යයක් නොවේ. මම ඉගෙනීමට පටන් ගත් විට, මට කිසිදු ප්‍රායෝගික මාර්ගෝපදේශයක් හෝ නිර්දේශයක් හමු නොවීය. DevOps කණ්ඩායමේ සහාය ඇතිව අධ්‍යයනයන් සහ අත්හදා බැලීම් කිහිපයකට පසුව, අපි එක් සේවක නෝඩයක් තුළ පිහිටා ඇති එක් පොඩ් එකක් තුළ අවශ්‍ය බ්‍රව්සර් සහිත බහාලුම් එසවීමේ ප්‍රවේශය තෝරා ගත්තෙමු. මෙම ක්‍රමය මඟින් ඒවායේ සංඛ්‍යාව වැඩි කිරීමෙන් නෝඩ් වල තිරස් පරිමාණයේ උපාය මාර්ගය යෙදීමට අපට ඉඩ සලසයි. අනාගතයේදී මෙය වෙනස් වනු ඇතැයි මම බලාපොරොත්තු වන අතර වඩා හොඳ ප්‍රවේශයන් සහ සූදානම් කළ විසඳුම් පිළිබඳ වැඩි වැඩියෙන් විස්තර අපට පෙනෙනු ඇත, විශේෂයෙන් වෙනස් වූ අභ්‍යන්තර ගෘහ නිර්මාණ ශිල්පයක් සහිත Selenium grid 4 නිකුත් කිරීමෙන් පසුව.

සෙලිනොයිඩ්:

K8s හි Selenoid යෙදවීම දැනට විශාලතම බලාපොරොත්තු සුන්වීමයි. ඒවා නොගැළපේ. න්‍යායට අනුව, අපට Pod එකක් තුළ Selenoid බහාලුමක් මතු කළ හැකිය, නමුත් Selenoid බ්‍රව්සර් සමඟ බහාලුම් දියත් කිරීමට පටන් ගත් විට, ඒවා තවමත් එකම පොඩ් එක තුළ පවතිනු ඇත. මෙය පරිමාණය කළ නොහැකි වන අතර, එහි ප්‍රතිඵලයක් ලෙස, පොකුරක් තුළ ඇති සෙලිනොයිඩ් ක්‍රියාකාරිත්වය අතථ්‍ය යන්ත්‍රයක් තුළ ක්‍රියා කිරීමෙන් වෙනස් නොවේ. කතාවේ අවසානය.

සඳ:

Selenoid සමඟ වැඩ කරන විට මෙම බාධාව දැන ගැනීමෙන්, සංවර්ධකයින් විසින් Moon නම් වඩාත් බලවත් මෙවලමක් නිකුත් කරන ලදී. මෙම මෙවලම මුලින් නිර්මාණය කර ඇත්තේ Kubernetes සමඟ වැඩ කිරීමට වන අතර, එහි ප්‍රතිඵලයක් ලෙස, ස්වයංක්‍රීය පරිමාණය කිරීමේ විශේෂාංගය භාවිතා කළ හැකි සහ භාවිතා කළ යුතුය. එපමණක් නොව, මේ මොහොතේ එය එසේ බව මම කියමි එකම පෙට්ටියෙන් පිටත දේශීය K8s පොකුරු ආධාරක ඇති Selenium ලෝකයේ මෙවලමක් (තවදුරටත් ලබා ගත නොහැක, ඊළඟ මෙවලම බලන්න ) මෙම සහාය ලබා දෙන සඳෙහි ප්රධාන ලක්ෂණ වන්නේ: 

සම්පූර්ණයෙන්ම අස්ථායී. Selenoid දැනට ක්‍රියාත්මක වන බ්‍රවුසර සැසි පිළිබඳ තොරතුරු මතකයේ ගබඩා කරයි. කිසියම් හේතුවක් නිසා එහි ක්‍රියාවලිය බිඳ වැටුණහොත් - සියලුම ධාවන සැසි නැති වී යයි. චන්ද්‍රයාට ප්‍රතිවිරුද්ධ ලෙස අභ්‍යන්තර තත්වයක් නොමැති අතර දත්ත මධ්‍යස්ථාන හරහා ප්‍රතිවර්තනය කළ හැක. අනුපිටපත් එකක් හෝ කිහිපයක් පහළ ගියත් බ්‍රවුසර සැසි සජීවීව පවතී.

ඉතින්, සඳ හොඳ විසඳුමක්, නමුත් එක් ගැටලුවක් තිබේ: එය නොමිලේ නොවේ. මිල සැසි ගණන මත රඳා පවතී. ඔබට නොමිලේ සැසි 0-4 ක් පමණක් ධාවනය කළ හැකිය, එය විශේෂයෙන් ප්රයෝජනවත් නොවේ. නමුත්, පස්වන සැසියේ සිට, ඔබ එක් එක් සඳහා $5 ගෙවීමට සිදු වනු ඇත. සමාගමෙන් සමාගමට තත්වය වෙනස් විය හැකි නමුත් අපගේ නඩුවේදී, සඳ භාවිතා කිරීම අර්ථ විරහිත ය. මා ඉහත විස්තර කළ පරිදි, අපට ඉල්ලුම මත Selenium Grid සමඟ VM ධාවනය කිරීමට හෝ පොකුරේ ඇති Nodes ගණන වැඩි කිරීමට හැකිය. ආසන්න වශයෙන් එක් නල මාර්ගයක් සඳහා, අපි බ්‍රව්සර් 500 ක් දියත් කර පරීක්ෂණ අවසන් වූ පසු සියලු සම්පත් නවත්වන්නෙමු. අපි Moon භාවිතා කළා නම්, අපි කොපමණ වාර ගණනක් පරීක්ෂණ කළත්, මසකට අමතර 500 x 5 = $2500 ගෙවීමට සිදුවේ. ආයෙත් මම කියන්නේ නෑ මූන් පාවිච්චි කරන්න එපා කියලා. ඔබගේ කාර්යයන් සඳහා, මෙය අත්‍යවශ්‍ය විසඳුමක් විය හැකිය, නිදසුනක් වශයෙන්, ඔබට ඔබේ සංවිධානයේ බොහෝ ව්‍යාපෘති/කණ්ඩායම් තිබේ නම් සහ ඔබට සෑම කෙනෙකුටම විශාල පොදු පොකුරක් අවශ්‍ය නම්. සෑම විටම මෙන්, මම අවසානයේ සබැඳියක් තබා ඔබගේ කාර්යයේ සන්දර්භය තුළ අවශ්ය සියලු ගණනය කිරීම් සිදු කිරීමට නිර්දේශ කරමි.

කැලිස්ටෝ: (අවධානය! මෙය මුල් ලිපියේ නොමැති අතර රුසියානු පරිවර්තනයේ පමණක් අඩංගු වේ)

මම කී පරිදි, සෙලේනියම් ඉතා ජනප්රිය මෙවලමක් වන අතර, තොරතුරු තාක්ෂණ ක්ෂේත්රය ඉතා ඉක්මනින් සංවර්ධනය වෙමින් පවතී. මම පරිවර්තනයේ වැඩ කරමින් සිටියදී, Callisto නම් නව පොරොන්දු මෙවලමක් වෙබයේ දර්ශනය විය (හලෝ සයිප්‍රස් සහ අනෙකුත් සෙලේනියම් ඝාතකයන්). එය K8s සමඟ දේශීයව ක්‍රියා කරන අතර Nodes හරහා බෙදා හරින ලද කරල්වල Selenoid බහාලුම් ධාවනය කිරීමට ඔබට ඉඩ සලසයි. ස්වයංක්‍රීය පරිමාණය ඇතුළුව සෑම දෙයක්ම කොටුවෙන් පිටත ක්‍රියා කරයි. නියමයි, නමුත් පරීක්ෂා කිරීමට අවශ්යයි. මම දැනටමත් මෙම මෙවලම යෙදවීමට සහ අත්හදා බැලීම් කිහිපයක් ක්‍රියාත්මක කිරීමට සමත් වී ඇත. නමුත් නිගමනවලට එළඹීමට ඉක්මන් වැඩියි, දිගු දුරක් ප්‍රතිඵල ලැබීමෙන් පසු, සමහර විට මම ඉදිරි ලිපිවල සමාලෝචනයක් කරන්නෙමි. දැනට මම ස්වාධීන පර්යේෂණ සඳහා සබැඳි පමණක් තබමි.  

යටිතල පහසුකම්වල වත්මන් තත්ත්වය පිළිබඳ නිදර්ශනය

DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය

ගවේෂණය කිරීමට සබැඳි

සමාන මෙවලම්

7. යටිතල පහසුකම් කේතය (IaC) ලෙස

තාක්ෂණය පිළිබඳ කෙටි විස්තරයක්

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

මෙම ප්රවේශය භාවිතා කිරීම සඳහා පෙළඹවීම සමඟ ආරම්භ කරමු. GitlabCI හි පරීක්ෂණ ක්‍රියාත්මක කිරීමට, Gitlab Runner ධාවනය කිරීමට අපට අවම වශයෙන් සම්පත් අවශ්‍ය බව අපි දැනටමත් සාකච්ඡා කර ඇත්තෙමු. බ්‍රව්සර්/ඉමුලේටර් සහිත බහාලුම් ධාවනය කිරීමට, අපි VM හෝ පොකුරක් වෙන්කරවා ගත යුතුය. සම්පත් පරීක්‍ෂා කිරීමට අමතරව, දත්ත සමුදායන්, ස්වයංක්‍රීය කාලසටහන්, ජාල වින්‍යාස කිරීම්, පැටවුම් සමතුලිතතා, පරිශීලක අයිතිවාසිකම් සහ යනාදිය ඇතුළත් සංවර්ධනය, වේදිකාගත කිරීම, නිෂ්පාදන පරිසරයන්ට සහාය වීමට අපට සැලකිය යුතු ධාරිතාවක් අවශ්‍ය වේ. ප්‍රධාන කාරණය වන්නේ ඒ සියල්ලටම සහයෝගය දැක්වීමට අවශ්‍ය උත්සාහයයි. අපට වෙනස්කම් කිරීමට සහ යාවත්කාලීන කිරීමට හැකි ක්‍රම කිහිපයක් තිබේ. උදාහරණයක් ලෙස, GCP සන්දර්භය තුළ, අපට බ්‍රව්සරයේ UI කොන්සෝලය භාවිතා කළ හැකි අතර බොත්තම් ක්ලික් කිරීමෙන් සියලුම ක්‍රියා සිදු කළ හැකිය. විකල්පයක් වනුයේ ක්ලවුඩ් ආයතන සමඟ අන්තර් ක්‍රියා කිරීමට API ඇමතුම් භාවිතා කිරීම හෝ අපේක්ෂිත උපාමාරු සිදු කිරීමට gCloud විධාන රේඛා උපයෝගීතාව භාවිතා කිරීමයි. නමුත් ඇත්ත වශයෙන්ම විවිධ ආයතන සහ යටිතල පහසුකම් මූලද්‍රව්‍ය විශාල සංඛ්‍යාවක් සමඟ, සියලු මෙහෙයුම් අතින් සිදු කිරීම දුෂ්කර හෝ කළ නොහැකි වේ. එපමණක් නොව, මෙම සියලු අතින් ක්රියාවන් පාලනය කළ නොහැකි ය. අපට ඒවා ක්‍රියාත්මක කිරීමට පෙර සමාලෝචනය සඳහා ඉදිරිපත් කිරීමට, අනුවාද පාලන පද්ධතියක් භාවිත කිරීමට සහ සිදුවීමට තුඩු දුන් වෙනස්කම් ඉක්මනින් ආපසු හැරවීමට නොහැක. එවැනි ගැටළු විසඳීම සඳහා, ඉංජිනේරුවන් විසින් පෙර ක්‍රමවලට වඩා හොඳ නැති ස්වයංක්‍රීය bash/shell scripts නිර්මාණය කර නිර්මාණය කරන ලදී, මන්ද ඒවා ක්‍රියා පටිපාටි ශෛලියකින් ඉක්මනින් කියවීම, තේරුම් ගැනීම, නඩත්තු කිරීම සහ වෙනස් කිරීම එතරම් පහසු නොවන බැවිනි.

මෙම ලිපියේ සහ මඟ පෙන්වීම සඳහා, මම IaC භාවිතයට අදාළ මෙවලම් 2 ක් භාවිතා කරමි. මේවා Terraform සහ Ansible වේ. සමහර අය විශ්වාස කරන්නේ ඒවායේ ක්‍රියාකාරිත්වය සමාන වන අතර ඒවා එකිනෙකට හුවමාරු කළ හැකි බැවින් ඒවා එකවර භාවිතා කිරීම තේරුමක් නැති බවයි. නමුත් කාරණය නම් මුලදී ඔවුන්ට සම්පූර්ණයෙන්ම වෙනස් කාර්යයන් ලබා දී ඇති බවයි. මෙම මෙවලම් එකිනෙකට අනුපූරක විය යුතු බව HashiCorp සහ RedHat නියෝජනය කරන සංවර්ධකයින් විසින් ඒකාබද්ධ ඉදිරිපත් කිරීමකදී තහවුරු කරන ලදී. සංකල්පීය වෙනස නම් Terraform යනු සේවාදායකයන් කළමනාකරණය කිරීම සඳහා ප්‍රතිපාදන මෙවලමක් වීමයි. Ansible යනු වින්‍යාස කළමනාකරණ මෙවලමක් වන අතර එහි කාර්යය වන්නේ මෙම සේවාදායකයන් මත මෘදුකාංග ස්ථාපනය කිරීම, වින්‍යාස කිරීම සහ කළමනාකරණය කිරීමයි.

මෙම මෙවලම්වල තවත් ප්‍රධාන කැපී පෙනෙන ලක්ෂණයක් වන්නේ කේතීකරණ විලාසයයි. bash සහ Ansible මෙන් නොව, Terraform ක්‍රියාත්මක කිරීමේ ප්‍රතිඵලයක් ලෙස සාක්ෂාත් කර ගැනීමට අපේක්ෂිත අවසාන තත්ත්වය පිළිබඳ විස්තරයක් මත පදනම් වූ ප්‍රකාශන ශෛලියක් භාවිතා කරයි. උදාහරණයක් ලෙස, අපි 10 VM නිර්මාණය කර Terraform හරහා වෙනස්කම් යෙදීමට යන්නේ නම්, අපට VM 10 ක් ලැබේ. අපි ස්ක්‍රිප්ට් එක නැවත ක්‍රියාත්මක කළහොත්, අප සතුව දැනටමත් වීඑම් 10 ක් ඇති බැවින් කිසිවක් සිදු නොවනු ඇත, සහ ටෙරාෆෝම් මෙය දන්නේ එය යටිතල ව්‍යුහයේ වත්මන් තත්ත්වය රාජ්‍ය ගොනුවක ගබඩා කරන බැවිනි. නමුත් ඇන්සිබල් ක්‍රියා පටිපාටි ප්‍රවේශයක් භාවිතා කරන අතර, ඔබ එය VM 10 ක් නිර්මාණය කරන ලෙස ඉල්ලා සිටියහොත්, පළමු දියත් කිරීමේදී අපට Terraform හා සමාන VM 10 ක් ලැබෙනු ඇත. නමුත් නැවත ආරම්භ කිරීමෙන් පසු අපට දැනටමත් VM 20 ක් ලැබෙනු ඇත. වැදගත් වෙනස මෙයයි. කාර්ය පටිපාටි ශෛලිය තුල, අපි වත්මන් තත්ත්වය ගබඩා නොකරන අතර සරලව සිදු කළ යුතු පියවර අනුපිළිවෙලක් විස්තර කරමු. ඇත්ත වශයෙන්ම, අපට විවිධ තත්වයන් හැසිරවිය හැකිය, සම්පත් වල පැවැත්ම සහ වත්මන් තත්වය සඳහා චෙක්පත් කිහිපයක් එකතු කළ හැකිය, නමුත් අපගේ කාලය නාස්ති කිරීම සහ මෙම තර්කනය පාලනය කිරීම සඳහා උත්සාහයක් දැරීමේ තේරුමක් නැත. මීට අමතරව, මෙය වැරදි සිදු කිරීමේ අවදානම වැඩි කරයි. 

ඉහත සියල්ල සාරාංශගත කිරීම, අපට නිගමනය කළ හැක්කේ Terraform සහ declarative notation යනු සේවාදායකයන් සැපයීම සඳහා වඩාත් සුදුසු මෙවලමක් බවයි. නමුත් වින්‍යාස කළමනාකරණයේ කාර්යය Ansible වෙත පැවරීම වඩා හොඳය. එය මඟ හැරීමත් සමඟ, ස්වයංක්‍රීයකරණයේ සන්දර්භය තුළ භාවිත අවස්ථා දෙස බලමු.

ස්වයංක්රීය යටිතල පහසුකම් සඳහා වටිනාකම

මෙහිදී තේරුම් ගත යුතු එකම වැදගත් දෙය නම් පරීක්ෂණ ස්වයංක්‍රීය යටිතල ව්‍යුහය සමස්ත සමාගම් යටිතල ව්‍යුහයේ කොටසක් ලෙස සැලකිය යුතු බවයි. මෙයින් අදහස් කරන්නේ සියලුම IaC භාවිතයන් සමස්ත සංවිධානයේ සම්පත් සඳහා ගෝලීය වශයෙන් යෙදිය යුතු බවයි. මේ සඳහා වගකිව යුත්තේ කවුරුන්ද යන්න ඔබේ ක්‍රියාවලීන් මත රඳා පවතී. DevOps කණ්ඩායම මෙම ගැටළු සම්බන්ධයෙන් වඩාත් පළපුරුදු ය, ඔවුන් සිදුවන්නේ කුමක්ද යන්න පිළිබඳ සම්පූර්ණ චිත්‍රය දකී. කෙසේ වෙතත්, QA ඉංජිනේරුවන් ස්වයංක්‍රීයකරණය සහ නල මාර්ගයේ ව්‍යුහය ගොඩනැගීමේ ක්‍රියාවලියට වැඩි වශයෙන් සම්බන්ධ වන අතර එමඟින් අවශ්‍ය සියලුම වෙනස්කම් සහ වැඩිදියුණු කිරීමේ අවස්ථා වඩා හොඳින් දැකීමට ඔවුන්ට ඉඩ සලසයි. හොඳම විකල්පය වන්නේ එකට වැඩ කිරීම, අපේක්ෂිත ප්රතිඵලය සාක්ෂාත් කර ගැනීම සඳහා දැනුම හා අදහස් හුවමාරු කර ගැනීමයි. 

පරීක්ෂණ ස්වයංක්‍රීයකරණය සහ අප කලින් සාකච්ඡා කළ මෙවලම් සන්දර්භය තුළ Terraform සහ Ansible භාවිතා කිරීමේ උදාහරණ කිහිපයක් මෙන්න:

1. Terraform භාවිතා කරන VM සහ පොකුරු වල අවශ්‍ය ලක්ෂණ සහ පරාමිතීන් විස්තර කරන්න.

2. Ansible භාවිතයෙන්, පරීක්ෂණ සඳහා අවශ්‍ය මෙවලම් ස්ථාපනය කරන්න: docker, Selenoid, Selenium Grid සහ අවශ්‍ය බ්‍රව්සර්/ඉමුලේටර් අනුවාද බාගන්න.

3. Terraform භාවිතා කරමින්, GitLab Runner දියත් කෙරෙන VM හි ලක්ෂණ විස්තර කරන්න.

4. GitLab Runner සහ අවශ්‍ය අනුබද්ධ මෙවලම් Ansible භාවිතා කර ස්ථාපනය කරන්න, සැකසීම් සහ වින්‍යාස කිරීම්.

යටිතල පහසුකම්වල වත්මන් තත්ත්වය පිළිබඳ නිදර්ශනය

DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය

ගවේෂණය කිරීමට සබැඳි:

සමාන මෙවලම්

අපි එය සාරාංශ කරමු!

පියවර
තාක්ෂණ
මෙවලම්
ස්වයංක්රීය යටිතල පහසුකම් සඳහා වටිනාකම

1
දේශීය ධාවනය
Node.js, Selenium, Appium

  • වෙබ් සහ ජංගම සඳහා වඩාත් ජනප්රිය මෙවලම්
  • බොහෝ භාෂා සහ වේදිකා සඳහා සහය දක්වයි (Node.js ඇතුළුව)

2
අනුවාද පාලන පද්ධති 
Git

  • සංවර්ධන කේතය සමඟ සමාන ප්රතිලාභ

3
බහාලුම්කරණය
ඩොකර්, සෙලේනියම් ග්‍රිඩ්, සෙලිනොයිඩ් (වෙබ්, ඇන්ඩ්‍රොයිඩ්)

  • පරීක්ෂණ සමාන්තරව ධාවනය කිරීම
  • හුදකලා පරිසරයන්
  • සරල, නම්‍යශීලී අනුවාද වැඩිදියුණු කිරීම්
  • භාවිතයට නොගත් සම්පත් ගතිකව නැවැත්වීම
  • සැකසීමට පහසුය

4
CI/CD
Gitlab CI

  • නල මාර්ගයේ කොටසක් පරීක්ෂා කරයි
  • Страяыстрая обратная связь
  • සමස්ත සමාගම/කණ්ඩායම සඳහා දෘශ්‍යතාව

5
වලාකුළු වේදිකා
Google වලාකුළු වේදිකාව

  • ඉල්ලුම මත සම්පත් (අපි ගෙවන්නේ අවශ්‍ය විටදී පමණි)
  • කළමනාකරණය කිරීමට සහ යාවත්කාලීන කිරීමට පහසුය
  • සියලු සම්පත්වල දෘශ්‍යතාව සහ පාලනය

6
වාද්‍ය වෘන්දය
කුබර්නෙට්ස්
කරල් ඇතුළත බ්‍රව්සර්/ඉමුලේටර් සහිත බහාලුම් සන්දර්භය තුළ:

  • පරිමාණය / ස්වයංක්‍රීය පරිමාණය
  • ස්වයං-සුව කිරීම
  • බාධාවකින් තොරව යාවත්කාලීන කිරීම් සහ ආපසු හැරීම්

7
කේතයක් ලෙස යටිතල පහසුකම් (IaC)
ටෙරාෆෝම්, ඇන්සිබල්

  • සංවර්ධන යටිතල පහසුකම් සමග සමාන ප්රතිලාභ
  • කේත අනුවාදයේ සියලුම වාසි
  • වෙනස්කම් කිරීමට සහ නඩත්තු කිරීමට පහසුය
  • සම්පුර්ණයෙන්ම ස්වයංක්‍රීයයි

මනස සිතියම් රූප සටහන්: යටිතල පහසුකම්වල පරිණාමය

පියවර 1: දේශීය
DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය

පියවර 2: VCS
DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය

පියවර 3: බහාලුම්කරණය 
DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය

පියවර 4: CI/CD 
DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය

පියවර 5: වලාකුළු වේදිකා
DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය

පියවර 6: වාද්‍ය වෘන්දය
DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය

පියවර 7: IaC
DevOps මෙවලම් DevOps සඳහා පමණක් නොවේ. මුල සිටම පරීක්ෂණ ස්වයංක්‍රීයකරණ යටිතල පහසුකම් ගොඩනැගීමේ ක්‍රියාවලිය

ඊළඟට කුමක්ද?

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

ඔබේ පැත්තෙන්
මම මුලින් කී පරිදි, ලිපිය ප්‍රායෝගිකව භාවිතා කිරීමට සහ ඔබ ලබාගත් දැනුම සැබෑ වැඩ සඳහා භාවිතා කිරීමට උපකාරී වේ නම් මම කැමතියි. මම නැවත එකතු කරමි ප්‍රායෝගික මාර්ගෝපදේශයට සබැඳිය.

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

මගේ පැත්තෙන්

මාතෘකාවෙන් පැහැදිලි වන්නේ මෙය පළමු කොටස පමණක් බවයි. එය තරමක් විශාල වුවද, වැදගත් මාතෘකා තවමත් මෙහි ආවරණය කර නොමැත. දෙවන කොටසේදී, IOS හි සන්දර්භය තුළ ස්වයංක්‍රීය යටිතල පහසුකම් දෙස බැලීමට මම අදහස් කරමි. MacOS පද්ධති මත පමණක් iOS සිමියුලේටර් ධාවනය කිරීමට Apple හි සීමා කිරීම් හේතුවෙන්, අපගේ විසඳුම් පරාසය පටු වේ. උදාහරණයක් ලෙස, අපට සිමියුලේටරය ධාවනය කිරීමට ඩොකර් හෝ අතථ්‍ය යන්ත්‍ර ධාවනය කිරීමට පොදු වලාකුළු භාවිතා කළ නොහැක. නමුත් වෙනත් විකල්ප නොමැති බව මින් අදහස් නොවේ. උසස් විසඳුම් සහ නවීන මෙවලම් සමඟින් ඔබව යාවත්කාලීනව තබා ගැනීමට මම උත්සාහ කරමි!

එසේම, මම අධීක්ෂණය සම්බන්ධ තරමක් විශාල මාතෘකා සඳහන් කර නැත. 3 වන කොටසේදී, මම වඩාත් ජනප්‍රිය යටිතල පහසුකම් අධීක්ෂණ මෙවලම් සහ සලකා බැලිය යුතු දත්ත සහ ප්‍රමිතික මොනවාදැයි බැලීමට යන්නෙමි.

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

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

අදහස් එක් කරන්න