Скалирање и оптимизација ЦИ/ЦД

Имплементација ЦИ/ЦД тока посла за развој апликација постаје све популарнија. Међутим, у исто време, скалирање и оптимизација ЦИ/ЦД-а представља изазов.

Данас ћемо разговарати о томе шта је овај изазов и истражити тачно како можемо да скалирамо и оптимизујемо ЦИ/ЦД. Дакле, пратите!

Данас се развој апликација обично обавља у тимовима који се састоје од неколико програмера. Свака особа или тим има своју улогу у пројекту напредујући у свом посвећеном делу.

Затим се налазимо на крају пројекта са неколико делова кода за компајлирање. У зависности од свачијих метода рада, много времена се може изгубити на управљање овом интеграцијом.

ЦИ/ЦД, континуална интеграција и континуална испорука/примјена је рјешење за овај проблем и осигурава да се ажурирања објављују без непотребних одлагања и сукоба. Хајде да разумемо овај процес.

Континуирано интеграција

ЦИ или Цонтинуоус Интегратион групишу процесе који имају за циљ континуирано објављивање промена кода и додатака у заједничкој грани пројекта. Омогућава тестирање кода и вршење побољшања и промена у реалном времену. Циљ је тестирати сваки елемент кроз креирање тестова.

Ова трајна мера омогућава да се не проверава све у једном блоку на крају и да се избегне рад на превише елемената истовремено. Извођење јединичних тестова је, стога, веома корисно да се то осигура. Дакле, лакше је открити грешке тако што ћете осигурати да се код добро компајлира и да не ствара регресије.

Континуирана испорука

Континуирана испорука или ЦД обједињује континуирану интеграцију и тестирање које се може упаковати у контејнере и ставити у производњу. То јест, прикупља ове кодове и обављена тестирања и ставља их у производњу путем аутоматизације.

Чак и ако захтева људску акцију, постаје аутоматизован стављањем свега што је урађено „у етар“ на интегрисан и потпун начин. Конкретно, уз континуирану дистрибуцију, наша апликација је развијена тако да се може пустити у производњу, без обзира када.

  Како убити процес у Линуку

Цонтинуоус Деплоимент

Иако су концепти континуиране испоруке и континуиране имплементације слични, постоје разлике. Ако им је циљ исти, односно увођење апликације у производњу, средства за постизање истог се разликују. Оно што одваја континуирану испоруку од континуиране имплементације је ослобађање.

Заиста, континуирана примена омогућава директну примену сваке модификације која прелази различите фазе нашег цевовода. Док је у континуираној испоруци, корак људске валидације је неопходан да би се имплементација одвијала.

Скалирање ЦИ/ЦД

Када се број микроуслуга повећа, постаје скоро неизбежно скалирати свој ЦИ/ЦД. Повећани број микросервиса резултира различитим цевоводима повезаним са једним гит репозиторијумом што повећава оптерећење ЦИ сервера и смањује перформансе.

Да бисте скалирали ЦИ/ЦД, неопходно је креирати стандардизовани и аутоматизовани развојни цевовод за све тимове и, одатле, осигурати квалитет појединачних испорука програмера и тимских испорука. Такође олакшава управљање цевоводом.

Скалирање се може постићи дефинисањем ЦИ процеса за извршавање јединичних тестова и валидацијом квалитета испорученог кода.

Следи ЦД процес за прављење слика и њихово постављање у окружења у континуитету и коначно дефинисање процеса за прављење слика и њихово примену у производном окружењу.

Кораци за скалирање ЦИ/ЦД

Први корак је да се цевовод усклади са архитектима, укључујући вође тимова. Она прати мапирање Гит грана у окружења (развој -> развој и мастер -> [homologation and production]). Затим долази до покретања ЦИ задатка при сваком захтеву за повлачење и ЦД задатка при свакој промени у мапираним гранама.

Може се креирати ток послова за ЦИ и ЦД који ће се пратити.

Ток послова ЦИ се развија у 7 корака:

  • Погледајте изворну и одредишну грану Захтева за повлачење;
  • Проверава да ли спајање нема конфликте који захтевају ручно решавање;
  • Покрените тестове јединица;
  • Направите пакет да бисте проверили интегритет и да је код компајлиран;
  • Активирајте проверу квалитета кода;
  • Повећајте и урезујте верзију пројекта у изворну грану;
  • Обавестите Гит спремиште захтева за повлачењем о успеху или неуспеху преко Вебхоок или Рест АПИ позива (Гит Репозиторијум).

Ток ЦД посла прати следећу путању:

  • Обавештена филијала је одјављена.
  • Артефакт је направљен коришћењем специфичног алата за изградњу пројекта на коме се ради.
  • Након што артефакт дође, библиотечки пројекти се шаљу у Некус за складиштење артефакта и ток је завршен.
  Како заштитити датотеке шифроване БитЛоцкер-ом од нападача

Спроводе се следеће радње:

Корак 1: Доцкер слика се креира за генерисани артефакт, примењујући верзију артефакта на Доцкер слику.

Корак 2: Слика се отпрема у Доцкер регистар.

Корак 3: Примена кроз представљање слике преко Кубернетеса.

За апликационе пројекте који су у окружењу за одобрење/производњу, следите кораке 1 и 2 изнад, а затим следеће:

  • Примените путем увођења слике преко Кубернетеса у окружењу за одобравање;
  • Посао узима паузу да сачека да се увођење одобри за производњу;
  • Ако се одобри, слика која се одобрава се промовише за производњу;
  • У супротном, враћа слику у одобрење.

ЦИ/ЦД оптимизација

ЦИ/ЦД побољшава развојни циклус апликације и решава проблем настао интеграцијом новог кода и повећањем учесталости испоруке.

Следи како можете даље да оптимизујете употребу ЦИ/ЦД-а:

Дајте приоритет поправљању оштећене верзије

Када се градња поквари, поправљање би требало да буде приоритет тима. Ако се верзија не може поправити за неколико минута, тим мора одлучити да ли ће уклонити код или онемогућити ознаку функције.

Идеја која стоји иза поправљања покварене верзије је да ће она увек производити радни код који може бити пуштен.

Мала честа распоређивања

Генерално, стабилност апликације је угрожена кад год дође до примене. Стога имамо тенденцију да удаљимо распоређивање једно од другог. Проблем овог приступа је што акумулирамо превише промена. Једна од ових промена би могла да пође по злу, приморавајући нас да вратимо остале које су радиле.

Примените образац давитеља и разбијте компликоване промене на мале и једноставне. Ако примењујете чешће и радите у малим серијама, ризик од примене је мањи.

Аутоматизирајте КА тестове за смањење ризика

Вероватно смо сви били укључени у сценарио „радио на мојој локалној машини“ јер се локална развојна окружења често разликују. Може постојати много различитих ствари између вашег локалног окружења и места у ком идете у производњу. Можете да оптимизујете ЦИ/ЦД тако што ћете аутоматизовати задатке обезбеђења квалитета (КА), као што је тестирање претраживача, смањујући ризик да грешка дође до активне апликације.

Верујте аутоматизованим тестовима

Да би потврдио када програмер интегрише нови код, ЦИ се ослања на аутоматизован и поуздан тест пакет. Ако треба да преведете код, први тест је да се компајлира. Затим можете додати онолико тестова колико сматрате критичним.

  Копирајте путању и име датотеке и фасцикле из контекстног менија датотеке

Колико тестова треба укључити? Да бисте то утврдили, запамтите да је циљ ЦИ-а да пружи повратне информације што је брже могуће. Ако програмер мора да чека сат времена да добије повратне информације, то неће радити. Увек ће вам недостајати ствари, али када уочите грешку у производњи, направите тест случај и укључите га у ЦИ петљу.

Увек водите рачуна о безбедности

Размислите о безбедности ЦИ/ЦД алата док се интегрише у постојеће конфигурације или окружења. ЦИ/ЦД захтева да се сви алати за тестирање безбедности позивају програмски и да се њихови резултати агрегирају на једном месту. Потражите алате који имају АПИ-је за аутоматске ревизије шифровања.

Предности скалирања и оптимизације ЦИ/ЦД-а

Осим повећања ефикасности развојних тимова, скалирање и оптимизација ЦИ/ЦД-а имају и друге предности, од којих су неке:

Смањене режије

Сати развоја се обично наплаћују, али шта је са временом утрошеним на ручно постављање кода или датотека? Аутоматизација великих делова вашег тока ће уштедети време за рад који се наплаћује, што свако може да цени. Аутоматско тестирање вам такође омогућава да раније не успете, уместо да пронађете грешке у КА или производњи или још горе, клијент их пронађе. Више грешака поправљених за исто време је чиста победа.

Испорука са мање грешака и мање ризика

Багове хватате много раније у процесу развоја тако што чешће објављујете мање промене. Када имплементирате аутоматизоване тестове у свим фазама развоја, не ризикујете да померите неисправан код на следећу фазу и лакше је вратити мање промене када је то потребно.

Брже одговорите на тржишне услове

Услови на тржишту се стално мењају. Претпоставимо да откријете да нови производ губи приход или да више купаца приступа вашој веб локацији са паметних телефона него са лаптопа. У том случају, много је лакше направити брзу промену ако сте оптимизовали континуирану испоруку.

Самопоуздање

Ако сте оптимизовали ЦИ/ЦД, што значи да имате робустан тестни пакет, ваше самопоуздање да нећете послати грешку увелико расте. Ако сте транспарентни са својим процесом и образујете остатак свог тима и клијенте, повећава се и њихово поверење у вас као развојни тим.

Завршне речи

ЦИ/ЦД чини ваше интеграције и испоруке бржима. Међутим, важно је повећати и оптимизовати га како би се избегло да процес постане контрапродуктиван због све веће сложености.

Такође можете погледати неке од најбољих ЦИ алата.