![30 глупых вопросов Product Manager [Карьера в IT]](https://i.ytimg.com/vi/-WCQlXIL9M4/hqdefault.jpg)
Съдържание
Източник: Nexusplexus / Dreamstime.com
За вкъщи:
DevOps - сливането на разработката и операциите - е метод за разработка на софтуер, който набира популярност поради своята ефективност.
Независимо от това, каква е вашата ИТ стратегия, може спокойно да се предположи, че всяка ИТ стратегия има за цел навременна доставка на качествен софтуер, бързо отстраняване на проблеми, подобряване на потребителското изживяване и оптимално използване на ресурсите. Традиционните модели за разработка на софтуер в различна степен не успяха да постигнат тези цели. Компаниите се надпреварват да намерят баланс между навременната доставка на качествен софтуер и оптималното използване на ресурсите. Сега наличието на софтуер в облака означава, че потребителите имат достъп до софтуер чрез стандартни браузъри. В резултат обратна връзка и проблеми се наводняват, поставяйки софтуерни компании под огромен натиск да доставят поправки бързо. Основна причина за подобни проблеми е прекъсването на връзката между разработчиците, QA и оперативните екипи. Концепцията на DevOps помага на компаниите да управляват тези проблеми чрез по-голямо сътрудничество между екипи и активно управление на проблемите. Принципите на DevOps се включват в моделите за разработка на софтуер на много компании.
Какво е DevOps?
DevOps е скорошна култура на разработка на софтуер, която предефинира начина, по който компаниите трябва да разработят и управляват софтуер при променен бизнес сценарий. Сега много софтуерни приложения се хостват в облака и се предоставят на потребителите чрез браузъри. На потребителите се предоставят и възможности за публикуване на техните отзиви или проблеми. В резултат на това компаниите получават много отзиви бързо. Тази ситуация е различна от тази при традиционната разработка на софтуер, когато грешки или проблеми се съобщават по някои определени канали и отнема известно време, за да се достигне до съответния екип. Честото съобщаване на грешки и проблеми оказва огромен натиск върху компанията за бързото отстраняване на проблемите. В традиционните модели за разработка на софтуер, екипите за разработка, QA и операционни дейности са изключени един от друг, което води до забавено реагиране на проблеми. В конкурентна среда това може да бъде критичен фактор.
Терминът DevOps е създаден чрез комбиниране на думите „развитие“ и „операции“, а основната идея е синергия между разработчиците и оперативния екип. В културата DevOps работата в силози не се приема. Разработчиците, QA и оперативният персонал се насърчават да мислят за общия доставен софтуер и какво могат да направят, за да пуснат качествен софтуер. Например, разработчикът се насърчава да мисли за възможните сценарии след проверка на кода, като например сценарии за разбиване на код, независимо дали случаите на използване са проблеми в реалния живот или хипотетични проблеми с потребителското изживяване. За да получи отговорите на тези въпроси, разработчикът трябва да се свърже с QA и оперативните екипи. Екипите също трябва активно да планират възможни проблеми и тяхното управление.
В обобщение, основната идея, която стои зад DevOps, е да засили сътрудничеството между екипа за разработка и операции, да предвиди и предотврати проблеми, да спре да мисли в силози и да мисли за принос за цялостното качество на софтуера. (За да научите повече за DevOps, вижте DevOps 101.)
Принципи на DevOps
Основните три принципа, които движат културата на DevOps в различни компании са описани по-долу.
Не можете да подобрите уменията си за програмиране, когато никой не се интересува от качеството на софтуера.
Примерно проучване на DevOps
Amazon се трансформира от онлайн търговец на дребно в пионер в облачното пространство с пускането на Amazon Web Services (AWS), IaaS по заявка, който сега се използва широко. Когато обаче Amazon навлезе в домейна на облачните услуги, компанията не знаеше много по темата. Имаше много рискове. И така, как Amazon създаде такъв огромен успех? (За повече информация за AWS, вижте какво носят Amazon Web Services в облака?)
Стратегията за това как Amazon стана успешна трябваше да бъде тайна, но един от бившите й служители, Стив Йеге, изтече вътрешна бележка, която предоставя важни подробности за това, което Джеф Безос иска от служителите, за да направи AWS успех.
- Всички екипи трябва да излагат данни, функции и функционалности чрез интерфейси за уеб услуги.
- Екипите трябва да комуникират помежду си чрез тези интерфейси за уеб услуги. Не се допускаше друга форма на комуникация, като свързване или споделяне.
- На екипите е разрешено да използват всякаква технология за използване на интерфейсите на уеб услугите - HTTP, CORBA, Pubsub, персонализирани протоколи - няма значение кой.
- Всички интерфейси за уеб услуги трябва да бъдат проектирани така, че интерфейсите да могат да бъдат изложени на външния свят.
В обобщение, инженерите в Amazon бяха задължени да изграждат уеб услуги, чрез които да могат да споделят данни и това би било единственото средство за споделяне на данни. Всеки екип, който се нуждаеше от данни от друг екип, трябваше да намери подходящи уеб услуги, чрез които да постави заявката. Ако не бъде намерена подходяща уеб услуга, те могат да ескалират въпроса. Екипите, изграждащи уеб услуга, също бяха необходими за осигуряване на уеб услугите, така че да не могат да бъдат достъпни без проверка на потребителските идентификационни данни.
И така, къде DevOps влиза в тази картина? Като част от инициативата AWS бяха създадени, използвани и тествани огромен брой уеб услуги, в които участваха огромен брой служители. Естествено, цялата гама от дейности доведе до създаването на огромен брой тестови случаи, проблеми, бъгове и случаи на използване. Ясно е, че почти всички екипи се включиха и изиграха своите роли - разработчиците разработиха уеб услуги, различни роли получиха достъп до интерфейсите и докладваха проблеми, ако има такива. Разработчиците трябваше непрекъснато да си сътрудничат с операции, QA и други роли, за да се уверят, че уеб услугите достигат минималното ниво на качество.
заключение
За всички ползи, които DevOps носи, не е лесно да се прилагат в една организация. Тъй като става въпрос за култура, преодоляването на бариерите и насърчаването на култура на непрекъсната комуникация може да отнеме много време. Промяната трябва да дойде от върха. Прилагането на новата система може да срещне съпротива под различни форми. Няма единен начин за внедряване на DevOps в организации, като се има предвид уникалният характер на различните работни среди. Организациите трябва да проучат кои методи биха работили най-добре за техните обстоятелства.