Kuidas kasutada Git-Flow manustatud tarkvara arendamisel

Agile arenduse kasutuselevõtu, pideva integreerimise, pideva edastamise ja DevOps'i tavade kasutamisel on üks peamisi lahendamist vajavaid asju, milleks on korralik versioonikontrollisüsteem ja õige töövoo seadistamine. See viib teid läbi suurema osa Dev-Test-Operation'i ehitusplokkidest - koodige, ehitage, testige ja vabastage. SW teadus- ja arendustegevuse meeskondade uuringud näitavad olulisi edusamme, vähendades uute funktsioonide turuletoomise aega, kui rakendatakse õiget allikakontrolli tava [1].

Täna on agiilsete meeskondade populaarseim versioonikontrollisüsteem Git, nii et see ajaveebi postitus keskendub konkreetsele Giti töövoole, mis sobib manustatud tarkvara arendamiseks.

Git-Flow

pilt võetud - http://nvie.com/posts/a-successful-git-branching-model/

Meie jaoks, Jumper, otsustasime pärast mõne git-töövoo proovimist teha koostööd Git-Flow'ga, nagu soovitab Vincent Driessen (kui te pole Git-Flow'ga tuttav, julgustan sellest lähemalt lugeda).

Lühidalt - Git-Flow on mõeldud peamiselt väljalaske ümber ja pooldab teie töö jagamist kahe peamise haru vahel:

Meister: Mis on praegu tootmisel - stabiilne haru.
Arendamine: järgmine funktsioonide komplekt, mille kallal töötame - veritsev haru.
Git-Flow räägib ka vähestest toetavatest harudest ja kuidas kõik omavahel seotud on.

See töövoog, kuigi see võib tunduda pisut kohmakas, on meie arvates manustatud tarkvaraprojektide jaoks väga kasulik. Veebi- või mobiilirakenduses ei pruugi te vajada ühte või mitut arendus-, väljalaske- ja peaharu. Manustatud tarkvara ei saa aga kogu aeg juurutada, kuna füüsilised seadmed pole alati värskenduseks valmis. Teine põhjus on see, et tarkvara värskendused peavad olema sertifitseeritud. Leiame, et põhi-, väljalaske- ja arendusharud on hädavajalikud, kui te ei tööta kogu aeg.

Mõelge, mis juhtub, kui leiate tõrke tootmises, kuid aeg valmis juurutatavast paketist kuni tegeliku püsivara värskenduseni väljal on päev või nädal. Selle aja jooksul töötab teie arendusmeeskond järgmise funktsioonide komplekti kallal. Kui liidate otse peamiseks, kuid te pole veel valmis kõiki oma funktsioone vabastama ja viga on tootmises leitud - peate takerduma tagasi tootmises oleva sildi juurde, hargnema sellega, katsetama, vabastama haru ja seejärel ühinemine. Arendusharuga pole see probleem. Uusi funktsioone arendatakse edasi. Kiirparandused hargnevad peamistena ja liidetakse siis põhimeheks ning töötatakse välja pärast valmimist.

Kas ma saan siltidega samu eeliseid?

Git-Flow võimaldab selgelt eristada muret uute funktsioonide arendamise, käimasoleva üldise hoolduse, iga vabastamisakna ja hädaolukorra hoolduse pärast. Meister on pühad pühad ja peab kogu aeg olema puhtas, töötavas ja vabastavas olekus. Muidugi, me saaksime sama asja tehniliselt saavutada ka siis, kui sildistada vabastatavad kohustused, kuid eraldi harud pakuvad selget vahet ja see on manustatud tarkvara arendamisel ületamatu.
Samuti on kasulik vaadata lühidalt, mida olete välja andnud, mida kavatsete välja anda ja millised funktsioonid on igasse väljaandesse veel lisatud.

Manustatud tarkvara arendamise piirangud

Manustatud süsteemide tarkvara arendamine tutvustab piiranguid, mis mõjutavad teie Giti ja tarkvara arendamise töövoogu. Arvame, et järgmised kolm on enamiku manustatud süsteemide projektide jaoks tavalised:

  1. Riistvara konfiguratsioon - projekti eluea jooksul peate toetama erinevaid riistvarakonfiguratsioone, see tähendab, et peate hooldama erinevaid tarkvaraversioone.
  2. Sertifitseerimise aeg - Meditsiini-, autotööstuse, tööstuse jms jaoks vajalik sertifitseerimisprotsess tutvustab enne vabastamist pikki katsetsükleid, mis tähendab, et ühinemine kapteniks lükatakse edasi.
  3. Automatiseeritud testimine - füüsiline seade muudab automatiseeritud testimisprotsessi ühendamise Giti töövoogudeks tülikaks (õppige neid viit sammu manustatud manuaalilt automaatse testimise juurde liikumiseks).

Kõik kolm piirangut on seotud teie valitud Giti töövooga, kuid kolmas eeldab ka testimisraamistikku, mis võimaldab teil manustatud tarkvaratoodete automatiseeritud testimist käivitada (kontrollige Seggeri tööriistade testimise automatiseerimist).

Kui soovite oma füüsilise seadme manustatud tarkvara testimise automatiseerimiseks lihtsat viisi, kutsutakse teid proovima Jumperit. Testimisest olulise osa moodustavate ehitamisprotsesside automatiseerimise õppimiseks lugege siit.

Riistvara konfiguratsioon

Manustatud toote eluea jooksul võib teil olla erinev riistvarakonfiguratsioon, mida kasutatakse erinevat tüüpi klientidele või isegi ühe ja sama kliendi jaoks. Tavaliselt tähendab see, et teil peab sama hoidla kasutamisel olema nende alamtoodete erinevad versioonid. Võib valida, et teeme koostööd rohkem kui ühe meistriga ja arendame filiaale, kuid me ei soovita seda teha. Erinevate harude hooldamisel proovite luua ainulaadseid ehitusi, eraldi testimist, raskete funktsioonide ühendamist jne. See kõik tähendab tõhususe langust.

Seda tüüpi projektide puhul on peamiseks väljakutseks tavaliselt versioonide omavaheline suhtlus ja koodide tõhus jagamine nende vahel ning Git-Flow ei olnud mõeldud selle probleemi lahenduseks.

Kuna Gitil pole selle lahendamiseks üldiselt hõbedast täppi, kirjeldame teile mõnda lähenemisviisi, mille vahel valida.

  1. Jagage koodialus sõltumatuteks teekideks / mooduliteks, mis toetavad erinevaid konfiguratsioone, hallake neid eraldi ja tehke seejärel konfiguratsioonihaldus. Pange tähele, et peate investeerima korrektsesse tarkvaraarhitektuuri ja abstraktsioonide kihtidesse.
  2. Juhtige erinevat konfiguratsiooni samade harude funktsioonilippudega.
  3. Looge versiooni / riistvara konfiguratsiooni jaoks isoleeritud ja pikaealised harud.

Pikas perspektiivis soovitame kasutada kahte esimest lähenemisviisi koos. See muudab teie koodi ka palju paremaks ja säästab teie aega katsetamiseks.

Sertifitseerimise aeg

Toodete puhul, mis peavad vastama regulatiivsetele vajadustele, võib sertifitseerimisaeg kuluda nädalaid enne väljalaset. Selle aja jooksul soovite, et teie meeskond jätkaks ühinemist ja töötaks järgmiste funktsioonidega, samal ajal kui lisate sertifikaadi vabastamise protsessile müra. Git-Flow toimib selle jaoks sarmina.

Automatiseeritud testimine

Hea Giti töövoo omamine ilma automatiseeritud testimisprotsessi sellesse haakimata on nagu ainult osa töö tegemine (õppige, kuidas liikuda manuaalsest testimisest automatiseeritud testimiseni). Peate määratlema protsessi, kus erinevat tüüpi testid toimuvad erinevatel harudel, nii et teil oleks hea käitusaja testimine ja tõhusus. Kuna funktsioon on pühendunud ja ühendatud harude ahelasse - alates lokaalsest funktsiooni harust kuni kaugrepotini, arendamiseks, vabastamiseks ja valdamiseks peate regressioonikäigu lõpuleviimiseks lisama veel teste.

Kuna igal projektil on ainulaadsed testimisnõuded ja saadaolevad testimisressursid, kirjeldame meie testimisvoogu, mis võib teie projekti jaoks vajada väheseid näpunäiteid. Meie testimisvoog põhineb eeldusel, et saate vähemalt läbi viia hostita testimise, simuleeritud hosttesti ja HiL-testimise [2].

Pange tähele, et automaatikahaldur ei peaks sama testi tegema sama ülesannet kaks korda.

Kas soovite proovida Jumperit?

Kui töötate manustatud süsteemidega ja soovite oma füüsilise seadme manustatud tarkvara testimiseks lihtsat viisi, kutsutakse teid proovima Jumperit. Jumper võimaldab teil kogu R&D tsükli hoogustamiseks simuleerida host testimist.

Kokkuvõte

Giti õige töövoo vastuvõtmine on asi, mida peate hoolikalt hindama. Kõigile ei sobi üks suurus, see sõltub teie unikaalsetest tootenõuetest. Loodame, et meie kavandatud töövoog on teie vajadustele kasulik. Andke meile oma mõtetest teada ja jagage meiega oma Giti töövoogu.

Lingid

[1] - https://itrevolution.com/the-amazing-devops-transformatsiooni-of-the-hp-laserjet-firmware-team-gary-gruver/

[2] - https://docs.google.com/spreadsheets/d/1ScSDfn9v73TBaGpuiGfpPTqnBeTvNd22TzApMt_E0qE/edit#gid=0