Раней мы аб Continuous Integration (CI). Працягнем з Continuous Delivery. Гэта - збор метадаў распрацоўкі ПЗ. Ён дапамагае пераканацца ў гатоўнасці кода да разгортвання.
/ Pixabay / /
Гісторыя
Словазлучэнне continuous delivery можна было ўбачыць яшчэ ў ад 2001 года ў пачатку спісу асноўных прынцыпаў: "Прыярытэт - рашэнне задач заказчыка з дапамогай бесперапыннай пастаўкі актуальнага ПЗ".
У 2010 годзе Джэз Хамбл (Jez Humble) і Дэвід Фарлі (David Farley) выпусцілі па Continuous Delivery. Па задуме аўтараў, CD дапаўняе падыход і дазваляе спрасціць падрыхтоўку кода да разгортвання.
Пасля публікацыі кнігі падыход пачаў набіраць папулярнасць і ўсяго за некалькі гадоў стаў практычна агульнапрынятым. Згодна , Праведзенаму сярод больш чым 600 распрацоўшчыкаў і ІТ-мэнэджараў у 2014 годзе, 97% тэхнічных кіраўнікоў і 84% праграмістаў былі знаёмыя з Continuous Delivery.
Цяпер гэты падыход застаецца адным з найбольш папулярных. Па дадзеных даследавання 2018 года, да якога прыцягнулі супольнасць IT-спецыялістаў DevOps and Jenkins Community, яго палова з больш за тысячу апытаных рэспандэнтаў.
Як працуе Continuous Delivery
Базіс CD - гатоўнасць кода да разгортвання. Для выканання гэтай задачы выкарыстоўваецца аўтаматызацыя працэсу падрыхтоўкі ПЗ да рэлізу. Ён павінен быць стандартным для розных асяроддзяў распрацоўкі, што дапаможа хутчэй знаходзіць слабыя месцы і аптымізаваць іх. Напрыклад, паскараць тэсціраванне.
Прыклад працэсу Continuous Delivery выглядае наступным чынам:
Калі за аўтаматызацыю першых двух этапаў адказвае падыход Continuous Integration, то за наступныя два - Continuous Delivery. Стабільнасць працэсу забяспечваецца ў тым ліку і за кошт сістэм. . Яны маніторыць змены ў інфраструктуры, базах даных і залежнасцях. Само разгортванне можа быць аўтаматызавана, а можа выконвацца ўручную.
Да працэсу прад'яўляюцца наступныя патрабаванні:
- Даступнасць інфармацыі аб гатоўнасці да выхаду ў production-асяроддзе і гатоўнасць да непасрэднага рэлізу (CD-інструменты тэстуюць код і даюць магчымасць ацаніць эфект ад змен у рэлізе).
- Агульная адказнасць за фінальны прадукт. Каманда прадукта – менеджэры, распрацоўшчыкі, тэсціроўшчыкі – думаюць аб выніку, а не толькі аб сваёй зоне адказнасці (вынік – працоўны рэліз, які даступны для карыстальнікаў прадукту).
У CD звычайна ўжываюць , а для збору меркаванняў кліентаў - прынцып . Новую функцыю спачатку выпускаюць для невялікага сегмента карыстальнікаў – іх вопыт узаемадзеяння з прадуктам дапамагае знайсці недахопы і багі, якія не заўважылі пры ўнутраным тэсціраванні.
У чым выгада
Continuous Delivery дапамагае спрасціць разгортванне кода, што дадатна ўплывае на прадуктыўнасць і змяншае верагоднасць эмацыйнага выгарання супрацоўнікаў. У канчатковым рахунку гэта змяншае і агульныя выдаткі на распрацоўку. Напрыклад, CD дапамог адной з каманд HP такія выдаткі на 40%.
Апроч гэтага — паводле даследавання 2016 года (старонка 28 ) - кампаніі, якія ўкаранілі CD, на 50% хутчэй вырашаюць праблемы з ИБ, у параўнанні з тымі, хто не выкарыстоўваюць падыход. У некаторай ступені такое адрозненне можна растлумачыць працай прылад аўтаматызацыі працэсу.
Яшчэ адзін плюс - паскарэнне выпуску рэлізаў. У фінскай студыі распрацоўкі бесперапынная пастаўка павялічыць хуткасць зборкі кода на 25%.
Патэнцыйныя складанасці
Першая і асноўная праблема - неабходнасць перабудоўваць звыклыя працэсы. Каб паказаць карысць новага падыходу, варта пераходзіць на CD паступова, пачынаючы не з самых працаёмкіх прыкладанняў.
Другая патэнцыйная праблема - вялікая колькасць галін кода. Наступства "разгалінавання" - частыя канфлікты і чарговыя страты вялікай колькасці часу. Магчымае рашэнне - падыход .
У прыватнасці, у некаторых кампаніях асноўныя складанасці ўзнікаюць з тэставаннем - на яго сыходзіць занадта шмат часу. Вынікі тэстаў часцяком даводзіцца аналізаваць уручную, але магчымым рашэннем можа быць распаралельванне тэстаў на першых этапах укаранення CD.
Таксама варта навучыць супрацоўнікаў працы з новымі інструментамі - папярэдні лікбез зэканоміць распрацоўшчыкам сілы і час.
/Flickr/ /
Інструменты
Прывядзем некалькі адкрытых інструментаў для Continuous Delivery:
- - сервер для бесперапыннай пастаўкі на Java і JRuby on Rails. Дазваляе кантраляваць увесь працэс пастаўкі прыкладання: build-test-release. Інструмент распаўсюджваецца па ліцэнзіі Apache 2.0. На афіцыйным сайце можна знайсці .
- - Фрэймворк для стварэння скрыптоў, якія аўтаматызуюць разгортку прыкладанняў на Ruby, Java або PHP. Capistrano здольны выконваць каманды на выдаленай машыне, падлучаючыся да яе па SSH. Працуе з іншымі інструментамі бесперапыннай інтэграцыі і пастаўкі, напрыклад CI-серверам Integrity.
- - мультыплатформавы інструмент, які аўтаматызуе ўвесь цыкл распрацоўкі прыкладанняў. Gradle працуе з Java, Python, C/C++, Scala і інш. Ёсць інтэграцыя з Eclipse, IntelliJ і Jenkins.
- - платформа для CD на мове Go. Drone можна разгарнуць on-premise ці ў воблаку. Інструмент пабудаваны на базе кантэйнераў і выкарыстоўвае YAML-файлы для кіравання імі.
- - платформа для бесперапыннай пастаўкі кода ў мультыхмарных сістэмах. Распрацавана ў Netflix, вялікую ролю ў распрацоўцы інструмента адыгралі інжынеры Google. Інструкцыю па ўстаноўцы вы .
Што пачытаць у нашым карпаратыўным блогу:
Крыніца: habr.com