devops tutorial ultimate guide devops
Ово је комплетна серија туторијала за ДевОпс од 25+ текстуалних и видео водича који покривају све аспекте ДевОпс-а попут Шта је ДевОпс, принципи ДевОпс-а и његов архитекта.
Списак лекција у ДевОпс Траининг Сериес:
# 1) Увод у ДевОпс (Овај водич)
#два) ДевОпс и тестирање софтвера
Водичи за ДевОпс ВИДЕО:
# 3) Видео лекција 1: Позадина, дефиниција, вредност, користи, навике и најбоље праксе ДевОпс-а
- 1. део, блок 1 - Демистификација ДевОпс-а
# 4) Видео туторијал 2: ДевОпс праксе засноване на агилним принципима, контроли извора и ДевОпс аутоматизацији
Овај видео водич је подељен на 6 блокова:
- Део 2, блок 1 - ДевОпс вежба заснована на агилном манифесту
- 2. део, блок 2 - Контрола извора и верзија у ДевОпс-у
- Део 2, блок 3 - Аутоматизација у ДевОпс-у
- Део 2, блок 4 - Мали кораци испорука у ДевОпс-у
- Део 2, блок 5 - Сарадња у ДевОпс тимовима
- Део 2, блок 6 - Како развити сарадњу у тимовима ДевОпс
# 5) Видео водич 3: ДевОпс обрађује континуирану интеграцију, континуирано тестирање и континуирану испоруку
Овај видео водич је подељен на 4 блока:
- Део 3, блок 1 - Непрекидна интеграција у ДевОпс
- Део 3, блок 2 - Континуирана испорука у ДевОпс-у
- Део 3, блок 3 - Континуирано постављање у ДевОпс
- Део 3, блок 4 - Континуирано тестирање у ДевОпс-у
# 6) Видео туторијал 4: ДевОпс управљање конфигурацијом и праћење перформанси апликација уживо
Овај видео водич је подељен на 3 блока:
- Део 4, блок 1 - Управљање конфигурацијом у пракси ДевОпс
- Део 4, блок 2 - Управљање издањима у ДевОпс-у
- Део 4, блок 3 - Надгледање перформанси апликација у ДевОпс-у
# 7) Видео туторијал 5: Кратак преглед целог курса.
- Део 5, блок 1 - Укратко о ДевОпс видео лекцијама
Водичи за текст:
# 8) Тестирање Схифт Лефт
# 9) Како побољшати квалитет софтвера помоћу континуиране интеграције
# 10) Континуирани процес испоруке
ДевОпс алати:
#Једанаест) ДевОпс Тоолс
# 12) Инсталација и конфигурација најчешће коришћених алата ДевОпс отвореног кода
# 13) Најбољи алати за континуирану интеграцију
# 14) Врхунски алати за континуирану испоруку
Водич за Мицрософт ВСТС:
# петнаест) Мицрософт ВСТС 1. део
# 16) Мицрософт ВСТС 2. део
АВС ДевОпс алати:
# 17) АВС ДевОпс алати, 1. део (ЦодеЦоммит)
# 18) АВС ДевОпс алати, 2. део (ЦодеБуилд)
# 19) АВС ДевОпс Тоолс 3. део (ЦодеДеплои)
#двадесет) Примена .НЕТ веб апликација помоћу АВС Еластиц Беансталк
Одговорно за ДевОпс:
#двадесет један) Одговорни део 1: Инсталација и конфигурација
# 22) Ансибле 2. део: Аутоматизација задатака помоћу Плаибоок-а
# 2. 3) Ансибле Парт 3: Ансибле Ролес анд Интегратион витх Јенкинс
# 24) Интеграција Јенкинса са селеном
# 25) Худсонов алат за континуирану интеграцију
# 26) ДевОпс компаније које пружају услуге
# 27) ДевОпс Интервју питања
Почнимо са првим упутством у овој серији.
Шта ћете научити:
- Увод у ДевОпс
- Преглед Агиле и ДевОпс
- Да ли је ДевОпс само о алаткама?
- Компоненте ДевОпс-а
- Резиме
- Препоручено читање
Увод у ДевОпс
ДевОпс се не односи само на алате, већ укључује и скуп најбољих пракси који омогућава премошћавање јаза између развојних и оперативних тимова у областима континуиране интеграције и примене коришћењем интегрисаног сета алата за аутоматизацију испоруке софтвера.
желим да будем испитивач производа
Неопходно је да програмери разумеју оперативну страну и обрнуто. Дакле, циљ ДевОпс-а је једноставно да помогне било којој организацији у брзини испоруке апликација крајњим корисницима и омогућавању бржих повратних информација крајњих корисника, што је потребно за било које пословање данас.
Преглед Агиле и ДевОпс
Не постоји разлика између Агиле и ДевОпс. Уместо тога, они се допуњују. Почнимо од гледања модела Ватерфалл где су сви захтеви замрзнути, а дизајн и развој се раде један за другим док не буде доступан стабилан производ.
Дакле, овде је проблем у томе што ако се у овој фази промени потреба купца, тада не постоји начин да се промењена потреба укључи и испуни.
Како би се питање прилагођавања потребама купаца решило боље него методом водопада, усвајање је било агилно. Идеја овде је била развити софтвер у мањим спринтима или понављању, рецимо око 2 до 3 недеље, што је помогло развојним тимовима да раде на повратним информацијама крајњег корисника и да уграде промене у новија издања.
Отуда развојни и оперативни тимови морају бити агилни у својим областима рада иДевОпсје рођен да омогући бољу сарадњу између њих.
Агиле доноси процесе као што су КСП, СЦРУМ итд., А ДевОпс доноси праксе као што су континуирана интеграција, континуирана испорука, континуирано тестирање и континуирано надгледање, што ћемо детаљно видети током даљег рада у овом упутству.
Да ли је ДевОпс само о алаткама?
На неки начин можете тврдити да су вам потребни алати за имплементацију ДевОпс-а. Тачно је, али алати су само акцелератори.
Али заправо, ради се о следећа 3 аспекта:
Људи :Веома је важно обучити и имати високо мотивисан тим људи који ће моћи ефикасно да комуницирају и сарађују кроз читаво ово путовање кроз културне промене.
Процес: Како говоримо о културним променама за примену ДевОпс-а, неопходно је имати праксе и стратегије које пружају вредност купцу. Исправан начин за то био би да се изврши процена зрелости АС-ИС, сагледају се празнине и предложи путоказ за спровођење давања одговарајућих препорука.
Нећу детаљно говорити о томе како сам радио ове процене, али биће ми драго да поделим све улоге о њима.
Алати: Коначно, реч је о коришћењу акцелератора аутоматизацијом процеса помоћу стандардних ДевОпс алата који су данас доступни. То може бити отворени извор (Јенкинс, Гит итд.), Комерцијални (Мицрософт ТФС, ВСТС, ИБМ Ратионал, Јира итд.) Или комбинација оба.
Компоненте ДевОпс-а
Надам се да сте до сада имали идеју шта је ДевОпс.
које су све адресе е-поште
Погледајмо сада следеће 4 компоненте ДевОпс-а које чине језгро са становишта имплементације, а такође су организације развиле добре оквире за аутоматизацију око истог нудећи их као услугу својим клијентима.
- Континуирано интеграција
- Континуирано тестирање
- Континуирана испорука
- Континуирано праћење
Искрено сам веровао да ако програмер мора да ради у овом режиму, треба да му се додели извршна ставка попут Задатак или Дефект (у Агиле-у то може бити део Усер Стори-а) која ће му омогућити да посао изврши у року од временски оквир спринта.
Дакле, чак и пре него што горе наведени кораци могу да се примене, ове задатке или недостатке програмера треба планирати у Спринту. Дакле, алати попут ЈИРА, ИБМ Ратионал Теам Цонцерт, Мицрософт ТФС / ВСТС итд. Помажу у стварању Агиле планова за издање / спринт.
Погледајмо сада сваку од ових компонената детаљно.
# 1) Континуирана интеграција
Као програмер, радите на задацима или недостацима који су додељени и пријављујете код у дељено спремиште више пута дневно. Слично томе, и остали чланови тима пријављују код у дељено спремиште.
Тада ћете заправо интегрисати сав посао који су обавили чланови тима у заједнички сервер за изградњу и извести аутоматизовану изградњу. Редовно обављање ових интеграција и аутоматизованих израда назива се континуирана интеграција.
Ова пракса помаже у откривању проблема врло рано, а такође осигурава да сви интегрисани модули раде по потреби. Дакле, ако се не придржавате овог приступа, интеграција рада тима може се догодити једном месечно, што може бити касно за проналажење и решавање проблема са интеграцијом.
Пример континуираног процеса интеграције:
# 2) Континуирана испорука
Континуирана испорука је следећи корак након континуиране интеграције. Циљ континуиране испоруке је што брже покретање апликације уграђене у производњу. Током овог процеса он пролази кроз различите фазе у животном циклусу испоруке, тј. КА, Стагинг, Производно окружење итд.
Овај поступак редовне испоруке апликација уграђених у различите фазе познат је као континуирана испорука.
Континуирана испорука помаже бржем изласку на тржиште у поређењу са традиционалним методама, смањује ризик, смањује трошкове подстицањем веће аутоматизације у процесу пуштања и што је најважније бржим повратним информацијама од крајњих корисника за производњу квалитетног производа.
Из свог искуства, видео сам да овај процес добро функционише за било коју врсту развоја веб апликација.
Такође сам урадио прилично процена на имплементацијама ДевОпс-а за организације у области полупроводника, али због њихових постојећих циклус ослобађања чини се да ово подручје Континуиране испоруке не одговара јер је то више водопадни процес који се прати и размештање се обавља према захтевима у окружењу купаца.
Пример континуиране испоруке:
На горњем дијаграму можете погледати различита расположива окружења, тако да ово обезбеђивање инфраструктуре за окружења такође може бити аутоматизовано током овог континуираног процеса испоруке.
# 3) Континуирано тестирање
Из горње 2 праксе сазнали смо да ЦИ и ЦД помажу у примени апликације или променама у продукцији. Читав овај процес укључује правилну валидацију кода и његову интеграцију са свим компонентама које су у њега укључене како би се осигурало да апликација ради како је предвиђено и без грешака или недостатака.
Дакле, континуирано тестирање је поступак извођења различитих врста аутоматизованих тестова почев од ЦИ процеса до тренутка када се апликација коначно примени у производњу.
Из претходног дијаграма можете видети да у кораку континуиране интеграције интегришемо све програмере у заједнички сервер за изградњу и такође би током ове фазе програмери извршили одређену количину јединичних тестова.
Једном када ове интеграције и тестови раде без икаквих грешака, тек тада се апликација или промене примењују у КА окружење након што се пријаве за ове капителе и одобрења.
У КА окружењу, функционални тестови се изводе и опет на основу одобрења биће распоређени у припремно окружење које би било на паритету као што су покренути производни системи и прихватни тестови. Једном када је ова активност завршена, апликација или се промене коначно уводе у производне системе.
Дакле, овде можемо приметити да континуирано тестирање као активност започиње од саме фазе ЦИ и веома је обавезан корак током континуираног процеса испоруке.
Ток узорковања тестирања у континуираном процесу испоруке:
# 4) Континуирано праћење
Како се апликација или промене примењују на производно окружење, оперативни тим ће настојати да надгледа апликацију и окружење са становишта побољшања, стабилности и доступности. Овај процес је познат као континуирано праћење.
Оперативни тимови ће имати свој софтвер за надгледање околине, али такође ће морати да одиграју своју улогу да надгледају примењене апликације за било какве проблеме. Да би ово постигли, морали би да раде са развојним тимовима како би створили одређене алате за анализу проблема са апликацијама.
Дакле, питања инфраструктуре, животне средине и апликација се све надгледају у процесу континуираног праћења.
Резиме
У овом упутству сазнали смо шта је тачно процес ДевОпс, укључујући различите компоненте које су у њега укључене. Ове компоненте помажу у убрзавању испоруке апликација и такође штеде време за тржиште, што је данас потреба пословања са конкурентне тачке гледишта.
У предстојећој серији водича у ДевОпс сегменту, погледаћете различите видео записе / вероватне ДевОпс алате које тимови могу да користе, као и примену ДевОпс-а користећи одређене алате за локалну употребу и облак.
И као што сам рекао и учинио, приметио сам да је ДевОпс имплементација узбудљива, на начин који гледа са организационих промена.
Наш предстојећи водич ће вам објаснити све о ДевОпс-у и тестирању софтвера.
Препоручено читање
- Дубински водичи за помрачење за почетнике
- Континуирана испорука у ДевОпс-у
- Континуирано постављање у ДевОпс
- Водич за тестирање ДевОпс-а: Како ће ДевОпс утицати на КА тестирање?
- Непрекидна интеграција у ДевОпс
- Континуирано тестирање у ДевОпс-у
- Укратко о ДевОпс видео лекцијама
- Водич за АВС ЦодеЦоммит за имплементацију ДевОпс-а у облаку