කේතය ලෙස යටිතල පහසුකම්: XP භාවිතයෙන් ගැටළු ජය ගන්නේ කෙසේද

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

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

අපි කවුද, අපි කොහෙද සහ අපට ඇති ගැටළු මොනවාද

අපි දැනට ක්‍රමලේඛකයින් හය දෙනෙකු සහ යටිතල පහසුකම් ඉංජිනේරුවන් තිදෙනෙකුගෙන් සමන්විත Sre Onboarding කණ්ඩායමේ සිටිමු. අපි හැමෝම යටිතල පහසුකම් කේතය (IaC) ලෙස ලිවීමට උත්සාහ කරමු. අපි මෙය කරන්නේ අපි මූලික වශයෙන් කේතය ලිවීමට දන්නා නිසා සහ "සාමාන්‍යයට වඩා" සංවර්ධකයින් වීමේ ඉතිහාසයක් ඇති බැවිනි.

• අපට වාසි සමූහයක් ඇත: යම් පසුබිමක්, භාවිතයන් පිළිබඳ දැනුම, කේතය ලිවීමේ හැකියාව, අලුත් දේවල් ඉගෙන ගැනීමට ඇති ආශාව.
• ඒ වගේම අඩුවෙන කොටසක් තියෙනවා, ඒකත් අවාසියක්: යටිතල පහසුකම් දෘඪාංග පිළිබඳ දැනුම නොමැතිකම.

අපගේ IaC හි අප භාවිතා කරන තාක්‍ෂණ තොගය.

• සම්පත් නිර්මාණය කිරීම සඳහා ටෙරාෆෝම්.
• පින්තූර එකලස් කිරීම සඳහා පැකර්. මේවා Windows, CentOS 7 පින්තූර.
• Drone.io හි ප්‍රබල ගොඩනැගීමක් කිරීමට මෙන්ම පැකර් json සහ අපගේ ටෙරාෆෝම් මොඩියුල උත්පාදනය කිරීමට Jsonnet.
• Azure.
• රූප සකස් කිරීමේදී ප්‍රයෝජනවත් වේ.
• සහායක සේවා සහ ප්‍රතිපාදන ස්ක්‍රිප්ට් සඳහා පයිතන්.
• කණ්ඩායම් සාමාජිකයින් අතර බෙදාගත් ප්ලගීන සහිත VSCode හි මේ සියල්ල.

මගේ වෙතින් නිගමනය පසුගිය ලිපිය මෙය මෙසේ විය: මම (පළමුව මා තුළ) ශුභවාදී හැඟීමක් ඇති කිරීමට උත්සාහ කළෙමි, මෙම ප්‍රදේශයේ පවතින දුෂ්කරතා සහ සංකීර්ණතා සමඟ කටයුතු කිරීම සඳහා අප දන්නා ප්‍රවේශයන් සහ භාවිතයන් උත්සාහ කරන බව මට පැවසීමට අවශ්‍ය විය.

අපි දැනට පහත IaC ගැටළු සමඟ පොරබදමින් සිටිමු:

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

Extreme Programming (XP) ගලවා ගැනීමට

සියලුම සංවර්ධකයින් Extreme Programming (XP) සහ එය පිටුපස ඇති භාවිතයන් ගැන හුරුපුරුදුය. අපගෙන් බොහෝ දෙනෙක් මෙම ප්රවේශය සමඟ වැඩ කර ඇති අතර, එය සාර්ථක වී ඇත. එසේනම් යටිතල පහසුකම් අභියෝග ජය ගැනීම සඳහා එහි දක්වා ඇති මූලධර්ම සහ භාවිතයන් භාවිතා නොකරන්නේ මන්ද? අපි තීරණය කළා මේ ප්‍රවේශය අරගෙන මොකද වෙන්නේ කියලා බලන්න.

ඔබේ කර්මාන්තයට XP ප්‍රවේශයේ අදාළත්වය පරීක්ෂා කිරීමමෙන්න XP හොඳින් ගැලපෙන පරිසරය සහ එය අපට සම්බන්ධ වන ආකාරය පිළිබඳ විස්තරයක්:

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

2. නව තාක්ෂණය භාවිතා කරන ස්ථාවර කාල ව්‍යාපෘති නිසා ඇතිවන අවදානම්. අප නොදන්නා සමහර දේවල් භාවිතා කරන විට අපට අවදානම් ඇති විය හැක. මෙය 100% අපගේ නඩුවයි. අපගේ සම්පූර්ණ ව්‍යාපෘතිය වූයේ අපට සම්පූර්ණයෙන්ම හුරුපුරුදු නොවූ තාක්‍ෂණ භාවිතයයි. පොදුවේ ගත් කල, මෙය නිරන්තර ගැටලුවකි, මන්ද ... යටිතල පහසුකම් ක්‍ෂේත්‍රයේ සෑම විටම නව තාක්‍ෂණයන් රැසක් මතුවෙමින් පවතී.

3,4 කුඩා, සම-පිහිටා ඇති දිගු සංවර්ධන කණ්ඩායම. ඔබ භාවිතා කරන ස්වයංක්‍රීය තාක්ෂණය මඟින් ඒකක සහ ක්‍රියාකාරී පරීක්ෂණ සඳහා ඉඩ ලබා දේ. මේ කරුණු දෙක අපට එතරම් ගැළපෙන්නේ නැත. පළමුව, අපි සම්බන්ධීකරණ කණ්ඩායමක් නොවන අතර, දෙවනුව, විශාල කණ්ඩායමක් ලෙස සැලකිය හැකි අපෙන් නව දෙනෙක් සිටිති. "විශාල" කණ්ඩායමක සමහර නිර්වචනවලට අනුව, බොහෝ දෙනෙක් 14+ පුද්ගලයින් වේ.

සමහර XP භාවිතයන් සහ ඒවා ප්‍රතිපෝෂණවල වේගය සහ ගුණාත්මක භාවයට බලපාන ආකාරය බලමු.

XP ප්‍රතිපෝෂණ ලූප මූලධර්මය

මගේ වැටහීම අනුව, ප්‍රතිපෝෂණය යනු ප්‍රශ්නයට පිළිතුරයි, මම කරන්නේ හරි දේද, අපි එහි යනවාද? මේ සඳහා XP සතුව දිව්‍යමය යෝජනා ක්‍රමයක් ඇත: කාල ප්‍රතිපෝෂණ පුඩුවක්. සිත්ගන්නා කරුණ නම්, අප පහත් වන තරමට, අවශ්‍ය ප්‍රශ්නවලට පිළිතුරු සැපයීම සඳහා OS එක වේගවත් කිරීමට අපට හැකි වීමයි.

මෙය සාකච්ඡාවට තරමක් සිත්ගන්නා මාතෘකාවකි, අපගේ තොරතුරු තාක්ෂණ කර්මාන්තයේ ඉක්මනින් OS එකක් ලබා ගත හැකිය. මාස හයක් තිස්සේ ව්‍යාපෘතියක් කර පසුව පමණක් ආරම්භයේදීම වැරැද්දක් සිදුවී ඇති බව සොයා ගැනීම කොතරම් වේදනාකාරීදැයි සිතා බලන්න. මෙය සැලසුම් කිරීමේදී සහ සංකීර්ණ පද්ධතිවල ඕනෑම ඉදිකිරීමකදී සිදු වේ.

අපගේ IaC සම්බන්ධයෙන්, ප්‍රතිපෝෂණය අපට උපකාර කරයි. මම වහාම ඉහත රූප සටහනට කුඩා ගැලපීමක් කරන්නෙමි: මුදා හැරීමේ සැලැස්මට මාසික චක්‍රයක් නොමැත, නමුත් දිනකට කිහිප වතාවක් සිදු වේ. මෙම OS චක්‍රය සමඟ බැඳී ඇති සමහර භාවිතයන් අපි වඩාත් විස්තරාත්මකව බලමු.

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

බලාපොරොත්තු සුන්වීමේ අගාධයෙන් ඔබව ඉවත් කර ගන්නේ කෙසේද: භාවිතයන් තුනක්

පරීක්ෂණ

XP ප්‍රතිපෝෂණ ලූපයේ පරීක්ෂණ දෙවරක් සඳහන් වේ. නිකන් එහෙම නෙවෙයි. සමස්ත Extreme Programming තාක්‍ෂණය සඳහා ඒවා අතිශයින් වැදගත් වේ.

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

සම්භාව්‍ය පරීක්ෂණ පිරමීඩයක් ඇත, එයින් පෙන්නුම් කරන්නේ තවත් පරීක්ෂණ තිබිය යුතු බවයි.

IaC ව්‍යාපෘතියකදී මෙම රාමුව අපට අදාළ වන්නේ කෙසේද? ඇත්තටම... කොහෙත්ම නැහැ.

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

  ඒකාබද්ධතා පරීක්ෂණ පෙනෙන්නේ මෙයයි.

  
  
  Drone CI හි රූප තැනීමේදී මෙය උදාහරණයකි. ඔවුන් වෙත ළඟා වීමට, ඔබට පැකර් රූපය සෑදීමට විනාඩි 30 ක් බලා සිටිය යුතු අතර, පසුව ඒවා සම්මත වන තෙක් තවත් විනාඩි 15 ක් රැඳී සිටින්න. නමුත් ඒවා පවතී!

  රූප සත්‍යාපන ඇල්ගොරිතම

  1. පැකර් මුලින්ම රූපය සම්පූර්ණයෙන්ම සූදානම් කළ යුතුය.
  2. පරීක්ෂණයට යාබදව ප්‍රාදේශීය රාජ්‍යයක් සහිත ටෙරාෆෝම් එකක් ඇත, එය අපි මෙම රූපය යෙදවීමට භාවිතා කරමු.
  3. දිග හැරෙන විට, රූපය සමඟ වැඩ කිරීම පහසු කිරීම සඳහා අසල ඇති කුඩා මොඩියුලයක් භාවිතා කරයි.
  4. රූපයෙන් VM යෙදවූ පසු, චෙක්පත් ආරම්භ කළ හැක. මූලික වශයෙන්, චෙක්පත් මෝටර් රථයකින් සිදු කරනු ලැබේ. එය ආරම්භයේදී ස්ක්‍රිප්ට් ක්‍රියා කළ ආකාරය සහ ඩීමන් ක්‍රියා කරන ආකාරය පරීක්ෂා කරයි. මෙය සිදු කිරීම සඳහා, ssh හෝ winrm හරහා අපි අලුතින් ඔසවන ලද යන්ත්‍රයට ලොග් වී වින්‍යාස තත්ත්වය හෝ සේවා ක්‍රියාත්මක වේද යන්න පරීක්ෂා කරන්න.

• ටෙරාෆෝම් සඳහා මොඩියුලවල ඒකාබද්ධතා පරීක්ෂණ සමඟ තත්වය සමාන වේ. එවැනි පරීක්ෂණවල ලක්ෂණ පැහැදිලි කරන කෙටි වගුවක් මෙන්න.

  
  
  නල මාර්ගයේ ප්රතිචාරය විනාඩි 40 ක් පමණ වේ. සෑම දෙයක්ම ඉතා දිගු කාලයක් සිදු වේ. එය පසුබෑම සඳහා භාවිතා කළ හැකි නමුත් නව සංවර්ධනය සඳහා එය සාමාන්යයෙන් යථාර්ථවාදී නොවේ. ඔබ මේ සඳහා ඉතා සුදානම් නම්, ධාවන ස්ක්‍රිප්ට් සකස් කරන්න, එවිට ඔබට එය විනාඩි 10 දක්වා අඩු කළ හැකිය. නමුත් මේවා තවමත් තත්පර 5 කින් කෑලි 100 ක් කරන Unit tests නොවේ.

රූප හෝ ටෙරාෆෝම් මොඩියුල එකලස් කිරීමේදී ඒකක පරීක්ෂණ නොමැති වීම, REST හරහා හෝ පයිතන් ස්ක්‍රිප්ට් වෙත සරලව ක්‍රියාත්මක කළ හැකි වෙනම සේවාවන් වෙත කාර්යය මාරු කිරීම දිරිමත් කරයි.

උදාහරණයක් ලෙස, අථත්‍ය යන්ත්‍රය ආරම්භ වන විට, එය සේවාව තුළ ලියාපදිංචි වන බවට අපට සහතික විය යුතුය ScaleFT, සහ අතථ්‍ය යන්ත්‍රය විනාශ වූ විට, එය මකා දැමුණි.

අපට ScaleFT සේවාවක් ලෙස ඇති බැවින්, API හරහා එය සමඟ වැඩ කිරීමට අපට බල කෙරෙයි. එහි ලියා තිබුණේ ඔබට ඇදගෙන “ඇතුලට ගිහින් මේකයි අරකයි මකන්න” කියලා කියන්න පුළුවන් කියලා. එය අවශ්ය සියලු සැකසුම් සහ ප්රවේශයන් ගබඩා කරයි.

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

පරීක්ෂණවල ප්රතිඵල: මිනිත්තුවකින් OS ලබා දිය යුතු ඒකක පරීක්ෂාව, එය ලබා නොදේ. පිරමීඩයේ ඉහළ පරීක්ෂණ වර්ග ඵලදායී වන නමුත් ගැටළු වලින් කොටසක් පමණක් ආවරණය කරයි.

යුගල වැඩසටහන්කරණය

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

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

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

IaC මත වැඩ කිරීමේදී යුගල ක්‍රමලේඛන විලාස සහ ඒවායේ අදාළත්වය පහත දැක්වේ:

1. සම්භාව්‍ය, පළපුරුදු + පළපුරුදු, ටයිමරය අනුව මාරු කරන්න. භූමිකාවන් දෙකක් - රියදුරු සහ නාවිකයා. මිනිසුන් දෙදෙනෙක්. ඔවුන් එකම කේතය මත ක්‍රියා කරන අතර යම් නිශ්චිත කාල සීමාවකට පසු භූමිකාවන් මාරු කරයි.

ශෛලිය සමඟ අපගේ ගැටළු වල ගැළපුම සලකා බලමු:

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

IaC හි මෙම ශෛලිය භාවිතා කිරීමේ ප්රධාන ගැටළුව වන්නේ කාර්යයේ අසමාන වේගයයි. සාම්ප්‍රදායික මෘදුකාංග සංවර්ධනයේදී ඔබට ඉතා ඒකාකාරී චලනයක් ඇත. ඔබට විනාඩි පහක් වැය කර N ලියන්න. විනාඩි 10ක් වැය කර 2N, විනාඩි 15 - 3N ලියන්න. මෙන්න ඔබට විනාඩි පහක් ගත කර N ලියන්න, ඉන්පසු තවත් විනාඩි 30 ක් වැය කර N වලින් දශමයක් ලියන්න. මෙන්න ඔබ කිසිවක් දන්නේ නැහැ, ඔබ හිරවෙලා, මෝඩයි. විමර්ශනය සඳහා කාලය ගත වන අතර වැඩසටහන්කරණයෙන් ම අවධානය වෙනතකට යොමු කරයි.

නිගමනය: එහි පිරිසිදු ස්වරූපයෙන් එය අපට සුදුසු නොවේ.

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

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

නිගමනය: අහෝ, කාර්යයේ වේගය IaC හි යුගල ක්‍රමලේඛන පුහුණුවක් ලෙස ping-pong භාවිතා කිරීමට ඉඩ නොදේ.

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

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

නිගමනය: එය භාවිතා කළ හැකිය, අපි උත්සාහය අත් නොහරිමු.

4. Mobbing, swarming සහ සියලු දන්නා නමුත් ලැයිස්තුගත නොකළ මෝස්තර අපි එය සලකන්නේ නැත, මන්ද අපි එය උත්සාහ කර නැති අතර අපගේ කාර්යයේ සන්දර්භය තුළ ඒ ගැන කතා කළ නොහැක.

යුගල ක්‍රමලේඛනය භාවිතා කිරීමේ සාමාන්‍ය ප්‍රතිඵල:

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

5. එසේ තිබියදීත්, සාර්ථක විය. අපි අපේම ක්‍රමයක් “අභිසාරී - අපසරනය” ඉදිරිපත් කළෙමු. එය ක්‍රියාත්මක වන ආකාරය කෙටියෙන් විස්තර කරමි.

අපට දින කිහිපයකට (සතියකට අඩු) ස්ථිර හවුල්කරුවන් සිටී. අපි එකට එක වැඩක් කරනවා. අපි ටික වේලාවක් එකට වාඩි වී සිටිමු: එක් අයෙක් ලියයි, අනෙකා වාඩි වී සහායක කණ්ඩායම දෙස බලයි. ඊට පස්සේ අපි ටික වෙලාවක් විසිරෙනවා, එක එක්කෙනා සමහර ස්වාධීන දේවල් කරනවා, ඊට පස්සේ අපි ආයෙත් එකතු වෙනවා, ඉතා ඉක්මනින් සමමුහුර්ත වෙනවා, එකට යමක් කරලා ආපහු විසිරෙනවා.

සැලසුම් කිරීම සහ සන්නිවේදනය

මෙහෙයුම් පද්ධතියේ ගැටළු විසඳන අවසාන භාවිතයන් වන්නේ කාර්යයන් සමඟ වැඩ කිරීම සංවිධානය කිරීමයි. යුගල කාර්යයෙන් පිටත අත්දැකීම් හුවමාරුව ද මෙයට ඇතුළත් ය. අපි පුරුදු තුනක් බලමු:

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

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

කාර්යයන් පිළිබඳ දෘශ්‍ය දර්ශනයේ වාසි:

• හේතුඵලවාදය. සෑම කාර්යයක්ම යම් ගෝලීය ඉලක්කයකට මඟ පාදයි. කාර්යයන් කුඩා ඉලක්ක වලට කාණ්ඩගත කර ඇත. යටිතල පහසුකම් වසම තරමක් තාක්ෂණික ය. උදාහරණයක් ලෙස, වෙනත් nginx වෙත සංක්‍රමණය වීම පිළිබඳ ධාවන පොතක් ලිවීමෙන් ව්‍යාපාරයට ඇති විශේෂිත බලපෑම කුමක්ද යන්න සැමවිටම පැහැදිලි නැත. ඉලක්ක කාඩ්පත ළඟ තිබීමෙන් එය වඩාත් පැහැදිලි වේ.
  
  හේතු කාරකය ගැටළු වල වැදගත් දේපලකි. එය කෙලින්ම ප්‍රශ්නයට පිළිතුරු සපයයි: “මම කරන්නේ හරි දේද?”
• සමාන්තරවාදය. අපෙන් නව දෙනෙක් සිටින අතර, සෑම කෙනෙකුම එක් කාර්යයකට විසි කිරීම භෞතිකව කළ නොහැකි ය. එක් ප්‍රදේශයකින් කෙරෙන කාර්යයන් සෑම විටම ප්‍රමාණවත් නොවිය හැක. කුඩා වැඩ කරන කණ්ඩායම් අතර වැඩ සමාන්තර කිරීමට අපට බල කෙරෙයි. ඒ අතරම, කණ්ඩායම් ටික වේලාවක් ඔවුන්ගේ කාර්යයේ වාඩි වී සිටින අතර, ඔවුන් වෙනත් අයෙකු විසින් ශක්තිමත් කළ හැකිය. සමහර වෙලාවට මිනිස්සු මේ වැඩ කරන කණ්ඩායමෙන් ඈත් වෙනවා. කවුරුහරි නිවාඩුවක් ගත කරනවා, කවුරුහරි DevOps conf සඳහා වාර්තාවක් හදනවා, කවුරුහරි Habr ගැන ලිපියක් ලියනවා. සමාන්තරව කළ හැකි ඉලක්ක සහ කාර්යයන් දැන ගැනීම ඉතා වැදගත් වේ.

2. උදෑසන රැස්වීම්වල ආදේශක ඉදිරිපත් කරන්නන්. නැගී සිටීමේදී අපට මෙම ගැටලුව ඇත - මිනිසුන් බොහෝ කාර්යයන් සමාන්තරව කරයි. සමහර විට කාර්යයන් ලිහිල් ලෙස සම්බන්ධ වී ඇති අතර කවුරුන් කරන්නේද යන්න පිළිබඳ අවබෝධයක් නොමැත. තවද කණ්ඩායමේ තවත් සාමාජිකයෙකුගේ මතය ඉතා වැදගත් වේ. මෙය ගැටළුව විසඳීමේ මාර්ගය වෙනස් කළ හැකි අතිරේක තොරතුරු වේ. ඇත්ත වශයෙන්ම, සාමාන්යයෙන් ඔබ සමඟ යමෙකු සිටී, නමුත් උපදෙස් සහ ඉඟි සෑම විටම ප්රයෝජනවත් වේ.

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

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

එක එකාට කරපු වැඩේ පෙන්නලා ඊට පස්සේ සාකච්චා කරලා විසදුම හම්බුනා. අපි සතියකට වරක් පැයකට වරක් හමු වී පසුගිය සතිය පුරාවට අප කළ කාර්යයන් සඳහා විසඳුම් විස්තර පෙන්වමු.

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

පිරික්සුම් ලැයිස්තුවක් භාවිතයෙන් වාර්තාව පැවැත්විය හැකිය.1. සන්දර්භයට ඇතුළු වන්න. කාර්යය පැමිණියේ කොහෙන්ද, එය පවා අවශ්ය වූයේ ඇයි?

2. ගැටලුව කලින් විසඳා ගත්තේ කෙසේද? උදාහරණයක් ලෙස, විශාල මූසික ක්ලික් කිරීමක් අවශ්‍ය විය, නැතහොත් කිසිවක් කළ නොහැකි විය.

3. අපි එය වැඩිදියුණු කරන ආකාරය. උදාහරණයක් ලෙස: "බලන්න, දැන් scriptosik තියෙනවා, මෙන්න readme."

4. එය ක්‍රියා කරන ආකාරය පෙන්වන්න. සමහර පරිශීලක අවස්ථා සෘජුවම ක්රියාත්මක කිරීම යෝග්ය වේ. මට X අවශ්‍යයි, මම Y කරනවා, මම Y (හෝ Z) දකිනවා. උදාහරණයක් ලෙස, මම NGINX යොදවා, url දුම් පානය කර, 200 හරි ලබා ගන්නෙමි. ක්‍රියාව දිගු නම්, ඔබට එය පසුව පෙන්විය හැකි වන පරිදි එය කල්තියා සූදානම් කරන්න. එය බිඳෙනසුලු නම්, නිරූපණයට පැයකට පෙර එය නොකැඩීම සුදුසුය.

5. ගැටලුව කෙතරම් සාර්ථකව විසඳා ඇත්ද, ඉතිරිව ඇති දුෂ්කරතා මොනවාද, සම්පූර්ණ නොකළ දේ, අනාගතයේදී කළ හැකි වැඩිදියුණු කිරීම් මොනවාද යන්න පැහැදිලි කරන්න. උදාහරණයක් ලෙස, දැන් CLI, එවිට CI හි සම්පූර්ණ ස්වයංක්රීයකරණයක් වනු ඇත.

සෑම කථිකයෙකුටම එය විනාඩි 5-10 දක්වා තබා ගැනීම යෝග්ය වේ. ඔබේ කථාව පැහැදිලිවම වැදගත් සහ වැඩි කාලයක් ගත වන්නේ නම්, sre-takeover නාලිකාවේ මෙය කල්තියා සම්බන්ධීකරණය කරන්න.

මුහුණට මුහුණ පාට් එකෙන් පස්සේ ත්‍රෙඩ් එකේ හැමදාම කතා කරනවා. අපගේ කාර්යයන් පිළිබඳව අපට අවශ්‍ය ප්‍රතිපෝෂණය දිස්වන්නේ මෙහිදීය.

එහි ප්රතිඵලයක් වශයෙන්, සිදුවෙමින් පවතින දේවල ප්රයෝජනවත් බව තීරණය කිරීම සඳහා සමීක්ෂණයක් පවත්වනු ලැබේ. මෙය කථාවේ සාරය සහ කාර්යයේ වැදගත්කම පිළිබඳ ප්රතිචාරයකි.

දිගු නිගමන සහ ඊළඟ දේ

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

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

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

මෙහෙයුම් පද්ධතියට බලපෑම් කිරීමේ ඉහළ මට්ටමේ ක්‍රම - සැලසුම් කිරීම සහ කාර්යයන් සමඟ වැඩ කිරීම නිශ්චිතවම බලපෑම් ඇති කරයි: උසස් තත්ත්වයේ දැනුම හුවමාරුව සහ වැඩිදියුණු කළ සංවර්ධන ගුණාත්මකභාවය.

එක් පේළියක කෙටි නිගමන

• මානව සම්පත් වෘත්තිකයන් IaC හි වැඩ කරයි, නමුත් අඩු කාර්යක්ෂමතාවයක් ඇත.
• වැඩ කරන දේ ශක්තිමත් කරන්න.
• ඔබේම වන්දි යාන්ත්‍රණ සහ භාවිතයන් සමඟ එන්න.

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