8 ключавых задач у прыняцці DevOps: Частка 2 - Рашэнні

У першай частцы гэтага блога з дзвюх частак я разгледзеў 8 асноўных праблем, з якімі я сутыкаюся арганізацый, калі яны прымаюць DevOps. Зараз давайце разгледзім некаторыя рашэнні.

Змяненне складаней за ўсё ў пачатку, самае цяжкае ў сярэдзіне і найлепшае ў канцы. - Робін Шарм

1.Магчымасць функцыянавання культуры ў адпаведнасці з прынцыпамі DevOps

Кіраўнікам DevOps і агентам змен трэба будзе шукаць спосабы пастаяннага навучання камандам і людзям у арганізацыі пра тое, як выглядае культура DevOps і чаму яна паскарае каштоўнасць. Вось некаторыя рэчы, якія я паспрабаваў, якія спрацавалі:

Навучанне і супольнасці практыкі

Персанал DevOps можа арганізаваць унутраныя трэнінгі альбо прэзентацыйныя прэзентацыі для прыняцця DevOps і азнаёміцца ​​з культурай DevOps. Такім чынам яны могуць прасоўваць і сустракацца тварам да твару з усімі ў арганізацыі. Перавага ў асабістым кабінеце аддаецца перавагу выкарыстанню электроннай пошты ці відэаканферэнцый, паколькі людзі хутчэй дабудоўваюць давер, таму рэкамендуецца праводзіць шоў-шоў, калі каманды будуць рассеяны, накіраваныя на тое, каб сустрэць усіх, па меншай меры, для таго, каб наладзіць адносіны.

DevOps База ведаў і FAQ

Каманды DevOps могуць ствараць базу ведаў або часта задаюць пытанні (FAQ) і дзяліцца з усімі людзьмі ўнутры арганізацыі, таму ўсе ведаюць, дзе атрымаць інфармацыю пра сувязь з DevOps там, дзе яна патрэбная. Бачнасць і лёгкі доступ да інфармацыі, што падахвочвае іх шукаць і чытаць самастойна і нават садзейнічаць. Такая інфармацыя можа захоўвацца на сумесных платформах, такіх як Atlassian Confluence або Microsoft Teams.

Прымяненне практыкі арганізацыі культуры Westrum

Мы можам выкарыстоўваць культурную практыку арганізацыі Westrum для стварэння генератыўнай культуры, якая культывуе паток дадзеных і даверу, разглядаючы шэсць частак мадэлі іерархічнай культуры Westrum, канцэнтруючыся на тых практыках, якія можна знайсці ў генерацыйнай культуры;

Тут можна пабудаваць генеральную культуру;

2.Адресацыя супраціву да пераменаў

Кіраўнікі павінны разлічваць, што людзі будуць супрацьстаяць зменам. Па словах DevOpsologist, Філіпа Хейл, у сваім артыкуле пра інструменты адлюстравання зацікаўленых бакоў і яна абмяркоўвала, як мы можам адрасаваць настроі і эмоцыі пэўных груп людзей да змен, тады мы можам ужыць розныя стратэгіі ўзаемадзеяння, каб наблізіць іх да ініцыятыў DevOps. Ёсць 6 "профіляў паводзін" і як мы можам з імі ўзаемадзейнічаць, як паказана ніжэй;

Не заняты

Гледачоў

Цынікі

Крытыкі

Энтузіясты

Адвакатаў (чэмпіёны / эксперты)

Падводзячы вынік на аснове вышэйсказанага, мы бачым, што ўсе падыходы ўзаемадзеяння ўключаюць зносіны і быць у курсе пра прыняцце DevOps. Мы павінны больш цесна супрацоўнічаць з усімі групамі, быць іх бачнымі і аказваць дапамогу, калі яны ім патрэбныя.

3. Прывядзенне яснасці ў DevOps Vision

Увядзенне ў сістэму CALMS DevOps можа дапамагчы вызначыць дарожную карту і мэты DevOps. CALMS - гэта канцэптуальная аснова для інтэграцыі распрацовак і аперацый (DevOps), функцый і сістэм у рамках арганізацыі.

Кіраўнікам DevOps неабходна распрацаваць дакладную дарожную карту па развіцці DevOps з выразнымі этапамі паляпшэння. Яны павінны падзяліцца ім і зрабіць яго бачным усім у арганізацыі;

4.Стварэнне сумеснай працы

Каманды па распрацоўцы і ІТ-рабоце павінны навучыцца супрацоўнічаць. Гэта можа азначаць стварэнне шматфункцыянальных каманд, уключаючы Dev і Ops, але гэта не працуе ў многіх арганізацыях. Часта бывае занадта драматычным арганізацыйным зменам, альбо людзей проста не хапае. Налады традыцыйных тэхналагічных аддзелаў таксама ўключаюць у сябе глыбокую экспертызу прадметаў ІТ-аперацый, звязаных з бяспекай і сеткамі, напрыклад, таму цяжка зразумець, як дзяліцца гэтым тыпам людзей з камандамі распрацоўкі ці прадуктаў.

Што дапамагае, калі рэгулярна сустракаюцца каманды па распрацоўцы і ІТ-аперацыях? Калі каманды распрацоўшчыкаў праводзяць штодзённыя разборкі ў рамках іх спрытнай практыкі, запрашэнне ІТ-аперацый да ўдзелу можа дапамагчы ў ліквідацыі перашкод. Запрашэнне іх у планаванне спрынту можа гарантаваць, што тыя нефункцыянальныя патрабаванні ўлічваюцца ў спрынце, што ўпарадкуе працэс дастаўкі значэння.

Інструменты для камунікацыі паміж камандамі, такія як Slack або Microsoft Team, сапраўды дапамагаюць тут, робячы магчымай бесперапыннасць супрацоўніцтва. Група чату альбо апавяшчэнне / апавяшчэнне таксама павінна быць належным чынам кіравана, каб праблемы можна было накіраваць у патрэбную каманду і хутка перарасці, выкарыстоўваючы правільныя дзеянні для вырашэння праблемы / памылкі.

Вось некалькі інструментаў для супрацоўніцтва, якія вы можаце выкарыстоўваць і пачаць супрацоўнічаць у вашай арганізацыі;

5.Стандартызацыя асяроддзя

Навакольнае асяроддзе - гэта сукупнасць рэсурсаў альбо мэтавых месцаў, якія трэба пераўтварыць з кода ў рэальны прадукт праз канвеер. Навакольнае асяроддзе можа ўключаць у сябе віртуальныя машыны (VM), серверы баз дадзеных, паслугі іншых вытворцаў і інш. Ніжэй прыводзіцца прыклад этапаў навакольнага асяроддзя з яго выкарыстаннем, карыстальнікам / персаналізаваным чалавекам і адказным за падтрыманне навакольнага асяроддзя;

Да пераваг добра вызначанай асяроддзя можна аднесці наступнае;

  1. Запіс / гісторыя разгортвання - усе дэталі запуску трубаправода запісваюцца ў інструменты CI / CD для сваіх рэсурсаў.
  2. Прасочванасць - гэта дазваляе адсочваць, ці змянілася змяненне кода (здзейсніць) альбо функцыя / выпраўленне памылак (працоўныя элементы).
  3. Дазвол / кантроль - бяспечная серада, указваючы, якому карыстачу дазволена і якое мэтавае асяроддзе разгарнуць.

Забеспячэнне асяроддзя аўтаматызацыі - галоўны фактар ​​поспеху ў бесперапынным працэсе пастаўкі. Ці можа каманда Dev запытаць новае асяроддзе спецыяльна і ці прадугледжана ваша асяроддзе па патрабаванні пры разгортванні прыкладання? Асяроддзе прыкладання можна падзяліць на 3 асноўныя вобласці:

1. Інфраструктура

2. Канфігурацыя

3. залежнасці

Інфраструктура - гэта месца, дзе прыкладанне або служба будзе разгорнута, і прыкладанне будзе выконваць пэўныя канфігурацыйныя патрэбы. Яна таксама ўключае, як залежнасць трэба інтэграваць з дадаткам. На сённяшні дзень інфраструктуру можна забяспечваць па сцэнары альбо называюць яе "Інфраструктура як код", альбо, скажам, IaC. Сёння IaC становіцца больш даступным праз шырокі спектр інструментаў, даступных для аўтаматызацыі ўсяго працэсу забеспячэння навакольнага асяроддзя.

Канфігурацыя - наступны, найбольш вынікаючы аспект асяроддзя прыкладання. Канфігурацыя дыктуе, як прыкладанне паведамляе ў той ці іншай інфраструктуры, і як інфраструктура аднаўляецца з базавай праграмай.

Залежнасці - гэта розныя модулі альбо сістэмы, ад якіх залежыць прыкладанне, ад бібліятэк да служб і іншых прыкладанняў.

Перавага выкарыстання аўтаматызаванага забеспячэння навакольнага асяроддзя наступная;

  • Зніжэнне складанасці дазваляе камандам DevOps працаваць на больш высокім узроўні абстракцыі.
  • Падвышаная ўстойлівасць дзякуючы магчымасці прыкладанням дынамічна рэагаваць на іх разгортванне.
  • Падвышаная гнуткасць за кошт развязкі кіравання канфігурацыяй ад канкрэтнай асяроддзя хостынгу прыкладання.

У нас ёсць шмат інструментаў на рынку, няхай гэта будзе з адкрытым зыходным кодам або прадпрыемствам, якія мы можам выкарыстоўваць для аўтаматызацыі прадастаўлення ўсіх трох вышэйзгаданых абласцей, такіх як ніжэй;

6.Стандартызацыя DevOps Toolchain і прадастаўленне яе як самаабслугоўванне

Пасля таго, як мэты і працэсы прыняцця DevOps вызначаны, мы можам вызначыць набор інструментаў, неабходных для задавальнення працэсаў. Пераканайцеся, што каманды па распрацоўцы і ІТ працуюць разам, каб вызначыцца з інструментамі, прыдатнымі для арганізацыі. З любым новым інструментам, які ўводзіцца, наяўныя работнікі павінны прайсці навучанне. Таксама важна, каб інструменты адпавядалі патрабаванням бяспекі і былі добра інтэграваны з існуючымі рэсурсамі і паслугамі.

** Проста назваць некалькі ланцужкоў інструментаў, даступных на рынку для вышэйзгаданых раздзелаў.

7. Паскарэнне кіравання рэлізамі

Пасля таго, як мы правільна вызначылі навакольнае асяроддзе, кіраўнікам DevOps неабходна стварыць адпаведны канвеер, які патрэбны для аўтаматычнага запуску для разгортвання, калі патрэбны вароты зацвярджэння папярэдняга разгортвання і калі неабходна размясціць этап кантролю якасці / тэставання. На малюнку ніжэй прыведзены асноўны канвектар выпуску з аўтаматычным і ручным разгортваннем;

Пасля таго, як у вас ёсць правільны канвеер выпуску, аўтаматызацыя пабудовы, інтэграцыі, тэсціравання і дастаўкі і іншых працэсаў, гэта прывядзе да скарачэння чалавечай дзейнасці ў кожным выпуску, а таксама да неабходнасці кіравання і ўзгаднення.

Паскарэнне развіцця стала канкурэнтнай перавагай, каманда DevOps імкнулася даць магчымасць бесперапыннай інтэграцыі і бесперапыннай дыстрыбуцыі (CI / CD). CI / CD дапамагае распрацоўшчыкам і ІТ-аперацыям пераадолець вялікія праблемы з распрацоўкай і тэставаннем праграмнага забеспячэння. За гэтыя гады распрацоўка праграмнага забеспячэння перайшла з узроўню прадпрыемства, дзе ёсць шырокія рэсурсы, на меншыя групы распрацоўшчыкаў, якія імкнуцца ісці ў нагу з попытам, згенераваным мільярдамі смартфонаў і іншых мабільных спажывецкіх прылад і платформаў. Ніжэй прыведзены прыклад CI / CD-трубаправода з камбінаваным ланцужком даступных інструментаў;

У нашым выпадку мы вырашылі выкарыстоўваць камбінацыю інструментаў, паколькі, здаецца, прапануем лепшае рашэнне для нашых складаных патрэбаў. Большасць каманд, якія распрацоўваюць карпаратыўную прадукцыю, выйграюць ад такога наземнага падыходу. Наш стэк інструментарыяў складаецца з:

  1. Atlassian JIRA - гэта інструмент для сумеснай працы ў камандзе з зачыненых прадуктаў, планавання спрынтаў і справаздачы аб выпуску і таго, наколькі добра Agile працуе ў кожным спрынце.
  2. Github - гэта сістэма кіравання размеркаванай версіяй (DVCS), дзе распрацоўшчык мае зносіны адзін з адным і супрацоўнічае, каб палепшыць код функцыі прадукту і бачыць змены і версіі кода. Любыя змены павінны быць разгледжаны іншымі распрацоўшчыкамі альбо рэцэнзентам кода, што зрабіла код больш чыстым і менш памылак / памылак.
  3. Azure DevOps - гэта інструмент, які мы выкарыстоўваем, каб арганізаваць наш CI / CD канвеер, і гэта таксама месца, дзе можна больш супрацоўнічаць паміж DevOps Engineer, Developer, Release Manager і QA-камандай. Гэта таксама месца, дзе адбываецца інтэграцыя, каб даставіць прадукт з добрым якасцю, таму мы прааналізуем бяспеку і тэставанне якасці перад тым, як размясціць у вытворчым асяроддзі.
  4. Datadog - гэта інструмент маніторынгу, які з дапамогай Datadog вы можаце адсочваць вашы серверы, вашыя аблокі, вашыя метрыкі, дадаткі, вашу каманду разам. Гэта як адзін прыпынак для ўсіх відаў манітораў для вашай навакольнага асяроддзя і прадуктаў.

Эфектыўны канвеер CI / CD можа значна палепшыць час на рынак і палепшыць стабільнасць і якасць распаўсюджанага праграмнага забеспячэння.

8. Аўтаматызацыя тэсціравання

DevOps спрыяе аўтаматызацыі, і яе мэты зрабіць як мага больш аўтаматызацыі ўсіх паўсядзённых задач, якія не патрабуюць умяшанняў чалавека. Даданне экспертаў па кантролі якасці ў склад каманды DevOps дапаможа камандзе вызначыцца з найлепшым падыходам альбо інструментамі тэсціравання могуць быць аўтаматызаваны. Інструменты аўтаматызацыі звычайна працуюць, калі гаворка ідзе пра тэставанне прыкладных або сістэмных памылак, але тэставанне якасці дазваляе значна лепш працаваць з тэставаннем на зручнасць і гатоўнасць да выпуску.

Інтэграцыя аўтаматычнага бесперапыннага тэставання ў ваш канвеер CI / CD патрабуе рэалізацыі тэставання прыкладанняў, які лёгка інтэгруецца з зборкай, тэставай аўтаматызацыяй і рэалізацыямі CI / CD, якія вы ўжо выкарыстоўваеце, і якая мае шырокую падтрымку вэб-API. Перавага выкарыстання аўтаматычнага бесперапыннага тэставання заключаецца ў наступным:

Стабільнасць. Гэта дапаможа вам больш паслядоўна ўжываць рэквізіты якасці і бяспекі. Калі вы запісалі тэст бяспекі ўручную, а потым аўтаматызавалі яго, гэта стане патрабаваннем бяспекі, якое вы можаце выканаць пры кожнай зборцы.

Хуткасць. Аўтаматызаванае бесперапыннае тэставанне на аснове маштабуемых інструментаў, распрацоўшчыкі могуць знайсці і наладзіць праблемы ў сапраўдны час на працягу ўсяго SDLC. Гэта паскарае распрацоўку прыкладання і пазбягае памылак, характэрных для ручнога тэставання.

Маштаб. Для маштабавання ручнога тэставання вам спатрэбіцца больш ручных тэстараў. Каб маштабаваць аўтаматызаванае тэставанне, для тэставання вам спатрэбіцца толькі больш прыкладанняў і праграм.

Выснова

Прыняцце DevOps - гэта падарожжа, якое павінна пачынацца з аналізу архітэктуры і мэтаў арганізацыі. Вырашэнне гэтых агульных праблем у працэсе прыняцця DevOps зробіць трансфармацыю значна больш гладкай. За пэўны перыяд кожная каманда альбо чалавек у арганізацыі прывыкне да змен DevOps і адаптуецца да бесперапынных працэсаў навучання. Пасля таго, як каманды па распрацоўцы, эксплуатацыі і кіраванні даведаюцца, як супрацоўнічаць, яны аўтаматычна дапамагаюць адзін аднаму і цесна супрацоўнічаюць для архівавання мэт па прыняцці DevOps.