Меню

Управление на изданията в DevOps

release management devops

Опитайте Нашия Инструмент За Премахване На Проблемите

Какво представлява управлението на изданията в DevOps?

Надявам се да сте били наясно Концепция за управление на конфигурацията в DevOps от последния ни урок.

Както дефинирахме DevOps по-рано, DevOps е целият екип, притежаващ софтуера от самото му създаване, докато не бъде доставен на продукцията и гарантиращ, че приложението работи в производството според изискванията.

Препоръчително четене => Най-добрите уроци за обучение за DevOps

Управление на изданията в DevOps

Следователно, „Управление на изданията“, както всички знаем, е да управляваме коя версия на софтуера е внедрена в коя среда, кога и как не е отговорност само на Release Manager, но и отговорността на целия екип в DevOps.

Основните предимства на Release Management в DevOps могат да бъдат обобщени като,

    • По-бързи и последователни доставки.
    • Силен одит и проследимост на промените.
    • Автоматизация на процеса на освобождаване: По-високо качество, последователност, увереност.
    • Повишава доверието чрез успешни и последователни доставки.
    • Осъществяване на освобождаване - ненатоварена дейност
    • Без престой

ВИДЕО Част 4 Блок 2: Управление на изданията- 17 минути 12 секунди

Стенограма:

В този блок ще разберем Процедура за управление на изданията на DevOps .

Какво представлява управлението на изданията в контекста на DevOps и кои са основните му предимства?

Когато си мисля за управление на изданията, различните въпроси, които възникват в съзнанието ми, са кое издание се изпълнява в коя среда и какви кръпки са приложени там? Кои са актуалните корекции, които са внедрени и за кой клиент е?

Знам, че главоболието на мениджъра на изданията е да следи цялата тази информация. По-рано знаем, че управлението на изданията не е било отговорност на Dev или Ops. Това беше отделен екип за управление на изданията, който използваше за управление на дейностите по издаване на софтуер.

И отделен съвет, наречен CCB и CAB, съвет за контрол на промените, съвет за одобрение на промените, използван за отговорност по управлението на промените и контрол върху това какво се прилага и какво не.

Но сега нещата се промениха с DevOps. И това е не само отговорността на мениджъра на изданието, но и на целия екип.

Както дефинирахме DevOps по-рано, DevOps е цял екип, притежаващ софтуера от самото начало, докато той бъде доставен на продукцията и гарантиращ, че приложението работи в производството според изискванията.

По този начин в DevOps, освен ако кодът не е разположен на сайта и не се следи за неговата ефективност успешно за определен период, задачата за разработка на софтуер не е завършена.

Следователно, отговорността за доставката на софтуера и неговото представяне на живо е на всички в екипа. Както и задачите за управление на изданията.

Ще научим повече за аспектите на управлението на изданията в DevOps.

Нека разберем какво е управление на освобождаването?

Както всички знаем, от широка перспектива управлението на изданията управлява и поддържа информацията подобно, коя версия на софтуера или компонентите са разположени в коя среда, кога и как е била внедрена.

кой е най-добрият софтуер за разработка на приложения

И така, всичко е свързано с управлението на изданията.

Нека да видим как работи процесът на управление на изданията.

За разлика от преди, в DevOps няма официални CCB. Но това не означава, че няма одобрения за промените.

Одобренията се извършват и чрез инструмент. Инструментите за управление на промените като Jeera и ClearQuest се използват за извършване на запис и одобрение на промените и насочването им в екипа на Dev с цел изграждане на изоставане като технически дълг или ново изискване.

Тези промени, взети от екипа на програмата, се изграждат, тестват и автоматично се внедряват в производството, заедно с автоматизирания конвейер за доставка. Но всяка промяна се регистрира в контрола на версиите и тези промени се одитират и тестват по целия конвейер за доставка.

И така, каквито и промени да са направени от екипа, те се записват в инструмента за контрол на версиите и какво успешно е внедрено в средите и техните конфигурации са налични в инструмента за конфигуриране.

Следователно, както контролът на версиите, така и управлението на конфигурацията ни дават ясна картина на това, което се пуска, кога е пуснато, къде е пуснато и как е пуснато.

Така че, в контекста на DevOps, основно управлението на версиите и управлението на конфигурацията действат като инструмент за управление на изданията. И така, тези два процеса и инструмента действат като CCB, който ние наричаме в нашия традиционен метод за развитие.

По принцип тя автоматизира работата на мениджър на ЦКБ, който в идеалния случай проверява всяка от тези промени или освобождава и удостоверява, че ще я пусне в производство.

В случай на DevOps, не изданието се сертифицира, а целият тръбопровод за доставка се сертифицира по автоматизиран начин, заедно с ръчните порти.

Тъй като такова управление на издания не е отделна дейност като част от DevOps, но е вградено вече като част от тръбопровода или доставката на DevOps заедно с контрола на версиите, управлението на конфигурацията и конвейера за внедряване.

И така, контролът на версиите, когато е свързан заедно с управлението на конфигурацията, прави управлението на изданията.

И докато преминаваме към практиката на DevOps, където се стремим да извършваме доставки за период от няколко часа, практически е невъзможно да се управляват толкова чести внедрявания и неговото записване и поддръжка ръчно чрез традиционните процеси за управление на освобождаването, където те се управляват ръчно с автоматизация в много малка степен.

И така, пълната автоматизация на процеса на управление на изданията е задължителна.

Също така, в тръбопровода DevOps, не е необходимо да контролираме внедряванията, ако промените бъдат одобрени, изградени, тествани и влязат в контрола на версиите, те автоматично се прилагат към производството. Разбира се, функциите за превключване са включени или изключени, за да ги контролират в производството.

Одитът и проследимостта на всяка промяна са едни от най-силните предимства, които имаме от гледна точка на управлението на изданията. Така че, когато изграждаме тръбопровода DevOps или тръбопровода за доставка, ние изграждаме това регистриране и одит в тръбопровода, така че събития в реално време в околната среда да се записват и одитират.

И така, ще получим действителните събития, които се появяват поради действието на внедряване на приложението в околната среда. Като по-кратко и по-малко освобождаване, е доста лесно да се проследят тези промени по целия конвейер.

Стигнахме до частта Инструменти на управлението на изданията.

Инструментите за управление на изданията, които се предлагат на пазара, гарантират, че автоматичното внедряване на промените е навременно и без грешки и са насочени към предоставяне на максимална стойност на потребителите.

По принцип те са инструментите за внедряване, които се използват в тръбопровода за доставка по време на автоматизираното внедряване.

XL Release е един такъв инструмент за управление на освобождаването, който е специфичен за непрекъснатото внедряване. Както казах по-рано, тези инструменти помагат на екипите на DevOps да проектират своя модел за внедряване и помагат при наблюдението на изданията, като автоматизират всички задачи, свързани с разполагането и управлението на изданията.

Plutora е друг такъв надежден инструмент, който предоставя набор от софтуерни инструменти за управление на корпоративни ИТ издания при поискване, който помага при доставянето на изданията.

Продуктът за управление на жизнения цикъл на изданието на BMC Software също е инструмент за управление на изданията от BMC Software, който осигурява цялостна видимост на напредъка на изданието на софтуера. Изглежда, чрез централен уеб-базиран портал, потребителите могат да проследяват разработването на приложения, QA и производството, за да наблюдават последиците от всяка направена промяна.

Има още един инструмент от XebiaLabs. Този инструмент позволява да се планират, автоматизират и анализират конвейерите за техните версии на софтуера.

Нека изброим предимствата на автоматизираната система за управление на освобождаването на DevOps.

На първо място, всички автоматизирани процеси за управление на изданията, които се автоматизират, помагат на екипа да извършва по-бързи и последователни доставки до клиентите.

Научихме, че когато всяко издание или промяна се прокара през непрекъснат конвейер за доставка в средата на DevOps, всяка информация за това, което всъщност се е случило в околната среда, ще бъде ясно записана в дневниците.

И така, ще имаме действителни неща или събития в реално време, които са записани в дневника, като това, което се е случило по време на действителното внедряване на изданието в определена среда.

И така, с това имаме много силен одит и проследимост на промените, поддържани в DevOps.

По всяко време всеки, който прави някакви промени в която и да е част от тръбопровода за доставка, ще бъде проследен.

Ще имаме в контрола на версиите какво е променено, какво е внедрено и съответните му конфигурации. Така че, това осигурява ясна видимост на подробностите за това, какво е доставено, къде е доставено, кога и как, в случай на всяко издание.

Автоматизацията на тръбопровода за освобождаване е друга чудесна характеристика на DevOps, която предотвратява ръчната намеса, доколкото е възможно, и също така е много лесно да се проследи обратно в случай на неуспехи на освобождаването, чрез сравняване на неуспешното издание с успешното издание.

И така, автоматизацията на тръбопровода за освобождаване ни осигурява по-високо качество на доставката в рамките на минути. Правят се човешки грешки, последователност и очевидно по-голяма увереност в доставките.

Това също така дава възможност на екипа да усети, че внедряването или „пускането в производство“ като рутинен или ежедневен график, като ги кара да разберат цялостно тръбопровода за освобождаване и неговите внедрявания.

Без съмнение този комфорт и спестяване на време позволява на хората да се фокусират повече върху другите важни неща, отколкото върху рутинните неща.

Знаем по-рано, изданията се случваха след часове или ранни часове и обикновено през почивните дни. И от екипа се изискваше да подкрепи тези издания в тези срокове.

Помислете за всички стресиращи моменти преди освобождаването, които биха се случили, да сте будни след часове или рано сутринта, за да извършите разполагането, да завършите с извършване на човешки грешки, да забравите да направите промяна и след това да се молите на Бог да направи изданието успешно и така нататък.

Така че сегашният метод на DevOps за внедряване и управление на освобождаването постави завеса за всички наши по-ранни проблеми на стресиращи моменти.

отпечатване на масив в обратен ред

Няма повече разполагания през уикенда, няма повече безсънни нощи и повече стрес при внедряване. Всичко е автоматизирано. Така че пускането на нови функции или актуализирането на промените вече не е стресираща дейност.

Методът за внедряване на DevOps включва, без прекъсвания или всякакъв вид прекъсвания на потребителите, в сравнение с по-ранния случай на изпращане на досадни съобщения за престой на всички клиенти и искане от тях да спрат да използват услугата или да им правят внезапни изненади с възникналите неочаквани проблеми по време на надстройката и допълнително удължаване на престоя.

Нелепо !! Защо трябва да се притесняват от надстройките на софтуера, които правим, или защо трябва да имат проблеми с тези актуализации?

Не безпокойте потребителите с каквито и да е актуализации, които софтуерният екип прави на сървъра. Следователно начинът на издаване на DevOps е сложил край на всички тези проблеми.

Няма повече внедряване през нощта, няма повече корекции, доставяни на клиентите, и няма повече прекъсване на обслужването.

С това завършваме темата „Управление на изданията в DevOps“.

В нашия предстоящ урок , ще научим повече за Процес на мониторинг на ефективността на приложението в DevOps.

PREV Урок | СЛЕДВАЩ урок

Препоръчително четене

^