Много от вас може да са наясно с всички теории, свързани с . Но знаете ли как да приложите принципите на DevOps в реалния живот? В този блог ще обсъдя сценариите в реално време на DevOps, които ще ви помогнат да разберете накратко как работят нещата в реално време.
Указателите, които ще покрия в товаСтатия за сценарии в реално време на DevOpsса:
- Какво е DevOps?
- Проблеми, решени от DevOps
- CI (Непрекъсната интеграция) Сценарии
- CT (Непрекъснато тестване) Сценарии
- Сценарии на CD (непрекъсната доставка)
- Сценарии за данни на DevOps
Затова нека започнем с първата ни тема.
Какво е DevOps?
DevOps е подход за разработване на софтуер, който включва Непрекъснато развитие, Непрекъснато тестване, Непрекъснато интегриране, Непрекъснато внедряване и Непрекъснато наблюдение на софтуера през целия му жизнен цикъл на разработка. Тези дейности са възможни само в DevOps, а не в Agile или водопад. Ето защо Facebook и други водещи компании избраха DevOps като път напред към своите бизнес цели.DevOps се предпочита главно за разработване на висококачествен софтуер в по-кратки цикли на разработка, което води до по-голяма удовлетвореност на клиентите.
В следващия раздел на товаВ статията за сценарии в реално време на DevOps ще разгледаме различните проблеми, решени от DevOps.
Проблеми, решени от DevOps
1. Предоставяне на стойност на клиентите
- DevOps минимизира времето необходимо е да се достави стойност на клиентите. Времето на цикъла от завършването на разработчика на история / задача до производството значително намалява, което позволява стойността да бъде реализирана възможно най-бързо.
Най-важната стойност, реализирана чрез DevOps, е, че позволява на ИТ организациите съсредоточете се върху техните „основни“ бизнес дейности . Чрез премахване на ограниченията в рамките на потока на стойността и автоматизиране на конвейерите за внедряване, екипите могат да се съсредоточат върху дейностите. Това помага за създаването на стойност за клиента, а не просто за преместване на битове и байтове. Тези дейности увеличават устойчивото конкурентно предимство на дадена компания и създават по-добри бизнес резултати.
2. Намалено време на цикъла
Вътрешно DevOps е единственият начин да се постигне гъвкавост за предоставяне на защитен код с прозрения. Важно е да имате порти и добре изработен DevOps процес. Когато доставяте нова версия, тя може да работи рамо до рамо с текущата версия. Можете също така да сравните показатели, за да постигнете това, което сте искали, с показатели за приложение и производителност.
как да намеря тип данни в python
DevOps насочват екипите за разработка към непрекъснато подобрение и по-бързи цикли на освобождаване . Ако се направи добре, този итеративен процес позволява повече фокус във времето, върху нещата, които наистина имат значение. Като неща, които създават страхотен опит за потребителите - и по-малко време за управление на инструменти, процеси и технологии.
3. Време за пускане на пазара
Най-важният проблем, който се решава, е намаляване на сложността на процеса. Това допринася значително за нашия бизнес успех, като съкращава времето ни за пускане на пазара, предоставя ни бърза обратна връзка за характеристиките и ни прави по-отзивчиви към нуждите на нашите клиенти.
4. Разрешаване на проблеми
Най-голямата стойност на успешното внедряване на DevOps е по-голямата увереност в доставката, видимостта и проследимостта към случващото се, така че да можете да решавате проблемите по-бързо.
Друго важно предимство на DevOps е загубата на време. Привеждането в съответствие на хората и ресурсите на организацията позволява бързо внедряване и актуализиране. Това позволява на програмите DevOps да отстраняват проблеми, преди да се превърнат в бедствия.DevOps създава култура на прозрачност, която насърчава фокуса и сътрудничеството между екипите за разработка, операции и сигурност.
CI (Непрекъсната интеграция) вСценарии в реално време на DevOps
1. Хората могат да видят непрекъсната интеграция с обратен ефект
Членовете на екипа за разработка имат различни роли, отговорности и приоритети. Възможно е първият приоритет на продуктовия мениджър да е стартирането на нови функции, като мениджърът на проекти трябва да се увери, че екипът им спазва крайния срок. Програмистите може да си помислят, че ако спрат да поправят малка грешка всеки път, когато се появи, ще ги забави. Те може да почувстват, че поддържането на конструкцията чиста е допълнителна тежест за тях и няма да бъдат облагодетелствани от допълнителните си усилия. Това потенциално може да застраши процеса на адаптация.
За да преодолеете това:
Първо, уверете се, че целият ви екип е на борда, преди да приемете непрекъсната интеграция.
Техническите директори и ръководителите на екипи трябва да помогнат на членовете на екипа да разберат разходите и ползите от непрекъснатата интеграция.
Подчертайте кога и кога ще се възползват кодерите, като се посветите на различен метод на работа, който изисква малко повече отвореност и гъвкавост.
2. Интегриране на CI в съществуващия ви поток на развитие
Приемането на CI неизбежно идва с необходимостта от съществена промяна на някои части от работния процес на разработката ви. Възможно е разработчиците ви да не поправят работния процес, ако той не е повреден. Това е възможно главно ако вашият екип има по-голяма рутина при изпълнение на текущия си работен процес.
Ако искате да промените работния процес, трябва да го направите с големи предпазни мерки. В противен случай това може да компрометира производителността на разработчиците, а също и качеството на продукта. Без достатъчна подкрепа от ръководството, екипът за разработка може да е малко склонен да се заеме със задача с подобни рискове.
За да преодолеете това:
Трябва да сте сигурни, че давате достатъчно време на екипа си да разработи новия си работен процес. Това се прави, за да се избере гъвкаво решение за непрекъсната интеграция, което да поддържа новия им работен процес.
Също така, уверете се, че компанията е с гръб, дори ако в началото нещата не вървят много гладко.
3. Възстановяване на бившите навици за тестване
Непосредственият ефект от приемането на непрекъсната интеграция е, че вашият екип ще тества по-често. Така че за повече тестове ще са необходими повече тестови случаи, а писането на тестови случаи може да отнеме много време. Следователно разработчиците често трябва да разделят времето си между отстраняване на грешки и писане на тестови случаи.
Временно разработчиците може да успеят да спестят време чрез ръчно тестване, но в дългосрочен план може да навредят повече. Колкото повече отлагат писането на тестови казуси, толкова по-трудно ще стане да наваксат напредъка на разработката. В най-лошия случай вашият екип може да се върне към стария си процес на тестване.
За да преодолеете това:
какво е екземпляр на клас в java
Трябва да подчертаете, че писането на тестови казуси от самото начало може да спести много време за вашия екип и може да осигури високо покритие на теста на вашия продукт.
Освен това вградете идеята във вашата фирмена култура, че тестовите случаи са толкова ценни активи, колкото самата кодова база.
4. Разработчиците пренебрегват съобщенията за грешки
Често срещан проблем е, че когато по-големите екипи работят заедно, количеството известия за CI става огромно и разработчиците започват да ги игнорират и заглушават. Следователно е възможно те да пропуснат актуалните за тях актуализации.
Това може да доведе до етап, в който кодерите развиват относителна имунитет към счупени компилации и съобщения за грешки. Колкото по-дълго игнорират съответните известия, толкова по-дълго се развиват без обратна връзка в грешната посока. Това потенциално може да доведе до огромни откати, загуба на пари, ресурси и време.
За да преодолеете това:
Трябва да изпращате само критични актуализации.
Изпращайте известието само до съответните разработчици, които отговарят за поправянето му.
CT (Непрекъснато тестване) вСценарии в реално време на DevOps
Правилно получаване на спецификацията на изискванията
Ако постигнете правилно вашите изисквания, тогава е спечелена почти половината от битката. Така че, ако имате много конкретно и точно разбиране на изискванията, можете да проектирате по-добре планове за тестове и да покриете добре изискванията.
И все пак много екипи отделят много време и усилия, просто за изясняване на изискванията. Това е много често срещана клопка и за да се избегне това, екипите могат да възприемат базирани на модели тестове и техники за развитие, основани на поведение. Това помага да се проектират сценарии за тестове точно и адекватно.
Тези практики определено ще помогнат за по-бързото отстраняване на пропуските. Също така, това им позволява да генерират повече тестови случаи автоматично още от ранните етапи на спринт.
Оркестрация на тръбопроводи
Предимствата на непрекъснатото тестване и непрекъсната доставка са тясно свързани с оркестрацията на тръбопроводи. Това директно означава разбиране как работи, защо работи, как да се анализират резултатите и как и кога да се мащабира. Всичко зависи от тръбопровода и следователно трябва да интегрирате тръбопровода с комплекта за автоматизация.
Причината, поради която екипите се бъркат, е, че нито едно решение не предоставя пълната верига от инструменти, необходима за изграждането на CD тръбопровод.
Екипите обикновено трябва да търсят подходящите за тях части от пъзела. Няма перфектни инструменти, обикновено само най-добрите инструменти от породата, които осигуряват интеграция заедно с множество други инструменти. И разбира се, API, който позволява и лесна интеграция.
Накратко, невъзможно е да се приложат непрекъснати тестове без скоростта и надеждността на стандартизиран и автоматизиран тръбопровод.
Мащабиране и управление на сложността
Друг важен сценарий е, че непрекъснатите тестове стават по-сложни, докато се придвижват към производствената среда. Тестовете нарастват както в брой, така и в сложност, като кодът за узряване и околната среда стават все по-сложни.
Трябва да актуализирате тестове всеки път, когато актуализирате различни фази и автоматизирани скриптове. В резултат на това общото време, необходимо за провеждане на тестовете, също се увеличава към пускането.
Решението за това се крие в подобрената тестова оркестрация, която осигурява точния обем на тестовото покритие за по-кратки цикли на спринта и дава възможност на екипите да изпълняват уверено. В идеалния случай целият процес трябва да бъде автоматизиран с CT, извършен на различни етапи. Това се прави чрез използване на порти на политики и ръчна намеса, докато кодът бъде изтласкан към производството.
Създаване на цикли за обратна връзка
Без чести цикли на обратна връзка на всеки етап от цикъла на разработка, не е възможно непрекъснато тестване. Това отчасти е причината, поради която CT е трудно да се приложи. Не се нуждаете само от автоматизирани тестове, но също така се нуждаете от видимост на резултатите от теста и изпълнението.
Традиционните контури за обратна връзка като инструменти за регистриране, кодови профили и инструменти за мониторинг на производителността вече не са ефективни. Нито работят заедно, нито осигуряват дълбочината на прозрение, необходима за отстраняване на проблеми. Таблата за управление в реално време, които автоматично генерират отчети и действаща обратна връзка в целия SDLC, помагат за по-бързото пускане на софтуера в производство с по-малки дефекти. Достъпът в реално време до таблата и достъпът за всички членове на екипа помага на механизма за непрекъсната обратна връзка.
Липса на среда
Непрекъснатото тестване просто означава тестване по-често и това изисква по-често да се засягат множество среди. Това представлява пречка, ако споменатите среди не са налични в момента, в който са необходими. Някои среди са достъпни чрез API, а други чрез различни интерфейси. Някои от тези среди могат да бъдат изградени с помощта на модерна архитектура, докато други с монолитни наследени клиент / сървър или мейнфрейм системи.
Но въпросът тук е как координирате тестването чрез различните собственици на околната среда? Възможно е също така те да не винаги поддържат средата работеща. Отговорът на всичко това е Виртуализация . Чрез виртуализиране на средата можете да тествате кода, без да се притеснявате твърде много за областите, които са непроменени.Предоставянето на средите достъпни и достъпни при поискване чрез виртуализация със сигурност помага да се премахне значително препятствие от вашия тръбопровод.
CD (непрекъсната доставка) вСценарии в реално време на DevOps
Внедряванията отнемат твърде много време
Разпределените приложения обикновено изискват повече от „копиране и поставяне“ на файлове на сървър. Сложността има тенденция да се увеличава, ако имате ферма от сървъри. Несигурността относно това какво да се разположи, къде и как е съвсем нормално нещо. Резултатът? Дълги периоди на изчакване, за да вкараме нашите артефакти в следващата среда по маршрута, за да забавим всичко, тестване, време за живот и т.н.
Какво предлага DevOps на масата? Екипите за разработка и ИТ операции определят процеса на внедряване в безупречна сесия за сътрудничество. Първо те проверяват какво работи и след това го извеждат на следващото ниво с автоматизация, за да улеснят непрекъснатата доставка. Това драстично намалява времето за разполагане, а също така проправя пътя за по-чести разполагания.
Липсващи артефакти, скриптове и други зависимости
Често срещаме неуспехи след внедряването на нова версия на работещ софтуер. Това често се причинява от липсата на библиотеки или скриптове на бази данни, които не се актуализират. Това обикновено се причинява от липсата на яснота кои зависимости да се разположат и тяхното местоположение. Насърчаването на сътрудничество между разработката и операциите може да помогне за решаването на този вид проблеми в повечето случаи.
Що се отнася до автоматизацията, можете да дефинирате зависимости, което помага много за ускоряване на внедряванията. Инструменти за управление на конфигурация като Куклен или Главен допринасят с допълнително ниво на дефиниция на зависимости. Можем да дефинираме не само зависимости в нашето приложение, но и на ниво инфраструктура и конфигурация на сървъра. Например можем да създадем виртуална машина за тест и да инсталираме / конфигурираме tomcat преди да бъдат публикувани нашите артефакти.
Неефективно наблюдение на производството
Понякога конфигурирате инструментите за мониторинг по начин, който създава много неподходящи данни от производството, но в други случаи те не дават достатъчно или изобщо нищо. Няма определение за какво трябва да се грижите и какви са показателите.
Трябва да се съгласите какво да наблюдавате и коя информация да издавате и след това да въведете контрол на място. Инструментите за управление на производителността на приложенията са чудесна помощ, ако вашата организация може да си позволи да разгледа AppDynamics, New Relic и AWS X-Ray.
Сценарии за данни на DevOps
DevOps има за цел да премахне рисковете, свързани с разработването на нов софтуер: Анализът на данните идентифицира тези рискове. За непрекъснато измерване и подобряване на процеса на DevOps, анализът трябва да обхваща целия конвейер. Това предоставя безценна информация за управлението на всички етапи от жизнения цикъл на разработката на софтуер.
1. По-малко време за анализ на данни
С всички данни, които се генерират по всяко време, организациите трябва да приемат, че не могат да анализират всичко. Просто няма достатъчно време през деня - и за съжаление, роботите все още не са достатъчно сложни, за да направят всичко за нас.
е a и има връзка в Java
Поради тази причина е важно да се определи кои набори от данни са най-значими. В повечето случаи това ще бъде различно за всяка организация. Затова преди да се потопите, определете ключови бизнес цели и цели. Обикновено тези цели се въртят около нуждите на клиентите - най-вече най-ценните функции, които са най-важни за крайните потребители. Например за търговец на дребно в горната част на списъка е анализът как трафикът взаимодейства със страницата за плащане на сайта и тестването на това как работи в задната част.
Някои бързи съвети за идентифициране на кои данни е най-важно да се анализират:
Направете диаграма: Определете въздействието на прекъсванията върху вашия бизнес, задавайки въпроси като „Ако X прекъсва , какъв ефект ще има върху други функции? '
Погледнете историческите данни: Определете къде са възникнали проблеми в миналото и продължете да анализирате данни от тестове и да изграждате, за да сте сигурни, че това няма да се повтори.
2. Трудна комуникация
Днес повечето организации все още работят с различни екипи и персони, които идентифицират собствените си цели и използват свои собствени инструменти и технологии. Всеки екип действа независимо, изключен от тръбопровода и се среща с други екипи само по време на фазата на интеграция.
Когато става въпрос за разглеждане на по-общата картина и идентифициране на това, което работи и не работи, организацията се бори да намери едно решение. Това е така, защото най-вече защото всички не успяват да споделят общите данни, което прави анализа невъзможен.
За да преодолеете този проблем, преработете потока от комуникация, за да сте сигурни, че всички си сътрудничат по време на SDLC, а не само по време на процеса на интеграция.
Първо, уверете се, че има силна синхронизация на показателите на DevOps от самото начало. Напредъкът на всеки екип трябва да се показва в едно единствено табло, като се използват едни и същи ключови показатели за ефективност (KPI), за да се даде видимост на управлението в целия процес. Това се прави, за да могат те да съберат всички необходими данни, за да анализират какво се е объркало (или какво е успяло).
Извън първоначалния метричен разговор трябва да има постоянна комуникация чрез екипни срещи или цифрови канали като Slack.
3. Липса на работна ръка
Когато разполагаме с кратък персонал, се нуждаем от по-интелигентни инструменти, които използват дълбоко обучение, за да поставят данните, които събираме, и да вземем решения бързо. В крайна сметка никой няма време да разгледа всяко едно изпълнение на теста (а за някои големи организации може да има около 75 000 за даден ден). Номерът е да премахнете шума и да намерите правилните неща, върху които да се съсредоточите.
Тук изкуственият интелект и машинното обучение могат да помогнат. Много инструменти на пазара днес използват AI и ML, за да правят неща като:
Разработвайте скриптове и тестове за преместване и валидиране на различни части от данни
Докладвайте за качеството въз основа на по-рано научено поведение
Работете в отговор на промените в реално време.
Така че с това стигнахме до края на тази статия за сценариите в реално време на DevOps.
След като разбрахте какво представляват сценариите в реално време на DevOps, вижте това от Edureka, доверена компания за онлайн обучение с мрежа от над 250 000 доволни учащи, разпространени по целия свят. Курсът за обучение за сертифициране Edureka DevOps помага на обучаващите се да разберат какво е DevOps и да придобият опит в различни процеси и инструменти на DevOps като Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack и GIT за автоматизиране на множество стъпки в SDLC.
Имате въпрос към нас? Моля, споменете го в раздела за коментари на товаСтатия за сценарии в реално време на DevOpsи ние ще се свържем с вас.