Зашто је ДевОпс важан за вашу ИТ стратегију

Аутор: Louise Ward
Датум Стварања: 6 Фебруар 2021
Ажурирати Датум: 26 Јуни 2024
Anonim
Как устроена IT-столица мира / Russian Silicon Valley (English subs)
Видео: Как устроена IT-столица мира / Russian Silicon Valley (English subs)

Садржај



Извор: Некусплекус / Дреамстиме.цом

Одузети:

ДевОпс - спајање развоја и операција - је метода развоја софтвера која добија све већу популарност због своје ефикасности.

Без обзира на вашу ИТ стратегију, са сигурношћу се може претпоставити да свака ИТ стратегија има за циљ правовремену испоруку квалитетног софтвера, брзо решавање проблема, побољшање корисничког искуства и оптимално коришћење ресурса. Традиционални модели развоја софтвера у различитом смислу нису успели да постигну ове циљеве. Компаније су се бориле да пронађу равнотежу између благовремене испоруке квалитетног софтвера и оптималног коришћења ресурса. Доступност софтвера у облаку значи да корисници могу да приступе софтверу путем стандардних прегледача. Као резултат тога, повратне информације и проблеми преплављују се, што ставља софтверске компаније под огроман притисак да брзо пошаљу исправке. Главни разлог таквих проблема је прекид између развојних, КА и оперативних тимова. Концепт ДевОпс помаже компанијама да управљају овим проблемима путем веће сарадње између тимова и проактивног управљања проблемима. ДевОпс принципи су уграђени у моделе развоја софтвера многих компанија.


Шта је ДевОпс?

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

Израз ДевОпс је настао комбиновањем речи "развој" и "операције", а главна идеја је синергија између програмера и оперативног тима. У култури ДевОпс рад у силосу није прихваћен. Развојни програмери, КА-и и оперативно особље се охрабрују да размисле о укупном испорученом софтверу и ономе што могу учинити како би издали квалитетан део софтвера. На пример, програмер се охрабрује да размисли о могућим сценаријима након провере кода, као што су сценарији пробијања кода, било да су случајеви употребе стварни или хипотетички проблеми са корисничким искуством. Да би добио одговоре на ова питања, програмер мора контактирати КА и оперативне тимове. Тимови такође морају проактивно планирати могуће проблеме и њихово управљање.


Укратко, главна идеја која стоји иза ДевОпс-а је повећати сарадњу између развојног и оперативног тима, предвидети и спречити проблеме, престати размишљати у силосу и размишљати о доприносу целокупном квалитету софтвера. (Да бисте сазнали више о ДевОпс-у, погледајте ДевОпс 101.)

Принципи ДевОпс-а

Главна три принципа која покрећу културу ДевОпс-а у различитим компанијама описана су у наставку.

Не можете побољшати своје програмирање кад никога није брига за квалитет софтвера.

Студија случаја на ДевОпс-у

Амазон се трансформисао из интернетског продавца у пионира у облачном простору издањем Амазон Веб Сервицес (АВС), ИааС-а на захтев, који се сада широко користи. Међутим, када је Амазон ушао у домену облачних услуга, компанија није много знала о овој теми. Било је пуно ризика. Па како је Амазон створио тако огроман успех? (За више информација о АВС-у, погледајте шта Амазон Веб Сервицес доводи у облак?)

Стратегија о томе како је Амазон постао успешан требало је да буде тајна, али један од његових бивших запослених, Стеве Иегге, објавио је унутрашњу белешку која пружа важне детаље о ономе што је Јефф Безос желео да запослени ураде да АВС постане успешан.

  • Сви тимови морају изложити податке, карактеристике и функционалности путем интерфејса за интернетске сервисе.
  • Тимови морају међусобно комуницирати преко ових интерфејса за веб сервисе. Није дозвољен никакав други облик комуникације, попут повезивања или дељења.
  • Тимовима је дозвољено да користе било коју технологију за коришћење интерфејса за веб сервисе - ХТТП, ЦОРБА, Пубсуб, прилагођене протоколе - није битно која.
  • Сва интерфејса за веб сервисе морају бити дизајнирана тако да интерфејси могу бити изложени спољном свету.

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

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

Закључак

Уз све предности које ДевОпс доноси, није га лако имплементирати кроз организацију. Будући да је реч о култури, разбијање баријера и неговање културе флуидне комуникације може потрајати много времена. Промјена мора доћи с врха. Примена новог система може се суочити са отпором у различитим облицима. Не постоји јединствени начин имплементације ДевОпс-а кроз организације с обзиром на јединствену природу различитих радних окружења. Организације би требало да истражују који методи би најбоље одговарали њиховим околностима.