«Кем­брий­ский взрыв» в ми­ре ин­стру­мен­тов Devops

Otkrytye sistemy. SUBD. - - СОДЕРЖАНИЕ - Мик Кер­стен

Лю­бая дис­кус­сия на те­му, как по­лу­чить пре­иму­ще­ства Devops в усло­ви­ях все бо­лее мас­шта­би­ру­е­мых сред, неиз­мен­но сво­дит­ся к ин­стру­мен­там. Од­на­ко для Agile и Devops уже име­ет­ся огром­ное ко­ли­че­ство ин­стру­мен­тов. Сколь­ко же их нуж­но на са­мом де­ле?

Лю­бая дис­кус­сия на те­му, как по­лу­чить пре­иму­ще­ства Devops в усло­ви­ях все бо­лее мас­шта­би­ру­е­мых сред, неиз­мен­но сво­дит­ся к ин­стру­мен­там: при­ме­ня­е­мые сред­ства пла­ни­ро­ва­ния, от­сле­жи­ва­ния, ав­то­ма­ти­за­ции и управ­ле­ния опре­де­ля­ют ос­но­вы то­го, где и ка­ким об­ра­зом вы­пол­ня­ет­ся ра­бо­та. Од­на­ко для Agile и Devops уже име­ет­ся огром­ное ко­ли­че­ство ин­стру­мен­тов. Сколь­ко же их нуж­но на са­мом де­ле? Клю­че­вые сло­ва: сред­ства раз­ра­бот­ки Keywords: Devops, Agile, Development Tools

Се­год­ня Devops на­хо­дит­ся на ин­те­рес­ной ста­дии сво­ей эво­лю­ции — учи­ты­вая огром­ное ко­ли­че­ство до­ступ­ных средств, под­дер­жи­ва­ю­щих эту ме­то­до­ло­гию, мож­но го­во­рить о «кем­брий­ском взры­ве» раз­но­об­ра­зия ин­стру­мен­тов и об­ла­стей их при­ме­не­ния. («Кем­брий­ский взрыв» (Cambrian explosion) — услов­ное на­зва­ние яв­ле­ния, вы­звав­ше­го рез­кое уве­ли­че­ние ко­ли­че­ства ис­ко­па­е­мых остан­ков до­и­сто­ри­че­ских жи­вот­ных в от­ло­же­ни­ях, со­от­вет­ству­ю­щих на­ча­лу кем­брий­ско­го пе­ри­о­да. — Прим. ред.) Но дей­стви­тель­но ли это мно­го­об­ра­зие необ­хо­ди­мо? Про­изой­дет ли мас­штаб­ная кон­со­ли­да­ция, след­стви­ем ко­то­рой ста­нет ис­чез­но­ве­ние боль­шин­ства ны­неш­них ин­стру­мен­тов? Ка­кие имен­но об­ла­сти спе­ци­а­ли­за­ции средств спо­соб­ству­ют ро­сту мно­го­об­ра­зия и что сле­ду­ет учи­ты­вать при пла­ни­ро­ва­нии ар­хи­тек­ту­ры по­то­ков фор­ми­ро­ва­ния цен­но­сти ПО?

На про­тя­же­нии двух де­ся­ти­ле­тий, на­чи­ная с 1980-х го­дов, ос­нов­ной ком­па­ни­ей, ко­то­рая по­став­ля­ла сред­ства раз­ра­бот­ки ПО боль­шин­ству кор­по­ра­тив­ных Ит-от­де­лов, бы­ла Rational — во мно­гих ор­га­ни­за­ци­ях весь жиз­нен­ный цикл ПО от­сле­жи­вал­ся с по­мо­щью ин­стру­мен­таль­ной це­поч­ки про­дук­тов этой ком­па­нии. Се­год­ня есть со­блазн от­зы­вать­ся о по­доб­ных ин­стру­мен­тах-«тя­же­ло­ве­сах» с иро­ни­ей, од­на­ко Rational со­зда­ла це­поч­ку, ко­то­рая бы­ла неве­ро­ят­но слож­ной, но и эф­фек­тив­ной для сво­е­го вре­ме­ни. По­ми­мо средств раз­ра­бот­ки, в ком­па­нии пред­ло­жи­ли Rational Unified Process (RUP) — связ­ную си­сте­му про­цес­сов и ин­стру­мен­тов для про­грамм­ной ин­же­не­рии, обес­пе­чи­ва­ю­щую от­де­лам ИТ и ор­га­ни­за­ци­ям раз­ра­бот­ки ПО сквоз­ной об­зор, кон­троль и пред­ска­зу­е­мость мас­штаб­ных про­грамм­ных про­ек­тов. Фак­ти­че­ски RUP ста­ла стан­дар­том раз­ра­бот­ки по во­до­пад­ной мо­де­ли (waterfall). В 1990-х го­дах про­ис­хо­ди­ло стре­ми­тель­ное рас­ши­ре­ние ис­поль­зо­ва­ния как ин­стру­мен­таль­ной це­поч­ки, по­став­ля­е­мой Rational, так и со­от­вет­ству­ю­щих про­цес­сов и ме­то­до­ло­гий. За­тем, в 2000-х го­дах по­яви­лись ско­рые (Agile) ме­то­ды, преж­де все­го как ре­ак­ция на про­бле­мы, ко­то­рые по­ро­дил ко­манд­но-ад­ми­ни­стра­тив­ный стиль управ­ле­ния вы­пус­ком ПО, при­су­щий кас­кад­ной мо­де­ли и RUP. По­сле Agile по­яви­лось те­че­ние Devops, и се­год­ня бла­го­да­ря то­му и дру­го­му эпо­ха во­до­пад­ной мо­де­ли ушла в про­шлое: сре­ди по­чти 26 тыс. участ­ни­ков опро­са, про­ве­ден­но­го Stack Overflow в 2017 го­ду, 76,9% поль­зо­ва­лись ме­то­да­ми Agile и толь­ко 26,9% — во­до­пад­ной мо­де­лью [1]. Хо­тя по­след­няя по-преж­не­му при­ме­ня­ет­ся во мно­гих круп­ных ор­га­ни­за­ци­ях, се­год­ня пре­иму­ще­ства, обес­пе­чи­ва­е­мые Agile и Devops, об­ще­при­зна­ны: это бо­лее ко­рот­кие сро­ки по­став­ки и мень­ший объ­ем ра­бот на каж­дой ста­дии кон­вей­е­ра.

ПРИ­ЧИ­НЫ «ВЗРЫ­ВА»

Столь фун­да­мен­таль­ный пе­ре­во­рот в сто­ро­ну Agile/devops спо­со­бен пол­но­стью из­ме­нить от­расль — сфор­ми­ро­вал­ся ры­нок со­от­вет­ству­ю­щих ин­стру­мен­тов, ко­то­рые за­пол­ни­ли про­бел, об­ра­зо­вав­ший­ся в ре­зуль­та­те вы­тес­не­ния во­до­пад­ной мо­де­ли. Мас­шта­бы пе­ре­мен от­ра­же­ны на ри­сун­ке, где пе­ре­чис­ле­ны по­став­щи­ки ин­стру­мен­тов для но­вых ме­то­до­ло­гий. Боль­шин­ство этих по­став­щи­ков пред­ла­га­ют ре­по­зи­то­рий или уро­вень ав­то­ма­ти­за­ции для ка­ко­го-ли­бо сег­мен­та по­то­ка фор­ми­ро­ва­ния цен­но­сти ПО. По­ра­жа­ет как ко­ли­че­ство по­став­щи­ков, так и раз­но­об­ра­зие по­явив­ших­ся ка­те­го­рий ин­стру­мен­тов.

Мож­но так­же упо­мя­нуть про­ве­ден­ное ком­па­ни­ей Tasktop ис­сле­до­ва­ние, в рам­ках ко­то­ро­го бы­ли про­ана­ли­зи­ро­ва­ны ин­стру­мен­таль­ные це­поч­ки 300 от­де­лов ИТ круп­ных кор­по­ра­ций: в 70% этих ор­га­ни­за­ций уже ин­те­гри­ро­ва­ли три ин­стру­мен­та или боль­ше, а в 40% — не мень­ше че­ты­рех.

Кро­ме то­го, стре­ми­тель­но рас­ши­ри­лось ис­поль­зо­ва­ние средств с от­кры­тым

ко­дом. На­при­мер, рас­пре­де­лен­ную си­сте­му управ­ле­ния вер­си­я­ми Git, со­глас­но дан­ным Stack Overflow, ис­поль­зу­ют 69,2% из 30,7 тыс. участ­ни­ков опро­са, то­гда как Rational Clearcase — толь­ко 0,4% [2]. Очень быст­рый пе­ре­ход на Git и вы­тес­не­ние тра­ди­ци­он­ных тя­же­ло­вес­ных ин­стру­мен­тов ука­зы­ва­ют на важ­ную тен­ден­цию. У Agile, Devops и от­кры­то­го ко­да есть нечто об­щее: раз­ви­тие всех трех про­ис­хо­дит по ини­ци­а­ти­ве «сни­зу», и все они ори­ен­ти­ро­ва­ны на то, что­бы предо­ста­вить но­вые воз­мож­но­сти ис­пол­ни­те­лю. Эта трой­ка раз­ру­ша­ет мо­дель кон­тро­ля «свер­ху вниз», обес­пе­чи­вая «де­мо­кра­ти­за­цию» ин­стру­мен­таль­ной це­поч­ки. Из ри­сун­ка хо­ро­шо вид­но, что эта де­мо­кра­ти­за­ция от­ме­ня­ет свой­ствен­ный преж­ней эпо­хе прин­цип, по ко­то­ро­му один и тот же про­дукт пред­ла­гал­ся для всех нужд. Боль­шое ко­ли­че­ство ка­те­го­рий ин­стру­мен­тов сви­де­тель­ству­ет о по­яв­ле­нии раз­лич­ных спе­ци­а­ли­за­ций, че­го рань­ше не бы­ло. По­треб­ность в та­ком раз­де­ле­нии обя­зан­но­стей обу­слов­ле­на раз­ли­чи­я­ми в ти­пах ра­бот, вы­пол­ня­е­мых в рам­ках про­цес­са вы­пус­ка ПО.

С ро­стом мас­шта­бов раз­ра­бот­ки ее раз­лич­ные участ­ни­ки на­ча­ли от­да­вать пред­по­чте­ние ин­стру­мен­там, пред­на­зна­чен­ным спе­ци­аль­но для кон­крет­ных ро­лей. На­при­мер, ин­стру­мент, от­сле­жи­ва­ю­щий ин­ци­ден­ты и рас­счи­тан­ный на ра­бо­ту с со­гла­ше­ни­я­ми об уровне об­слу­жи­ва­ния, су­ще­ствен­но от­ли­ча­ет­ся от си­сте­мы мо­ни­то­рин­га про­блем в жур­на­ле по­же­ла­ний и от си­сте­мы для биз­не­са­на­ли­ти­ков, мо­де­ли­ру­ю­щей кли­ент­ские сце­на­рии ис­поль­зо­ва­ния про­дук­тов и ра­бо­чие про­цес­сы. Меж­ду тем внут­рен­нее устрой­ство та­ких ин­стру­мен­тов мо­жет вы­гля­деть иден­тич­ным с точ­ки зре­ния мо­де­лей дан­ных, средств сов­мест­ной ра­бо­ты и движ­ков ра­бо­чих про­цес­сов. Имен­но по­это­му в ор­га­ни­за­ци­ях рань­ше мог­ли поль­зо­вать­ся од­ним ин­стру­мен­том для раз­лич­ных за­дач. Од­на­ко с ро­стом мас­шта­бов за­дач уве­ли­чи­ва­ет­ся и ко­ли­че­ство ис­пол­ни­те­лей раз­ных спе­ци­аль­но­стей. Со­от­вет­ствен­но, ис­пол­ни­те­ли на­ча­ли тре­бо­вать поль­зо­ва­тель­ские ин­тер­фей­сы, оп­ти­ми­зи­ро­ван­ные для кон­крет­ных за­дач. Это вы­ну­ди­ло по­став­щи­ков на­чать де­лить свои ре­ше­ния по об­ла­сти спе­ци­а­ли­за­ции, что и по­ро­ди­ло «кем­брий­ский взрыв» в ин­стру­мен­таль­ном пу­ле. Раз­лич­ные ка­те­го­рии средств мож­но счи­тать от­ра­же­ни­ем раз­лич­ных стра­те­гий ста­биль­но­го эво­лю­ци­он­но­го раз­ви­тия для по­став­щи­ков. При этом рост мно­го­об­ра­зия внут­ри ка­те­го­рий и чис­лен­но­сти их са­мих обу­слов­лен на­ли­чи­ем щед­ро­го на ре­сур­сы рын­ка ор­га­ни­за­ций, раз­ра­ба­ты­ва­ю­щих все бо­лее мас­штаб­ные про­грамм­ные про­ек­ты.

АНА­ЛИЗ МНО­ГО­ОБ­РА­ЗИЯ

Пред­сто­ит ли ны­неш­ним ин­стру­мен­там мас­со­вое вы­ми­ра­ние? Ана­лиз ин­стру­мен­таль­ных це­по­чек поз­во­ля­ет вы­явить два ти­па мно­го­об­ра­зия ин­стру­мен­тов.

Фун­да­мен­таль­ное мно­го­об­ра­зие при­но­сит поль­зу за счет по­вы­ше­ния про­дук­тив­но­сти вы­пус­ка ПО. На­при­мер, груп­пы, раз­ра­ба­ты­ва­ю­щие Java-при­ло­же­ния, дей­ству­ют про­дук­тив­нее при ис­поль­зо­ва­нии Kira, а раз­ра­бот­чи­кам, при­ме­ня­ю­щим Azure и .NET, тот же ре­зуль­тат обес­пе­чи­ва­ет Visual Studio Team Services.

Слу­чай­ное мно­го­об­ра­зие не по­мо­га­ет ор­га­ни­за­ции в до­сти­же­нии ее це­лей. В эту ка­те­го­рию вхо­дят ин­стру­мен­ты, уна­сле­до­ван­ные в ре­зуль­та­те сли­я­ний и при­об­ре­те­ний, или сред­ства с по­хо­жей функ­ци­о­наль­но­стью, ко­то­рые бы­ли взя­ты на во­ору­же­ние неза­ви­си­мо друг от дру­га вви­ду от­сут­ствия цен­тра­ли­зо­ван­но­го ру­ко­вод­ства. На­при­мер, у ор­га-

ни­за­ции мо­жет быть сра­зу три си­сте­мы от­сле­жи­ва­ния оши­бок: уна­сле­до­ван­ный ин­стру­мент два­дца­ти­лет­ней дав­но­сти, раз­ра­бо­тан­ный соб­ствен­ны­ми си­ла­ми; со­вре­мен­ный тре­кер про­блем, ко­то­ро­му от­да­ют пред­по­чте­ние раз­ра­бот­чи­ки; ана­ло­гич­ный тре­кер с от­кры­тым ко­дом, пе­ре­шед­ший в ор­га­ни­за­цию по­сле по­гло­ще­ния дру­гой ком­па­нии.

Для ар­хи­тек­ту­ры по­то­ка фор­ми­ро­ва­ния биз­нес-цен­но­сти важ­ны оба ви­да мно­го­об­ра­зия. Слу­чай­ное долж­но по­буж­дать к кон­со­ли­да­ции и ра­ци­о­на­ли­за­ции. Это от­но­си­тель­но неслож­но, ра­ци­о­на­ли­за­ция под­ра­зу­ме­ва­ет, что по­ток фор­ми­ро­ва­ния цен­но­сти дол­жен со­дер­жать толь­ко один ин­стру­мент в каж­дой необ­хо­ди­мой ка­те­го­рии. Бо­лее про­бле­ма­тич­но, ко­гда в ор­га­ни­за­ции неспо­соб­ны от­ли­чать слу­чай­ное мно­го­об­ра­зие от фун­да­мен­таль­но­го.

При ис­сле­до­ва­нии по­то­ков фор­ми­ро­ва­ния цен­но­сти бы­ли иден­ти­фи­ци­ро­ва­ны шесть раз­но­вид­но­стей фун­да­мен­таль­но­го мно­го­об­ра­зия.

Спе­ци­а­ли­за­ция по за­ин­те­ре­со­ван­ным ли­цам. Раз­лич­ным участ­ни­кам про­цес­са вы­пус­ка ПО нуж­ны раз­ные ин­стру­мен­ты для по­вы­ше­ния эф­фек­тив­но­сти в сво­ем кон­крет­ном на­прав­ле­нии де­я­тель­но­сти. На­при­мер, со­труд­ни­кам служ­бы под­держ­ки нуж­ны ин­стру­мен­ты, ори­ен­ти­ро­ван­ные на со­гла­ше­ния об уровне об­слу­жи­ва­ния или ITIL, а раз­ра­бот­чи­кам тре­бу­ют­ся сред­ства, оп­ти­ми­зи­ро­ван­ные для про­цес­сов ре­ви­зии и об­нов­ле­ния ко­да. Спе­ци­а­ли­за­ция по мас­шта­бу. Неко­то­рые ин­стру­мен­ты спе­ци­а­ли­зи­ро­ва­ны в за­ви­си­мо­сти от раз­ме­ра ор­га­ни­за­ции. Так, упро­щен­ный ин­стру­мент Kanban мо­жет под­хо­дить для оп­ти­ми­за­ции ра­бо­чих про­цес­сов де­сят­ка ко­манд, а для от­сле­жи­ва­ния тре­бо­ва­ний в си­сте­ме, кри­тич­ной к без­опас­но­сти, необ­хо­дим иерар­хи­че­ский ин­стру­мент со­от­вет­ству­ю­ще­го на­зна­че­ния. Спе­ци­а­ли­за­ция по плат­фор­ме. По­став­щи­ки платформ раз­ра­бот­ки неред­ко пред­ла­га­ют по­стро­ен­ное на со­от­вет­ству­ю­щих ин­стру­мен­тах ре­ше­ние для осво­е­ния сво­ей плат­фор­мы. На­при­мер, Microsoft по­став­ля­ет уни­вер­саль­ные ре­ше­ния Devops и Agile, оп­ти­ми­зи­ро­ван­ные для плат­фор­мы раз­ра­бот­ки Azure, но в мень­шей сте­пе­ни под­хо­дя­щие для бо­лее ге­те­ро­ген­ной эко­си­сте­мы Java. Спе­ци­а­ли­за­ция по зоне. В кни­ге «Zone to Win» Джеф­ф­ри Мур пе­ре­чис­ля­ет «зо­ны», со­от­вет­ству­ю­щие раз­лич­ным ста­ди­ям зре­ло­сти пред­при­я­тия [3]. Для про­дук­та, ори­ен­ти­ро­ван­но­го на экс­пе­ри­мен­таль­ную «зо­ну транс­фор­ма­ции», мо­гут по­на­до­бить­ся толь­ко са­мые про­стые и экс­пе­ри­мен­таль­ные ин­стру­мен­ты — на­при­мер, сред­ства от­сле­жи­ва­ния про­блем, до­ступ­ные на Github. Бо­лее зре­лые про­дук­ты, на­хо­дя­щи­е­ся в «зоне про­из­во­ди­тель­но­сти», по­тре­бу­ют бо­лее тес­ной ин­те­гра­ции с за­про­са­ми биз­не­са и пла­ни­ро­ва­ни­ем. Мно­го­об­ра­зие по­став­щи­ков. С ро­стом аут­сор­син­га и ис­поль­зо­ва­ния ПО с от­кры­тым ко­дом ста­но­вит­ся непрак­тич­ным рас­счи­ты­вать на то, что по­став­щи­ки ПО бу­дут при­ме­нять те же ин­стру­мен­ты, что и ор­га­ни­за­ция-по­тре­би­тель. На­при­мер, в рам­ках про­ек­тов с от­кры­тым ко­дом обыч­но ис­поль­зу­ют­ся ин­стру­мен­ты с от­кры­тым ко­дом, а мел­кие по­став­щи­ки ча­ще при­ме­ня­ют упро­щен­ные ин­стру­мен­ты от­сле­жи­ва­ния, а не сред­ства уров­ня пред­при­я­тия, рас­счи­тан­ные на вы­пуск круп­ных про­грамм­ных про­ек­тов. Уна­сле­до­ван­ные си­сте­мы. За­тра­ты и на­ру­ше­ния ра­бо­то­спо­соб­но­сти, со­пря­жен­ные с от­хо­дом от уна­сле­до­ван­ной си­сте­мы (от уста­рев­ше­го ин­стру­мен­та или раз­ра­бо­тан­но­го са­мо­сто­я­тель­но тре­ке­ра де­фек­тов), мо­гут быть чрез­мер­ны­ми. Осо­бен­но это спра­вед­ли­во для дав­но вы­пус­ка­ю­щих­ся про­дук­тов, на­хо­дя­щих­ся в ре­жи­ме со­про­вож­де­ния или в «зоне про­из­во­ди­тель­но­сти». Эти ин­стру­мен­ты мо­гут быть еще од­ним ис­точ­ни­ком мно­го­об­ра­зия, ес­ли их мо­дер­ни­за­ция чре­ва­та оста­нов­кой ра­бо­че­го про­цес­са.

Всем ор­га­ни­за­ци­ям сто­ит стре­мить­ся к из­бав­ле­нию от слу­чай­но­го мно­го­об­ра­зия, хо­тя вы­яс­ни­лось, что нор­мой се­год­ня яв­ля­ет­ся ге­те­ро­ген­ная це­поч­ка луч­ших в сво­ем клас­се ин­стру­мен­тов. Од­на­ко с уче­том быст­ро­го ро­ста чис­ла стар­та­пов неко­то­рая кон­со­ли­да­ция неиз­беж­на: по­треб­ность в спе­ци­а­ли­за­ции столь вы­со­ка, что, преж­де чем на­чать умень­шать­ся, мно­го­об­ра­зие еще ка­кое-то вре­мя бу­дет рас­ти. На­при­мер, Ит-от­де­лы круп­ных пред­при­я­тий на­чи­на­ют от­хо­дить от по­то­ков фор­ми­ро­ва­ния цен­но­сти, жиз­нен­ный цикл ко­то­рых при­вя­зан к сро­кам и бюд­же­ту про­ек­та. Вза­мен ис­поль­зу­ет­ся по­ток фор­ми­ро­ва­ния цен­но­сти, ори­ен­ти­ро­ван­ный на про­дукт; при этом глав­ны­ми фак­то­ра­ми яв­ля­ют­ся са­мо ПО и вы­бор по­став­щи­ков и ин­стру­мен­тов. Пе­ре­ход от про­ект­ной к про­дук­то­вой ори­ен­та­ции при­во­дит к ро­сту еще од­ной ка­те­го­рии ин­стру­мен­тов управ­ле­ния про­дук­та­ми, пред­став­ля­ю­щих со­бой нечто сред­нее меж­ду тра­ди­ци­он­ны­ми си­сте­ма­ми со­став­ле­ния тре­бо­ва­ний и сред­ства­ми Agile­пла­ни­ро­ва­ния.

Кро­ме то­го, по ме­ре ро­ста уров­ня слож­но­сти раз­ра­бот­ки ПО услож­ня­ет­ся и си­сте­ма спе­ци­а­ли­за­ций в ин­стру­мен­таль­ной це­поч­ке. Ана­ло­гич­ные про­цес­сы про­ис­хо­дят в дру­гих об­ла­стях — на­при­мер, в ме­ди­цине, где пре­иму­ще­ства раз­де­ле­ния тру­да обу­сло­ви­ли по­сто­ян­ный рост чис­ла спе­ци­а­ли­за­ций. С ро­стом слож­но­сти ПО уве­ли­чи­ва­ет­ся и ко­ли­че­ство ис­пол­ни­те­лей раз­ных спе­ци­аль­но­стей, что обу­слов­ли­ва­ет даль­ней­шую ди­вер­си­фи­ка­цию ин­стру­мен­тов.

Пробле­ма в том, что при по­пыт­ке ана­ли­зи­ро­вать и со­вер­шен­ство­вать прин­ци­пы со­зда­ния ПО из-за огром­ной мас­сы ин­стру­мен­тов воз­ни­ка­ет си­ту­а­ция, ко­гда «за де­ре­вья­ми не вид­но ле­са». Ни­ка­кой от­дель­но взя­тый ин­стру­мент не ре­а­ли­зу­ет мо­де­ли всей си­сте­мы. Од­на­ко по­то­ки фор­ми­ро­ва­ния цен­но­сти бу­дут по-преж­не­му опре­де­лять­ся ин­стру­мен­та­ми и каж­дая ста­дия вы­пус­ка бу­дет ре­а­ли­зо­вы­вать­ся со­глас­но схе­ме и мо­де­ли ра­бо­че­го про­цес­са опре­де­лен­но­го ин­стру­мен­та. Тем не ме­нее, что­бы пе­ре­ве­сти Devops на но­вый уро­вень, необ­хо­ди­мо на­чать мыс­лить в ка­те­го­ри­ях пол­но­цен­ных си­стем. Един­ствен­ный спо­соб до­бить­ся это­го — со­здать но­вую ар­хи­тек­тур­но-ори­ен­ти­ро­ван­ную дис­ци­пли­ну по управ­ле­нию сло­ем, на­хо­дя­щим­ся над ин­стру­мен­таль­ной це­поч­кой. Эволюция ин­стру­мен­таль­ных це­по­чек про­дол­жит­ся, как и рост чис­ла спе­ци­а­ли­за­ций, от­ве­ча­ю­щих по­треб­но­стям раз­лич­ных участ­ни­ков про­цес­са вы­пус­ка ПО. Спе­ци­а­ли­за­ция и обу­слов­лен­ное ею мно­го­об­ра­зие ин­стру­мен­тов — фун­да­мен­таль­ные ас­пек­ты со­вре­мен­ной ин­стру­мен­таль­ной це­поч­ки Devops. В даль­ней­шем мож­но ожи­дать по­вы­ше­ния уров­ня аб­страк­ции и мо­де­ли­ро­ва­ния но­во­го слоя по­верх ин­стру­мен­таль­ной це­поч­ки.

ЛИ­ТЕ­РА­ТУ­РА

1. Developer Survey Results: 2017. Stack Overflow, 2017. URL: insights.stackoverflow. com/survey/2017 (да­та об­ра­ще­ния: 23.04.2018).

2. G. Kim et al. The Devops Handbook: How to Create World-class Agility, Reliability, and Security in Technology Organizations, IT Revolution, 2016.

3. G.A. Moore. Zone to Win: Organizing to Compete in an Age of Disruption, Diversion, 2015.

Взрыв­ной рост мно­го­об­ра­зия ин­стру­мен­тов Devops

Newspapers in Russian

Newspapers from Russia

© PressReader. All rights reserved.