Se via kompanio nur enkondukas DevOps aŭ CI/KD-iloj, eble estos utile por vi konatiĝi kun la plej oftaj eraroj por ne ripeti ilin kaj ne paŝi sur alies raketon.
teamo tradukis la artikolon .
Nepreteco ŝanĝi kulturon kaj procezojn
Se vi rigardas la ciklan diagramon , estas klare, ke en DevOps-praktikoj testado estas kontinua agado, fundamenta parto de ĉiu ununura deplojo.
DevOps Senfina Cikla Diagramo
Testado kaj kvalita certigo dum disvolviĝo kaj livero estas esenca parto de ĉio, kion faras programistoj. Ĉi tio postulas pensmanieron por korpigi testadon en ĉiu tasko.
Testado fariĝas parto de la ĉiutaga laboro de ĉiu grupano. La transiro al konstanta testado ne estas facila, vi devas esti preta por ĝi.
Manko de sugestoj
La efikeco de DevOps dependas de konstanta retrosciigo. Daŭra plibonigo estas neebla se mankas loko por kunlaboro kaj komunikado.
Firmaoj, kiuj ne organizas retrospektivajn renkontiĝojn, malfacilas efektivigi kulturon de kontinua retrosciigo en CI/KD. Retrospektivaj renkontiĝoj estas okazigitaj ĉe la fino de ĉiu ripeto, dum kiuj grupanoj diskutas kio iris bone kaj kio iris nebone. Retrospektivaj renkontiĝoj estas la fundamento de Scrum/Agile, sed ili ankaŭ estas necesaj por DevOps.
Ĉi tio estas ĉar retrospektivaj renkontiĝoj ensorbigas la kutimon interŝanĝi reagojn kaj opiniojn. Unu el la plej gravaj punktoj ĉe la komenco estas organizi ripetiĝantajn retroajn renkontiĝojn por ke ili fariĝu kompreneblaj kaj konataj al la tuta teamo.
Kiam temas pri softvarkvalito, ĉiuj teamanoj respondecas pri konservado de ĝi. Ekzemple, programistoj povas skribi unutestojn kaj ankaŭ skribi kodon kun testebleco en menso, helpante redukti riskon de la komenco.
Unu simpla maniero reflekti la ŝanĝon en pensado pri testado estas voki testistojn ne QA, sed softvartestilon aŭ kvalitan inĝenieron. Ĉi tiu ŝanĝo povas ŝajni tro simpla aŭ eĉ stulta. Sed nomi iun "persono pri certigo de programaro" donas la malĝustan ideon pri kiu respondecas pri la kvalito de la produkto. En Agile, CI/CD, kaj DevOps praktikoj, ĉiuj respondecas pri programaro kvalito.
Alia grava punkto estas kompreni, kion signifas kvalito por la tuta teamo kaj ĉiu el ĝiaj membroj, la organizo kaj koncernatoj.
Miskompreno de sceneja kompletigo
Se kvalito estas kontinua kaj ĝenerala procezo, necesas komuna kompreno pri scenkompletigo. Kiel vi scias, kiam etapo estas finita? Kio okazas kiam paŝo estas markita kiel finita sur Trello aŭ alia Kanban-tabulo?
Difino de Farita (DoD) estas potenca ilo en la kunteksto de KD DevOps/CI. Ĝi helpas pli bone kompreni la kvalitajn normojn pri kio kaj kiel la teamo konstruas.
La disvolva teamo devas decidi kion signifas "Farita". Ili devas sidiĝi kaj fari liston de karakterizaĵoj, kiuj devas esti renkontitaj en ĉiu etapo, por ke ĝi estu konsiderata kompleta.
DoD igas la procezon pli travidebla kaj faciligas efektivigi CI/KD se ĝi estas komprenita de ĉiuj grupanoj kaj reciproke interkonsentita.
Manko de realismaj, klare difinitaj celoj
Ĉi tiu estas unu el la plej ofte cititaj konsiloj, sed ĝi devas ripeti. Por sukcesi en iu ajn grava klopodo, inkluzive de CI/KD aŭ DevOps, vi devas fiksi realismajn celojn kaj mezuri rendimenton kontraŭ ili. Kion vi provas atingi per CI/CD? Ĉu ĉi tio permesas pli rapidajn eldonojn kun pli bona kvalito?
Ajnaj celoj fiksitaj devas ne nur esti travideblaj kaj realismaj, sed ankaŭ kongrui kun la nunaj agadoj de la kompanio. Ekzemple, kiom ofte viaj klientoj bezonas novajn diakilojn aŭ versiojn? Ne necesas troŝarĝi procezojn kaj liberigi pli rapide se ne ekzistas plia avantaĝo por uzantoj.
Aldone, vi ne ĉiam bezonas efektivigi ambaŭ KD kaj CI. Ekzemple, tre reguligitaj kompanioj kiel bankoj kaj medicinaj klinikoj povas nur labori kun CI.
CI funkcias kiel bona deirpunkto por iu ajn kompanio efektiviganta DevOps. Kiam ĝi estas efektivigita, la aliroj de firmaoj al softvarlivero signife ŝanĝiĝas. Post kiam CI estas regata, vi povas pensi pri plibonigo de la tuta procezo, pliigo de la rapido de lanĉo kaj aliaj ŝanĝoj.
Por multaj organizoj, CI sole sufiĉas, kaj KD devus esti efektivigita nur se ĝi aldonas valoron.
Manko de taŭgaj paneloj kaj metrikoj
Post kiam vi fiksis viajn celojn, la disvolva teamo povas krei panelon por mezuri KPIojn. Antaŭ ĝia evoluo, indas taksi la parametrojn, kiuj estos monitoritaj.
Malsamaj raportoj kaj aplikoj estas utilaj por malsamaj grupanoj. La Scrum Master pli interesiĝas pri statuso kaj atingo. Dum altranga administrado eble interesiĝas pri la elĉerpiĝo de specialistoj.
Iuj teamoj ankaŭ uzas panelojn kun ruĝaj, flavaj kaj verdaj indikiloj por taksi la staton de CI/CD por kompreni ĉu ili faras ĉion ĝuste aŭ ĉu estas eraro. Ruĝa signifas, ke vi devas atenti tion, kio okazas.
Tamen, se paneloj ne estas normigitaj, ili povas esti misgvidaj. Analizu kiajn datumojn ĉiuj bezonas, kaj poste kreu normigitan priskribon pri tio, kion ĝi signifas. Eltrovu, kio pli sencas por koncernatoj: grafikaĵoj, tekstoj aŭ nombroj.
Neniuj manaj provoj
Testaŭtomatigo metas la fundamenton por bona CI/KD-dukto. Sed aŭtomatigita testado en ĉiuj stadioj ne signifas, ke vi ne devas fari manajn provojn.
Por konstrui efikan CI/KD-dukton, vi ankaŭ bezonas manajn testojn. Ĉiam estos iuj aspektoj de testado, kiuj postulas homan analizon.
Indas konsideri integri manajn testajn klopodojn en vian dukton. Post kiam la mana testado de iuj testaj kazoj estas finita, vi povas pluiri al la deploja fazo.
Ne provu plibonigi testojn
Efika CI/KD-dukto postulas aliron al la ĝustaj iloj, ĉu ĝi testadministrado aŭ integriĝo kaj daŭra monitorado.
Krei fortan, kvalit-orientitan kulturon celas , monitorante klientinteragojn post-deplojo kaj spurante plibonigojn.
Jen kelkaj praktikaj konsiletoj, kiujn vi povas facile efektivigi:
- Certigu, ke viaj testoj estas facile verkeblaj kaj sufiĉe flekseblaj por ne rompiĝi kiam vi refaktorigas la kodon.
- Disvolvaj teamoj devas esti inkluzivitaj en la testan procezon - vidu liston de uzantproblemoj kaj petoj, kiujn gravas provi dum CI-duktoj.
- Vi eble ne havas plenan testan kovradon, sed ĉiam certigu, ke fluoj, kiuj estas gravaj por UX kaj klienta sperto, estas provitaj.
Lasta sed ne laste grava punkto
La transiro al CI/KD estas kutime movita de malsupre supren, sed finfine ĝi estas transformo, kiu postulas gvidan aĉeton, tempon kaj rimedojn de la kompanio. Post ĉio, CI/KD estas aro de kapabloj, procezoj, iloj kaj kultura restrukturado; tiaj ŝanĝoj nur povas esti efektivigitaj sisteme.
Kion alian legi pri la temo:
- .
- .
- .
fonto: www.habr.com