Салам, Хабр! Буга чейин мен инфраструктурадагы жашоого код парадигмасы катары нааразы болуп, азыркы кырдаалды чечүү үчүн эч нерсе сунуштаган эмесмин. Бүгүн мен сизге кандай ыкмалар жана практикалар үмүтсүздүктүн туңгуюгунан кутулууга жана кырдаалды туура багытка бурууга жардам берерин айтып берүү үчүн кайтып келдим.
Мурунку макалада Мен бул тармак боюнча өзүмдүн таасирлерим менен бөлүшүп, бул чөйрөдөгү учурдагы кырдаалды чагылдырууга аракет кылдым, ал тургай бардык иштеп чыгуучуларга белгилүү болгон стандарттык практика жардам бере алат деп сунуштадым. Турмушка болгон нааразычылыктар көп болгон сыяктуу сезилиши мүмкүн, бирок азыркы кырдаалдан чыгуунун жолдору боюнча сунуштар болгон жок.
Биз кимбиз, кайдабыз жана кандай көйгөйлөрүбүз бар
Учурда биз алты программист жана үч инфраструктура инженеринен турган Sre Onboarding командасынын курамындабыз. Биз баарыбыз Инфраструктураны код (IaC) катары жазууга аракет кылып жатабыз. Биз муну жасайбыз, анткени биз кодду кантип жазууну билебиз жана "ортодон жогору" иштеп чыгуучулар болгон тарыхыбыз бар.
- Бизде бир катар артыкчылыктар бар: белгилүү бир фон, практикаларды билүү, код жазуу жөндөмү, жаңы нерселерди үйрөнүү каалоосу.
- Ал эми ийилген бөлүгү бар, бул дагы минус: инфраструктуралык жабдыктар жөнүндө билимдин жоктугу.
IaCда биз колдонгон технологиялык стек.
- ресурстарды түзүү үчүн Terraform.
- Сүрөттөрдү чогултуу үчүн пакер. Бул Windows, CentOS 7 сүрөттөрү.
- Jsonnet drone.io'до күчтүү курууну, ошондой эле пакер json жана терраформ модулдарын түзүү үчүн.
- Azure.
- Сүрөттөрдү даярдоодо Ansible.
- Көмөкчү кызматтар жана скрипттерди камсыздоо үчүн Python.
- Мунун баары VSCode ичинде команда мүчөлөрүнүн ортосунда бөлүшүлгөн плагиндер менен.
Менден корутунду мындай болду: Мен оптимизмди (биринчи кезекте өзүмө) жайылтууга аракет кылдым, бул тармакта болгон кыйынчылыктарды жана татаалдыктар менен күрөшүү үчүн бизге белгилүү болгон ыкмаларды жана тажрыйбаларды сынап көрөбүз деп айткым келди.
Учурда биз төмөнкү IaC маселелери менен күрөшүп жатабыз:
- Кодду иштеп чыгуу үчүн куралдардын жана каражаттардын жеткилең эместиги.
- Жай жайгаштыруу. Инфраструктура реалдуу дүйнөнүн бир бөлүгү жана ал жай болушу мүмкүн.
- Мамилелер жана практикалар жетишсиз.
- Биз жаңыбыз жана көп нерсени билбейбиз.
Экстремалдуу программалоо (XP) жардамга келет
Бардык иштеп чыгуучулар Extreme Programming (XP) жана анын артында турган практикаларды жакшы билишет. Көптөрүбүз бул ыкма менен иштедик жана ал ийгиликтүү болду. Анда эмне үчүн инфраструктуралык кыйынчылыктарды жеңүү үчүн анда айтылган принциптерди жана практикаларды колдонбойт? Биз бул ыкманы колдонуп, эмне болорун көрүүнү чечтик.
Сиздин тармакка XP мамилесин колдонуу мүмкүнчүлүгүн текшерүүБул жерде XP ылайыктуу чөйрөнүн сүрөттөлүшү жана анын бизге кандай тиешеси бар:
1. Динамикалык өзгөргөн программалык талаптар. Түпкү максат эмне экени бизге түшүнүктүү болду. Бирок майда-чүйдөсүнө чейин ар кандай болушу мүмкүн. Кайда такси керек экенин өзүбүз чечебиз, андыктан талаптар мезгил-мезгили менен өзгөрүп турат (негизинен өзүбүзчө). Эгерде автоматташтырууну өзү жүргүзгөн жана өзү талаптарды жана иштин көлөмүн чектеген SRE командасын алсак, анда бул пункт туура келет.
2. Жаңы технологияны колдонуу менен белгиленген мөөнөттөгү долбоорлордон келип чыккан тобокелдиктер. Бизге белгисиз нерселерди колдонууда тобокелдиктерге туш болушубуз мүмкүн. Жана бул 100% биздин жагдай. Биздин долбоордун баары биз толук билбеген технологияларды колдонуу болчу. Жалпысынан алганда, бул туруктуу көйгөй, анткени... Инфраструктура тармагында ар дайым пайда болгон көптөгөн жаңы технологиялар бар.
3,4. Чакан, чогуу жайгашкан кеңейтилген өнүктүрүү командасы. Сиз колдонуп жаткан автоматташтырылган технология бирдикти жана функционалдык сыноолорду жүргүзүүгө мүмкүндүк берет. Бул эки пункт бизге такыр туура келбейт. Биринчиден, биз координацияланган команда эмеспиз, экинчиден, биз тогуз адамбыз, бул чоң команда деп эсептесе болот. Бирок, "чоң" команданын кээ бир аныктамаларына ылайык, көп 14+ адам.
Келгиле, кээ бир XP тажрыйбаларын жана алардын пикирлердин ылдамдыгына жана сапатына кандай таасир тийгизерин карап көрөлү.
XP пикир байланышынын принциби
Менин түшүнүгүмдө пикир – бул суроого жооп, мен туура кылып жатамбы, биз ал жакка бара жатабызбы? XP бул үчүн кудайлык схемасы бар: убакыт кайтарым байланыш цикли. Кызыктуусу, биз канчалык төмөн болсок, ОСту керектүү суроолорго жооп берүү үчүн ошончолук тезирээк ала алабыз.
Бул талкуулоо үчүн абдан кызыктуу тема, биздин IT тармагында ОСти тез алууга болот. Долбоорду алты ай жасап, анан гана башында ката болгонун билүү канчалык азаптуу экенин элестетиңиз. Бул долбоорлоодо жана татаал системаларды курууда болот.
Биздин учурда IaC, пикир бизге жардам берет. Мен дароо жогорудагы диаграммага бир аз оңдоп берем: чыгаруу планында айлык цикл жок, бирок күнүнө бир нече жолу болот. Бул ОС циклине байланыштуу кээ бир практикалар бар, биз аларды кененирээк карап чыгабыз.
Маанилүү: пикир жогоруда айтылган бардык көйгөйлөрдүн чечими болушу мүмкүн. XP тажрыйбалары менен айкалышып, ал сизди үмүтсүздүктүн туңгуюгунан чыгара алат.
Өзүңүздү үмүтсүздүктүн туңгуюгунан кантип алып чыгуу керек: үч практика
тесттер
Тесттер XP кайтарым байланыш циклинде эки жолу айтылган. Бул жөн эле андай эмес. Алар бүт Extreme программалоо техникасы үчүн өтө маанилүү болуп саналат.
Сизде бирдик жана кабыл алуу тесттери бар деп болжолдонууда. Айрымдары сизге бир нече мүнөттүн ичинде, башкалары бир нече күндүн ичинде жооп кайтарышат, андыктан аларды жазууга көп убакыт талап кылынат жана азыраак каралат.
Классикалык тестирлөө пирамидасы бар, ал дагы тесттер болушу керек экенин көрсөтүп турат.
Бул алкак IaC долбоорунда бизге кандай колдонулат? Чынында... такыр эмес.
- Бирдик тесттери, алардын көп болушу керек экендигине карабастан, өтө көп болушу мүмкүн эмес. Же алар бир нерсени кыйыр түрдө сынап жатышат. Чынында биз аларды такыр жазбайбыз десек болот. Бирок бул жерде биз жасай алган тесттер үчүн бир нече колдонмолор бар:
- Jsonnet коду сыналууда. Бул, мисалы, биздин дронду чогултуу түтүгү, бул абдан татаал. Jsonnet коду тесттер менен жакшы камтылган.
Биз муну колдонобуз . - Ресурс башталганда аткарылуучу скрипттердин сыноолору. Скрипттер Python тилинде жазылган, ошондуктан аларга тесттерди жазууга болот.
- Jsonnet коду сыналууда. Бул, мисалы, биздин дронду чогултуу түтүгү, бул абдан татаал. Jsonnet коду тесттер менен жакшы камтылган.
- Сыноолордо конфигурацияны текшерүү мүмкүн, бирок биз андай кылбайбыз. Бул аркылуу ресурстун конфигурациясынын эрежелерин текшерүүнү конфигурациялоого болот . Бирок, ал жерде текшерүүлөр terraform үчүн өтө жөнөкөй, бирок көптөгөн сыноо скрипттери AWS үчүн жазылган. Жана биз Azure'добуз, андыктан бул дагы колдонулбайт.
- Компоненттик интеграция тесттери: бул сиз аларды кантип классификациялаганыңыздан жана аларды кайда койгонуңуздан көз каранды. Бирок алар негизинен иштешет.
Интеграция тесттери ушундай көрүнөт.
Бул Drone CIде сүрөттөрдү курууда мисал. Аларга жетүү үчүн Пакердин сүрөтү пайда болушу үчүн 30 мүнөт күтүш керек, андан кийин алар өтүп кеткенче дагы 15 мүнөт күтүш керек. Бирок алар бар!Сүрөттү текшерүү алгоритми
- Пакер алгач сүрөттү толугу менен даярдашы керек.
- Тесттин жанында биз бул сүрөттү жайылтуу үчүн колдоно турган жергиликтүү штаты бар терраформа бар.
- Ачып жатканда сүрөт менен иштөөнү жеңилдетүү үчүн жанында жайгашкан кичинекей модуль колдонулат.
- VM сүрөттөлүштөн орнотулгандан кийин, текшерүүлөр башталышы мүмкүн. Негизинен текшерүүлөр унаа менен жүргүзүлөт. Ал стартапта скрипттер кандай иштегенин жана демондор кандай иштегенин текшерет. Бул үчүн, ssh же winrm аркылуу биз жаңы көтөрүлгөн машинага кирип, конфигурациянын абалын же кызматтардын иштеп жатканын текшеребиз.
- Терраформ үчүн модулдардагы интеграциялык тесттер менен да абал окшош. Мына ушундай сыноолордун өзгөчөлүктөрүн түшүндүргөн кыска таблица.
Түтүк боюнча пикир 40 мүнөттүн тегерегинде. Баары абдан узак убакыт бою болот. Аны регрессия үчүн колдонсо болот, бирок жаңы өнүгүү үчүн бул жалпысынан реалдуу эмес. Эгер сиз буга абдан даяр болсоңуз, иштеп жаткан сценарийлерди даярдаңыз, анда аны 10 мүнөткө чейин кыскарта аласыз. Бирок бул дагы эле 5 секунданын ичинде 100 даана жасаган Unit тесттери эмес.
Сүрөттөрдү же терраформдык модулдарды чогултууда Unit тесттеринин жоктугу ишти REST аркылуу же Python скрипттерине иштетүүгө боло турган өзүнчө кызматтарга жылдырууга түрткү берет.
Мисалы, виртуалдык машина ишке киргенде, ал кызматта өзүн каттайт деп текшеришибиз керек болчу , жана виртуалдык машина жок кылынганда, ал өзүн жок кылды.
Бизде ScaleFT кызматы болгондуктан, аны менен API аркылуу иштөөгө аргасызбыз. Ал жерде «кирип, муну-муну өчүрүп сал» деп сүйрөп айта ала турган орам бар экен. Ал бардык керектүү орнотууларды жана мүмкүнчүлүктөрдү сактайт.
Бул үчүн биз кадимки тесттерди жаза алабыз, анткени ал кадимки программалык камсыздоодон эч кандай айырмасы жок: кандайдыр бир апиха шылдыңдашат, сиз аны тартыңыз жана эмне болорун көрүңүз.
Сыноолордун натыйжалары: OS бир мүнөттө бериши керек болгон тестирлөө аны бербейт. Ал эми пирамидадан жогору тестирлөөнүн түрлөрү эффективдүү, бирок көйгөйлөрдүн бир бөлүгүн гана камтыйт.
Жуп программалоо
Тесттер, албетте, жакшы. Алардын көбүн жазсаңыз болот, алар ар түрдүү болушу мүмкүн. Алар өз деңгээлинде иштеп, бизге пикирлерин айтышат. Бирок эң ылдам ОСти берген начар Unit тесттери менен көйгөй кала берүүдө. Ошол эле учурда, мен дагы эле оңой жана иштөө үчүн жагымдуу тез OS келет. Алынган чечимдин сапатын айтпай эле коёлу. Бактыга жараша, бирдик тесттерине караганда дагы тезирээк пикир бере турган ыкмалар бар. Бул жуп программалоо.
Кодду жазып жатканда, анын сапаты боюнча мүмкүн болушунча тезирээк пикир алгыңыз келет. Ооба, сиз баарын бир өзгөчөлүк бутагына жаза аласыз (эч кимге эч нерсени сындырбоо үчүн), Github'да тартуу өтүнүчүн жасап, аны пикири салмагы бар адамга дайындап, жооп күтө аласыз.
Бирок сиз көпкө күтө аласыз. Адамдардын баары бош эмес, жооп болсо да, эң жогорку сапатта болбошу мүмкүн. Жооп дароо келди дейли, рецензент ошол замат бүт идеяны түшүндү, бирок жооп баары бир фактыдан кийин кеч келет. Эртерээк болсо дейм. Бул жуп программалоо багытталган - ошол замат, жазуу учурунда.
Төмөндө жуп программалоо стилдери жана алардын IaCда иштөөдө колдонулушу:
1. Классикалык, Тажрыйбалуу+Тажрыйбалуу, таймер боюнча жылдыруу. Эки ролу - айдоочу жана навигатор. Эки киши. Алар бир эле коддун үстүндө иштешет жана белгилүү бир убакыттан кийин ролдорду алмаштырышат.
Келгиле, көйгөйлөрүбүздүн стилге шайкештигин карап көрөлү:
- Көйгөй: кодду иштеп чыгуу үчүн куралдардын жана инструменттердин жеткилең эместиги.
Терс таасири: өнүгүү үчүн көбүрөөк убакыт талап кылынат, биз жайлайбыз, иштин темпи/ритми жоголот.
Кантип күрөшөбүз: биз башка куралдарды, жалпы IDE колдонобуз, ошондой эле жарлыктарды үйрөнөбүз. - Көйгөй: жай жайылтуу.
Терс таасири: коддун жумушчу бөлүгүн түзүүгө кеткен убакытты көбөйтөт. Күтүп жатып зеригип калабыз, күткөндө дагы бир нерсе кылалы деп колубуз сунулган.
Кантип күрөшөбүз: биз аны жеңе алган жокпуз. - Маселе: ыкмалардын жана практикалардын жетишсиздиги.
Терс таасири: аны кантип жакшы жана кантип начар жасоо керектиги жөнүндө билим жок. Пикирлерди кабыл алууну узартат.
Биз кантип күрөшөбүз: өз ара пикир алмашуу жана жуптук практика дээрлик көйгөйдү чечет.
IaC бул стилди колдонуунун негизги көйгөйү - бул иштин бирдей эмес темпи. Салттуу программалык камсыздоону иштеп чыгууда сизде абдан бирдей кыймыл бар. Беш мүнөт бөлүп, N деп жазсаңыз болот. 10 мүнөт бөлүп, 2N, 15 мүнөт - 3N жазыңыз. Бул жерде сиз беш мүнөт өткөрүп, N деп жазып, анан дагы 30 мүнөт өткөрүп, Nдын ондон бир бөлүгүн жазсаңыз болот. Бул жерде сиз эч нерсе билбейсиз, тыгылып калдыңыз, келесоо. Тергөө убакытты талап кылат жана өзүн программалоодон алаксытат.
Жыйынтык: таза түрүндө ал бизге ылайыктуу эмес.
2. Пинг-понг. Бул ыкма бир адам тестти жазып, экинчиси ал үчүн ишке ашырууну камтыйт. Unit тесттеринде баары татаал экенин жана программалоого көп убакыт талап кылынган интеграциялык тестти жазууга туура келгендигин эске алсак, пинг-понгдун бардык жеңилдиктери жок болот.
Мен сыноо сценарийин иштеп чыгуу жана ал үчүн кодду ишке ашыруу үчүн жоопкерчиликти бөлүүгө аракет кылдык деп айта алам. Бир катышуучу сценарий менен келди, иштин бул бөлүгүндө ал жооптуу, акыркы сөздү айтты. Ал эми экинчиси ишке ашырууга жооптуу болгон. Бул жакшы чыкты. Бул ыкма менен сценарийдин сапаты жогорулайт.
Жыйынтык: тилекке каршы, иштин темпи IaCда жуп программалоо практикасы катары пинг-понгду колдонууга жол бербейт.
3.Strong Style. . Идея бир катышуучу директивалык навигатор болуп калат, ал эми экинчиси аткаруу айдоочунун ролун алат. Бул учурда чечим кабыл алуу укугу штурманга гана таандык. Айдоочу бир гана сөздү басып чыгарат жана эмне болуп жатканына таасир эте алат. Ролдор көпкө чейин өзгөрбөйт.
Окуу үчүн жакшы, бирок күчтүү жумшак көндүмдөрдү талап кылат. Мына ушундан тайып калдык. Техника кыйын болду. Анан бул инфраструктура жөнүндө да эмес.
Корутунду: аны колдонсо болот, биз аракеттен баш тартпайбыз.
4. Моббинг, сверминг жана бардык белгилүү, бирок тизмеде жок стилдер Биз аны эсептебейбиз, анткени Биз аны сынап көргөн жокпуз жана бул тууралуу биздин ишибиздин контекстинде айтуу мүмкүн эмес.
Жуптук программалоону колдонуу боюнча жалпы жыйынтыктар:
- Бизде иштин темпи бирдей эмес, бул баш аламандык.
- Биз жетишсиз жакшы жумшак көндүмдөрдү чуркап. Ал эми предметтик аймак биздин бул кемчиликтерди жоюуга жардам бербейт.
- Узак сыноолор жана куралдар менен көйгөйлөр жупташып иштеп чыгууну кыйындатат.
5. Буга карабастан ийгиликтер болду. Биз өзүбүздүн “Конвергенция – Дивергенция” ыкмасын ойлоп таптык. Мен анын кантип иштээрин кыскача айтып берем.
Бизде бир нече күнгө (бир жумадан аз) туруктуу өнөктөштөр бар. Бир тапшырманы чогуу аткарабыз. Бир аз отурабыз: бири жазат, экинчиси олтуруп колдоочу топту карап турат. Анан биз бир аз убакытка тарайбыз, ар кимибиз өз алдынча иштерди жасайбыз, анан кайра чогулуп, абдан тез синхрондобуз, чогуу бир нерсе жасап, кайра тарайбыз.
Пландоо жана байланыш
OS көйгөйлөрү чечилүүчү практикалардын акыркы блогу - бул тапшырмалардын өздөрү менен иштөөнү уюштуруу. Буга жуптук иштен тышкары тажрыйба алмашуу да кирет. Келгиле, үч практиканы карап көрөлү:
1. Максат дарагы аркылуу максаттар. Биз келечекке чексиз бара турган дарак аркылуу долбоордун жалпы башкаруусун уюштурдук. Техникалык жактан көз салуу Мирода жүргүзүлөт. Бир милдет бар - бул ортодогу максат. Андан же кичинекей максаттар же милдеттердин топтору чыгат. Милдеттердин өзүлөрү алардан чыгат. Бардык тапшырмалар ушул тактада түзүлөт жана сакталат.
Бул схема дагы бир күндө бир жолу митингдерде синхрондоштурууда пайда болгон пикирлерди берет. Ар бир адамдын алдында жалпы планга ээ болуу, бирок структуралаштырылган жана толугу менен ачык, бардыгына эмне болуп жатканын жана канчалык алга жылганыбызды билүүгө мүмкүндүк берет.
Милдеттерди визуалдык көрүүнүн артыкчылыктары:
- Себептүүлүк. Ар бир тапшырма кандайдыр бир глобалдуу максатка алып келет. Милдеттер кичинекей максаттарга топтоштурулган. Инфраструктуралык домендин өзү абдан техникалык. Мисалы, башка nginxке өтүү боюнча Runbook жазуу бизнеске кандай таасир этээри дайыма эле түшүнүктүү боло бербейт. Максаттуу картанын жанында болуу аны айкыныраак кылат.
Себептүүлүк көйгөйлөрдүн маанилүү касиети болуп саналат. Ал түз эле суроого жооп берет: "Мен туура кылып жатамбы?" - Параллелизм. Биз тогуз адамбыз жана бардыгын бир тапшырмага тапшыруу физикалык жактан мүмкүн эмес. Бир аймактагы тапшырмалар дайыма эле жетишсиз болушу мүмкүн. Биз чакан жумушчу топтордун ортосундагы ишти параллелдештирүүгө аргасыз болуп жатабыз. Ошол эле учурда, топтор өз тапшырмасы боюнча бир нече убакыт отурушат, аларды башка бирөө бекемдей алат. Кээде адамдар бул жумушчу топтун курамынан чыгып кетет. Кимдир бирөө эс алууга барат, бирөө DevOps конф. үчүн отчет берет, кимдир бирөө Habr боюнча макала жазат. Кандай максаттарды жана милдеттерди параллелдүү аткарууга болорун билүү абдан маанилүү болуп калат.
2. Эртең мененки жыйындардын алмаштыруучу алып баруучулары. Стенд-аптарда бизде мындай көйгөй бар - адамдар параллелдүү көптөгөн тапшырмаларды аткарышат. Кээде милдеттер эркин байланышта болуп, ким эмне кылып жатканын түшүнбөй калат. Ал эми дагы бир команда мүчөсүнүн пикири абдан маанилүү. Бул маселени чечүү курсун өзгөртө турган кошумча маалымат. Албетте, адатта жаныңызда бирөө бар, бирок кеңештер жана кеңештер ар дайым пайдалуу.
Бул абалды жакшыртуу үчүн биз "Алдынкы стендди өзгөртүү" ыкмасын колдондук. Эми алар белгилүү бир тизме боюнча ротацияланып, бул да өз таасирин тийгизүүдө. Сиздин кезегиңиз келгенде, жакшы Scrum жолугушуусун өткөрүү үчүн кирип, эмне болуп жатканын түшүнүүгө аргасыз болосуз.
3. Ички демо. Жуп программалоодон көйгөйдү чечүүгө жардам берүү, көйгөй дарагында визуализация жана эртең мененки скрам жолугушууларында жардам берүү жакшы, бирок идеалдуу эмес. Жубайлар катары сиз билимиңиз менен гана чектелесиз. Тапшырма дарагы ким эмне кылып жатканын дүйнөлүк деңгээлде түшүнүүгө жардам берет. Ал эми эртең мененки жыйында алып баруучу жана кесиптештер сиздин көйгөйлөрүңүзгө терең киришпейт. Алар, албетте, бир нерсени сагынышы мүмкүн.
Аткарылган иштерди бири-бирине көрсөтүп, анан талкуулоодон чечим табылды. Биз жумасына бир жолу бир саат чогулуп, өткөн жумада аткарган милдеттерибиздин чечимдеринин чоо-жайын көрсөтөбүз.
Көргөзмө учурунда тапшырманын майда-чүйдөсүнө чейин ачып, анын иштешин сөзсүз түрдө көрсөтүү зарыл.
Отчет текшерүү баракчасын колдонуу менен жүргүзүлүшү мүмкүн.1. Контекстке кириңиз. Тапшырма кайдан келди, ал эмне үчүн керек эле?
2. Мурда маселе кантип чечилген? Мисалы, чычканды массалык басуу талап кылынган же такыр эч нерсе кылуу мүмкүн эмес болчу.
3. Биз аны кантип жакшыртабыз. Мисалы: "Мына, азыр скриптосик бар, бул жерде Readme."
4. Анын кантип иштээрин көрсөт. Кээ бир колдонуучу сценарийин түздөн-түз ишке ашыруу сунушталат. Мен X келет, мен Y кылам, Y (же Z) көрөм. Мисалы, мен NGINXти жайылтып, url'ди түтөйм жана 200 OK алам. Эгер аракет узак болсо, аны кийинчерээк көрсөтүү үчүн алдын ала даярдаңыз. Ал морт болсо, демонстрацияга бир саат калганда аны бузбоо сунушталат.
5. Маселе канчалык ийгиликтүү чечилгенин, кандай кыйынчылыктар сакталып калганын, эмнеси бүтпөй жатканын, келечекте кандай жакшыртууга болорун түшүндүрүңүз. Мисалы, азыр CLI, андан кийин CIде толук автоматташтыруу болот.
Ар бир баяндамачы аны 5-10 мүнөткө чейин кармап туруу максатка ылайыктуу. Эгерде сиздин сөзүңүз маанилүү болсо жана көбүрөөк убакытты талап кылса, муну алдын ала sre-takeover каналында координациялаңыз.
Бетме-бет бөлүктөн кийин жипте дайыма талкуу болот. Бул жерде биздин милдеттерибиз боюнча керектүү пикир пайда болот.
Натыйжада болуп жаткан нерсенин пайдалуулугун аныктоо үчүн сурамжылоо жүргүзүлөт. Бул сөздүн маңызы жана тапшырманын маанилүүлүгү боюнча пикир.
Узун корутундулар жана андан ары эмне болот
Макаланын өңү бир аз пессимисттик сыяктуу сезилиши мүмкүн. Бул андай эмес. Пикирдин эки төмөнкү деңгээли, атап айтканда, тесттер жана жуп программалоо иштейт. Салттуу өнүгүүдөгүдөй кемчиликсиз эмес, бирок андан оң натыйжа бар.
Тесттер, алардын учурдагы түрүндө, жарым-жартылай гана код камтууну камсыз кылат. Көптөгөн конфигурация функциялары текшерилбей бүтөт. Кодду жазууда алардын иш жүзүндөгү ишке тийгизген таасири төмөн. Бирок, интеграциялык тесттердин таасири бар жана алар коркпостон рефакторингдерди жүргүзүүгө мүмкүндүк берет. Бул чоң жетишкендик. Ошондой эле, фокустун жогорку деңгээлдеги тилдерди өнүктүрүүгө жылышы менен (бизде питон бар, кет) көйгөй жок болот. Ал эми "клей" үчүн көп текшерүүнүн кереги жок, жалпы интеграциялык текшерүү жетиштүү.
Жупташып иштөө конкреттүү адамдарга көбүрөөк көз каранды. Бул жерде тапшырма фактору жана биздин жумшак көндүмдөр бар. Кээ бир адамдар менен бул абдан жакшы иштейт, башкалары менен начар иштейт. Мунун сөзсүз түрдө пайдалары бар. Жупташуу эрежелери жетиштуу сакталбаса да, тапшырмаларды биргелешип аткаруу фактысынын езу натыйжа-нын сапатына жакшы таасирин тийгизе тургандыгы тушунуктуу. Жеке мага жупта иштөө оңой жана жагымдуураак.
ОСке таасир этүүнүн жогорку деңгээлдеги жолдору - пландоо жана тапшырмалар менен иштөө так эффекттерди берет: жогорку сапаттагы билим алмашуу жана өнүктүрүүнүн сапатын жакшыртуу.
Кыска корутундулар бир сапта
- HR практиктери IaCда иштешет, бирок натыйжалуулугу азыраак.
- Иштей турган нерсени бекемдеңиз.
- Өзүңүздүн компенсациялык механизмиңизди жана практикаңызды ойлоп табыңыз.
Source: www.habr.com