ස්ක්‍රිප්ට් වලින් අපේම වේදිකාවට: අපි CIAN හි සංවර්ධනය ස්වයංක්‍රීය කළ ආකාරය

ස්ක්‍රිප්ට් වලින් අපේම වේදිකාවට: අපි CIAN හි සංවර්ධනය ස්වයංක්‍රීය කළ ආකාරය

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

ශුන්ය මට්ටම

"ශුන්‍ය මට්ටමක් කියා දෙයක් නැත, මම එවැනි දෙයක් නොදනිමි"
"කුං ෆු පැන්ඩා" චිත්‍රපටයේ මාස්ටර් ෂිෆු

CIAN හි ස්වයංක්‍රීයකරණය ආරම්භ වූයේ සමාගම ආරම්භ කර වසර 14 කට පසුවය. එතකොට සංවර්ධන කණ්ඩායමේ 35 දෙනෙක් හිටියා. විශ්වාස කරන්න අමාරුයි නේද? ඇත්ත වශයෙන්ම, ස්වයංක්‍රීයකරණය යම් ආකාරයක පැවතුනි, නමුත් අඛණ්ඩ ඒකාබද්ධ කිරීම සහ කේත බෙදා හැරීම සඳහා වෙනම දිශාවක් 2015 දී හැඩගැසීමට පටන් ගත්තේය. 

ඒ වන විට අප සතුව ලිනක්ස්/වින්ඩෝස් සර්වර් මත යොදවා තිබූ පයිතන්, සී# සහ PHP විශාල ඒකලිතයක් තිබුණි. මෙම රකුසා යෙදවීමට, අපි අතින් ධාවනය කළ ස්ක්‍රිප්ට් කට්ටලයක් අප සතුව තිබුණි. ශාඛා ඒකාබද්ධ කිරීමේදී, අඩුපාඩු නිවැරදි කිරීමේදී සහ "ගොඩනැගීමේ වෙනස් කාර්යයන් සමඟ" නැවත ගොඩනැඟීමේදී ගැටුම් හේතුවෙන් වේදනාව සහ දුක් වේදනා ගෙන එන මොනොලිත් එකලස් කිරීම ද විය. සරල කළ ක්‍රියාවලියක් මේ ආකාරයට දිස් විය:

ස්ක්‍රිප්ට් වලින් අපේම වේදිකාවට: අපි CIAN හි සංවර්ධනය ස්වයංක්‍රීය කළ ආකාරය

අපි මේ ගැන සතුටු නොවූ අතර, අපට නැවත නැවතත් කළ හැකි, ස්වයංක්‍රීය සහ කළමනාකරණය කළ හැකි ගොඩනැගීමේ සහ යෙදවීමේ ක්‍රියාවලියක් ගොඩනැගීමට අවශ්‍ය විය. මේ සඳහා, අපට CI/CD පද්ධතියක් අවශ්‍ය වූ අතර, අපි ඔවුන් සමඟ වැඩ කළ නිසාත්, ක්‍රියාකාරීත්වය අනුව දෙකම අපට ගැලපෙන නිසාත්, අපි Teamcity හි නිදහස් අනුවාදය සහ Jenkins හි නිදහස් අනුවාදය අතර තෝරා ගත්තෙමු. අපි Teamcity වඩාත් මෑතකාලීන නිෂ්පාදනයක් ලෙස තෝරා ගත්තෙමු. ඒ වන විට අපි තවමත් ක්ෂුද්‍ර සේවා ගෘහ නිර්මාණ ශිල්පය භාවිතා කර නොතිබූ අතර විශාල කාර්යයන් සහ ව්‍යාපෘති ප්‍රමාණයක් අපේක්ෂා නොකළෙමු.

අපි අපේම පද්ධතියක් පිළිබඳ අදහසට පැමිණෙමු

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

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

ව්‍යාපාර ක්‍රියාවලීන්හි ස්වයංක්‍රීයකරණය වැඩිවීම හේතුවෙන් Teamcity හි ව්‍යාපෘති සහ ධාවන සංඛ්‍යාව වැඩි වී ඇත. එබැවින් නව ගැටලුවක් පැමිණියේය: එක් නොමිලේ Teamcity අවස්ථාවක් ප්‍රමාණවත් නොවීය (නියෝජිතයින් 3 ක් සහ ව්‍යාපෘති 100 ක්), අපි තවත් අවස්ථාවක් (තවත් නියෝජිතයින් 3 ක් සහ ව්‍යාපෘති 100 ක්) එකතු කළෙමු. එහි ප්‍රතිඵලයක් වශයෙන්, අපි කළමනාකරණය කිරීමට අපහසු වූ පොකුරු කිහිපයක පද්ධතියක් සමඟ අවසන් කළෙමු:

ස්ක්‍රිප්ට් වලින් අපේම වේදිකාවට: අපි CIAN හි සංවර්ධනය ස්වයංක්‍රීය කළ ආකාරය

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

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

අපි පරීක්ෂණය ස්වයංක්‍රීය කරන්නෙමු

ස්ක්‍රිප්ට් වලින් අපේම වේදිකාවට: අපි CIAN හි සංවර්ධනය ස්වයංක්‍රීය කළ ආකාරය

නිකුතු ස්වයංක්‍රීය කිරීම හේතුවෙන්, සංවර්ධන ක්‍රියාවලීන් වේගවත් වී ඇත, අර්ධ වශයෙන් සමහර පරීක්ෂණ අදියර මඟ හැරීම හේතුවෙන්. තවද මෙය තාවකාලික ගුණාත්මකභාවය නැතිවීමට හේතු විය. එය සුළු දෙයක් ලෙස පෙනේ, නමුත් නිකුතුවේ ත්වරණය සමඟ නිෂ්පාදන සංවර්ධන ක්‍රමවේදය වෙනස් කිරීම අවශ්‍ය විය. නිකුත් කරන ලද කේතය සහ එහි ඇති දෝෂ සඳහා සංවර්ධකයාගේ පරීක්ෂණ ස්වයංක්‍රීය කිරීම, පුද්ගලික වගකීම ඇති කිරීම (මෙහි අපි කතා කරන්නේ “මුදල් දඩ මුදල් නොව “හිසෙහි අදහස පිළිගැනීම” ගැන) මෙන්ම තීරණය ගැන සිතීම අවශ්‍ය විය. ස්වයංක්‍රීය යෙදවීම හරහා කාර්යයක් මුදා හැරීම/නොහැරීම. 

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

ස්වයංක්රීය කණ්ඩායම

අප සතුව දැනට සංවර්ධකයින් 130 දෙනෙකුගෙන් යුත් කාර්ය මණ්ඩලයක් සිටින අතර අපි දිගටම කරගෙන යන්නෙමු වැඩෙන්න. අඛණ්ඩ ඒකාබද්ධ කිරීම සහ කේත බෙදා හැරීම සඳහා කණ්ඩායම (මෙතැන් සිට යෙදවීම සහ ඒකාබද්ධ කිරීම හෝ DI කණ්ඩායම ලෙස හැඳින්වේ) පුද්ගලයන් 7 දෙනෙකුගෙන් සමන්විත වන අතර දිශාවන් 2කින් ක්‍රියා කරයි: Integro ස්වයංක්‍රීය වේදිකාව සහ DevOps සංවර්ධනය. 

DevOps CIAN අඩවියේ Dev/Beta පරිසරය, Integro පරිසරය සඳහා වගකිව යුතු අතර, සංවර්ධකයින්ට ගැටළු විසඳීමට සහ පරිමාණ පරිසරයන් සඳහා නව ප්‍රවේශයන් වර්ධනය කිරීමට උපකාරී වේ. Integro සංවර්ධන දිශාව Integro ම සහ අදාළ සේවාවන් සමඟ කටයුතු කරයි, උදාහරණයක් ලෙස, Jenkins, Jira, Confluence සඳහා ප්ලගීන, සහ සංවර්ධන කණ්ඩායම් සඳහා සහායක උපයෝගිතා සහ යෙදුම් සංවර්ධනය කරයි. 

DI කණ්ඩායම ගෘහ නිර්මාණ ශිල්පය, පුස්තකාල සහ සංවර්ධන ප්‍රවේශයන් අභ්‍යන්තරව සංවර්ධනය කරන Platform කණ්ඩායම සමඟ සහයෝගයෙන් ක්‍රියා කරයි. ඒ අතරම, CIAN තුළ සිටින ඕනෑම සංවර්ධකයෙකුට ස්වයංක්‍රීයකරණයට දායක විය හැකිය, උදාහරණයක් ලෙස, කණ්ඩායමේ අවශ්‍යතාවලට සරිලන පරිදි ක්ෂුද්‍ර ස්වයංක්‍රීයකරණය කිරීම හෝ ස්වයංක්‍රීයකරණය වඩාත් හොඳ කරන්නේ කෙසේද යන්න පිළිබඳ සිසිල් අදහසක් බෙදා ගන්න.

CIAN හි ස්වයංක්‍රීයකරණයේ ස්ථර කේක්

ස්ක්‍රිප්ට් වලින් අපේම වේදිකාවට: අපි CIAN හි සංවර්ධනය ස්වයංක්‍රීය කළ ආකාරය

ස්වයංක්‍රීයකරණයට සම්බන්ධ සියලුම පද්ධති ස්ථර කිහිපයකට බෙදිය හැකිය:

  1. බාහිර පද්ධති (ජිරා, බිට්බකට්, ආදිය). සංවර්ධන කණ්ඩායම් ඔවුන් සමඟ වැඩ කරයි.
  2. Integro වේදිකාව. බොහෝ විට, සංවර්ධකයින් එය සමඟ කෙලින්ම වැඩ නොකරයි, නමුත් එය සියලු ස්වයංක්‍රීයකරණය ක්‍රියාත්මක කරයි.
  3. බෙදා හැරීම, වාද්‍ය වෘන්දය සහ සොයාගැනීම් සේවා (උදාහරණයක් ලෙස, ජෙක්නින්ස්, කොන්සල්, නෝමාඩ්). ඔවුන්ගේ සහාය ඇතිව, අපි සේවාදායකයන් මත කේතය යොදවා සේවාවන් එකිනෙකා සමඟ ක්‍රියා කරන බව සහතික කරමු.
  4. භෞතික ස්ථරය (සේවාදායක, මෙහෙයුම් පද්ධතිය, අදාළ මෘදුකාංග). අපගේ කේතය මෙම මට්ටමේ ක්‍රියාත්මක වේ. මෙය භෞතික සේවාදායකයක් හෝ අතථ්‍ය එකක් විය හැකිය (LXC, KVM, Docker).

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

නොවෙනස්ව

අපි Integro වෙත අවධානය යොමු කර තාක්ෂණික තොගයෙන් පටන් ගනිමු:

  • CentOS 7
  • Docker + Nomad + Consul + Vault
  • Java 11 (පැරණි Integro monolith එක Java 8 මත පවතිනු ඇත)
  • Spring Boot 2.X + Spring Cloud Config
  • PostgreSql 11
  • හාවා එම්.කේ. 
  • Apache Ignite
  • කැමුන්ඩා (කාවැද්දූ)
  • Grafana + Graphite + Prometheus + Jaeger + ELK
  • වෙබ් UI: ප්‍රතික්‍රියා (CSR) + MobX
  • SSO: Keycloak

Integro හි මුල් පිටපතක මොනොලිත් ස්වරූපයෙන් අපට උරුමයක් තිබුණද, අපි ක්ෂුද්‍ර සේවා සංවර්ධන මූලධර්මයට අනුගත වන්නෙමු. සෑම ක්ෂුද්‍ර සේවාවක්ම තමන්ගේම ඩොකර් කන්ටේනරය තුළ ක්‍රියාත්මක වන අතර, සේවාවන් HTTP ඉල්ලීම් සහ RabbitMQ පණිවිඩ හරහා එකිනෙකා සමඟ සන්නිවේදනය කරයි. ක්ෂුද්‍ර සේවා කොන්සල් හරහා එකිනෙකා සොයාගෙන ඒ සඳහා ඉල්ලීමක් කරයි, SSO (Keycloak, OAuth 2/OpenID Connect) හරහා අනුමැතිය ලබා දෙයි.

ස්ක්‍රිප්ට් වලින් අපේම වේදිකාවට: අපි CIAN හි සංවර්ධනය ස්වයංක්‍රීය කළ ආකාරය

සැබෑ ජීවිතයේ උදාහරණයක් ලෙස, පහත පියවර වලින් සමන්විත ජෙන්කින්ස් සමඟ අන්තර් ක්‍රියා කිරීම සලකා බලන්න:

  1. කාර්ය ප්‍රවාහ කළමනාකරණ ක්ෂුද්‍ර සේවයට (මෙතැන් සිට ප්‍රවාහ ක්ෂුද්‍ර සේවා ලෙස හැඳින්වේ) ජෙන්කින්ස් හි ගොඩනැගීමක් ක්‍රියාත්මක කිරීමට අවශ්‍යයි. මෙය සිදු කිරීම සඳහා, ඔහු ජෙන්කින්ස් සමඟ ඒකාබද්ධ කිරීම සඳහා මයික්‍රො සර්විස් හි IP: PORT සොයා ගැනීමට කොන්සල් භාවිතා කරයි (මින් ඉදිරියට ජෙන්කින්ස් මයික්‍රො සර්විස් ලෙස හැඳින්වේ) සහ ජෙන්කින්ස් හි ගොඩනැගීම ආරම්භ කිරීමට අසමමුහුර්ත ඉල්ලීමක් යවයි.
  2. ඉල්ලීමක් ලැබීමෙන් පසු, Jenkins microservice විසින් රැකියා හැඳුනුම්පතක් උත්පාදනය කර ප්‍රතිචාර දක්වයි, පසුව එය කාර්යයේ ප්‍රතිඵලය හඳුනා ගැනීමට භාවිතා කළ හැක. ඒ අතරම, එය REST API ඇමතුමක් හරහා ජෙන්කින්ස් හි ගොඩනැගීමට ක්‍රියා කරයි.
  3. ජෙන්කින්ස් විසින් ගොඩනැගීම සිදු කරන අතර, අවසන් වූ පසු, ක්‍රියාත්මක කිරීමේ ප්‍රතිඵල සහිත webhook එකක් Jenkins microservice වෙත යවයි.
  4. Jenkins microservice, webhook ලැබුණු පසු, ඉල්ලීම් සැකසීම සම්පූර්ණ කිරීම පිළිබඳ පණිවිඩයක් ජනනය කර එය ක්රියාත්මක කිරීමේ ප්රතිඵල අනුයුක්ත කරයි. ජනනය කරන ලද පණිවිඩය RabbitMQ පෝලිමට යවනු ලැබේ.
  5. RabbitMQ හරහා, ප්‍රකාශිත පණිවිඩය Flow microservice වෙත ළඟා වන අතර, එය ඉල්ලීම සහ ලැබුණු පණිවිඩයෙන් රැකියා හැඳුනුම්පත ගැලපීමෙන් එහි කාර්යය සැකසීමේ ප්‍රතිඵලය ගැන ඉගෙන ගනී.

දැන් අපට ක්ෂුද්‍ර සේවා 30 ක් පමණ ඇත, ඒවා කණ්ඩායම් කිහිපයකට බෙදිය හැකිය:

  1. වින්යාස කළමනාකරණය.
  2. පරිශීලකයින් සමඟ තොරතුරු සහ අන්තර්ක්‍රියා (පණිවුඩකරුවන්, තැපෑල).
  3. මූල කේතය සමඟ වැඩ කිරීම.
  4. යෙදවුම් මෙවලම් සමඟ ඒකාබද්ධ කිරීම (ජෙන්කින්ස්, නෝමාඩ්, කොන්සල්, ආදිය).
  5. අධීක්ෂණය (නිදහස්, දෝෂ, ආදිය).
  6. වෙබ් උපයෝගිතා (පරීක්ෂණ පරිසරයන් කළමනාකරණය කිරීම සඳහා UI, සංඛ්යා ලේඛන එකතු කිරීම, ආදිය).
  7. කාර්ය ට්රැකර් සහ සමාන පද්ධති සමඟ ඒකාබද්ධ කිරීම.
  8. විවිධ කාර්යයන් සඳහා කාර්ය ප්රවාහ කළමනාකරණය.

කාර්ය ප්රවාහ කාර්යයන්

Integro කාර්ය ජීවන චක්‍රයට අදාළ ක්‍රියාකාරකම් ස්වයංක්‍රීය කරයි. සරල වචන වලින්, කාර්යයක ජීවන චක්‍රය ජිරා හි කාර්යයක කාර්ය ප්‍රවාහය ලෙස වටහා ගනු ඇත. අපගේ සංවර්ධන ක්‍රියාවලීන් ව්‍යාපෘතිය, කාර්යයේ වර්ගය සහ යම් කාර්යයක් තුළ තෝරාගත් විකල්ප මත පදනම්ව කාර්ය ප්‍රවාහ වෙනස්කම් කිහිපයක් ඇත. 

අපි බොහෝ විට භාවිතා කරන කාර්ය ප්රවාහය දෙස බලමු:

ස්ක්‍රිප්ට් වලින් අපේම වේදිකාවට: අපි CIAN හි සංවර්ධනය ස්වයංක්‍රීය කළ ආකාරය

රූප සටහනේ, ගියර් එකෙන් පෙන්නුම් කරන්නේ සංක්‍රාන්තිය ස්වයංක්‍රීයව Integro විසින් හඳුන්වනු ලබන අතර, මිනිස් රූපයෙන් පෙන්නුම් කරන්නේ සංක්‍රාන්තිය පුද්ගලයෙකු විසින් අතින් හඳුන්වනු ලබන බවයි. මෙම කාර්ය ප්‍රවාහයේදී කාර්යයකට යා හැකි මාර්ග කිහිපයක් බලමු.

කැනරි පරීක්ෂණ නොමැතිව DEV+BETA මත සම්පුර්ණයෙන්ම අතින් පරීක්ෂා කිරීම (සාමාන්‍යයෙන් අපි මොනොලිත් එකක් මුදා හරින්නේ මෙහෙමයි):

ස්ක්‍රිප්ට් වලින් අපේම වේදිකාවට: අපි CIAN හි සංවර්ධනය ස්වයංක්‍රීය කළ ආකාරය

වෙනත් සංක්රාන්ති සංයෝජන තිබිය හැක. සමහර විට ජිරා හි ඇති විකල්ප හරහා ගැටළුවක් ඇති මාර්ගය තෝරා ගත හැකිය.

කාර්ය චලනය

“DEV Testing + Canary Tests” කාර්ය ප්‍රවාහය හරහා කාර්යයක් චලනය වන විට සිදු කරන ප්‍රධාන පියවර දෙස බලමු:

1. සංවර්ධකයා හෝ PM කාර්යය නිර්මාණය කරයි.

2. සංවර්ධකයා කාර්යය භාර ගනී. සම්පුර්ණ වූ පසු, එය IN REVIEW තත්ත්වයට මාරු වේ.

3. ජිරා ජිරා ක්ෂුද්‍ර සේවාව වෙත වෙබ්හුක් යවයි (ජිරා සමඟ ඒකාබද්ධ වීම සඳහා වගකීම දරයි).

4. Jira microservice විසින් Flow සේවාව වෙත ඉල්ලීමක් යවයි (වැඩ සිදු කරන අභ්‍යන්තර වැඩ ප්‍රවාහයන් සඳහා වගකිව යුතු) වැඩ ප්‍රවාහය ආරම්භ කිරීමට.

5. ප්‍රවාහ සේවාව ඇතුළත:

  • සමාලෝචකයින් කාර්යයට පවරනු ලැබේ (පරිශීලකයින් + ජිරා ක්ෂුද්‍ර සේවා පිළිබඳ සියල්ල දන්නා පරිශීලක ක්ෂුද්‍ර සේවා).
  • Source microservice හරහා (එය නිධිය සහ ශාඛා ගැන දන්නා නමුත් කේතය සමඟම ක්‍රියා නොකරයි), අපගේ නිකුතුවේ ශාඛාවක් අඩංගු ගබඩා සඳහා සෙවීමක් සිදු කරනු ලැබේ (සෙවීම සරල කිරීමට, ශාඛාවේ නම ගැටලුව සමඟ සමපාත වේ. ජිරා හි අංකය). බොහෝ විට, කාර්යයකට ඇත්තේ එක් ගබඩාවක එක් ශාඛාවක් පමණි; මෙය යෙදවුම් පෝලිමේ කළමනාකරණය සරල කරන අතර ගබඩා අතර සම්බන්ධතාවය අඩු කරයි.
  • සොයාගත් එක් එක් ශාඛාව සඳහා, පහත දැක්වෙන ක්රියා අනුපිළිවෙල සිදු කරනු ලැබේ:

    i) ප්‍රධාන ශාඛාව යාවත්කාලීන කිරීම (කේතය සමඟ වැඩ කිරීම සඳහා Git microservice).
    ii) සංවර්ධකයා (Bitbucket microservice) විසින් ශාඛාව වෙනස්කම් වලින් අවහිර කර ඇත.
    iii) මෙම ශාඛාව (Bitbucket microservice) සඳහා Pull ඉල්ලීමක් නිර්මාණය කර ඇත.
    iv) නව අදින්න ඉල්ලීමක් පිළිබඳ පණිවිඩයක් සංවර්ධක කතාබස් වෙත යවනු ලැබේ (දැනුම්දීම් සමඟ වැඩ කිරීම සඳහා ක්ෂුද්‍ර සේවාවට දැනුම් දෙන්න).
    v) DEV (Jenkins සමඟ වැඩ කිරීම සඳහා Jenkins microservice) මත කාර්යයන් ගොඩනැගීම, පරීක්ෂා කිරීම සහ යෙදවීම ආරම්භ කර ඇත.
    vi) පෙර පියවර සියල්ල සාර්ථකව නිම කර ඇත්නම්, ඉන්ටෙග්‍රෝ විසින් එහි අනුමැතිය අදින්න ඉල්ලීමෙහි (බිට්බකට් මයික්‍රො සර්විස්) දමයි.

  • Integro නම් කරන ලද සමාලෝචකයින්ගෙන් පුල් ඉල්ලීම අනුමත කිරීමට බලා සිටී.
  • අවශ්‍ය සියලුම අනුමැතීන් ලැබුණු වහාම (ස්වයංක්‍රීය පරීක්ෂණ ධනාත්මකව සමත් වීම ඇතුළුව), Integro විසින් එම කාර්යය Dev මත Test (Jira microservice) තත්ත්වයට මාරු කරයි.

6. පරීක්ෂකයන් කාර්යය පරීක්ෂා කරයි. ගැටළු නොමැති නම්, කාර්යය ගොඩනැගීමට සූදානම් තත්ත්වයට මාරු කරනු ලැබේ.

7. කාර්යය මුදා හැරීමට සූදානම් බව Integro "දකියි" සහ කැනරි මාදිලියේ (Jenkins microservice) එහි යෙදවීම ආරම්භ කරයි. මුදා හැරීම සඳහා ඇති සූදානම නීති මාලාවක් මගින් තීරණය වේ. උදාහරණයක් ලෙස, කාර්යය අවශ්‍ය තත්වයේ ඇත, වෙනත් කාර්යයන් සඳහා අගුලු නොමැත, දැනට මෙම ක්ෂුද්‍ර සේවාවේ සක්‍රිය උඩුගත කිරීම් නොමැත, ආදිය.

8. කාර්යය කැනරි තත්ත්වයට මාරු කරනු ලැබේ (ජිරා ක්ෂුද්ර සේවා).

9. Jenkins Nomad හරහා කැනරි මාදිලියේ යෙදවීමේ කාර්යයක් දියත් කරයි (සාමාන්‍යයෙන් අවස්ථා 1-3 ක්) සහ යෙදවීම පිළිබඳව මුදා හැරීමේ අධීක්ෂණ සේවාව (DeployWatch microservice) වෙත දැනුම් දෙයි.

10. DeployWatch microservice දෝෂ පසුබිම එකතු කර අවශ්‍ය නම් එයට ප්‍රතිචාර දක්වයි. දෝෂ පසුබිම ඉක්මවා ඇත්නම් (පසුබිම් සම්මතය ස්වයංක්‍රීයව ගණනය කරනු ලැබේ), සංවර්ධකයින්ට Notify microservice හරහා දැනුම් දෙනු ලැබේ. මිනිත්තු 5 කට පසුව සංවර්ධකයා ප්‍රතිචාර දක්වා නොමැති නම් (ප්‍රතිවර්තනය කරන්න හෝ රැඳී සිටින්න ක්ලික් කරන්න), එවිට කැනරි අවස්ථා වල ස්වයංක්‍රීය ආපසු හැරීමක් දියත් කෙරේ. පසුබිම ඉක්මවා නොමැති නම්, සංවර්ධකයා විසින් නිෂ්පාදනයට කාර්යය යෙදවීම අතින් දියත් කළ යුතුය (UI හි බොත්තමක් ක්ලික් කිරීමෙන්). මිනිත්තු 60 ක් ඇතුළත සංවර්ධකයා නිෂ්පාදනයට යෙදවීම දියත් කර නොමැති නම්, ආරක්ෂක හේතූන් මත කැනරි අවස්ථා ද ආපසු හරවනු ලැබේ.

11. නිෂ්පාදනයට යෙදවීම දියත් කිරීමෙන් පසු:

  • කාර්යය නිෂ්පාදන තත්ත්වය (ජිරා ක්ෂුද්ර සේවා) වෙත මාරු කරනු ලැබේ.
  • Jenkins microservice යෙදවීමේ ක්‍රියාවලිය ආරම්භ කරන අතර යෙදවීම පිළිබඳව DeployWatch microservice වෙත දැනුම් දෙයි.
  • DeployWatch microservice නිෂ්පාදනයේ ඇති සියලුම බහාලුම් යාවත්කාලීන කර ඇත්දැයි පරීක්ෂා කරයි (සියල්ලම යාවත්කාලීන නොකළ අවස්ථා තිබේ).
  • Notify microservice හරහා, යෙදවීමේ ප්‍රතිඵල පිළිබඳ දැනුම්දීමක් නිෂ්පාදනය වෙත යවනු ලැබේ.

12. වැරදි ක්ෂුද්‍ර සේවා හැසිරීමක් අනාවරණය වුවහොත්, නිෂ්පාදනයෙන් කාර්යයක් ආපසු හැරවීම ආරම්භ කිරීමට සංවර්ධකයින්ට මිනිත්තු 30ක් ඇත. මෙම කාලයෙන් පසු, කාර්යය ස්වයංක්රීයව ප්රධාන (Git microservice) වෙත ඒකාබද්ධ කරනු ලැබේ.

13. Master වෙත සාර්ථක ඒකාබද්ධ වීමෙන් පසුව, කාර්ය තත්ත්වය සංවෘත (Jira microservice) වෙත වෙනස් කරනු ඇත.

රූප සටහන සම්පූර්ණයෙන්ම සවිස්තරාත්මක බවක් මවාපාන්නේ නැත (යථාර්ථයේ දී ඊටත් වඩා පියවර තිබේ), නමුත් එය ක්‍රියාවලි වලට ඒකාබද්ධ වීමේ මට්ටම තක්සේරු කිරීමට ඔබට ඉඩ සලසයි. අපි මෙම යෝජනා ක්‍රමය පරමාදර්ශී ලෙස නොසලකන අතර ස්වයංක්‍රීයව මුදා හැරීමේ ක්‍රියාවලි සහ යෙදවීමේ සහාය වැඩිදියුණු කරමින් සිටිමු.

ඊළඟට කුමක්ද

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

නමුත් දැනට මෙතනින් නවතිමු. අපි ස්වයංක්‍රීය සමාලෝචනයේ බොහෝ මාතෘකා මතුපිටින් ආවරණය කළෙමු, සමහර ඒවා කිසිසේත් ස්පර්ශ කර නැත, එබැවින් ප්‍රශ්නවලට පිළිතුරු දීමට අපි සතුටු වන්නෙමු. විස්තරාත්මකව ආවරණය කළ යුතු දේ පිළිබඳ යෝජනා සඳහා අපි බලා සිටිමු, අදහස් දැක්වීමේදී ලියන්න.

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

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