Kuinka käyttää Git-Flowa sulautettujen ohjelmistojen kehittämisessä

Kun puhutaan ketterän kehityksen omaksumisesta, jatkuvasta integroinnista, jatkuvasta toimittamisesta ja DevOps-käytännöistä, asianmukaisen versionhallintajärjestelmän omaaminen ja oikean työnkulun määrittäminen on yksi perusedellytyksiä. Se vie sinut läpi useimpien Dev-Test-Operaation rakennuspalikoiden osien - koodaa, rakenna, testaa ja vapauta. SW-tutkimus- ja kehitysryhmien tutkimukset osoittavat merkittäviä parannuksia, jotka vähentävät uusien ominaisuuksien markkinoille saattamisen aikaa, kun asianmukaiset lähteenhallintakäytännöt pannaan täytäntöön [1].

Nykyään ketterien joukkueiden suosituin versionhallintajärjestelmä on Git, joten tämä blogiviesti keskittyy tiettyyn Git-työnkulkuun, joka sopii sulautettujen ohjelmistojen kehittämiseen.

Git-Flow

kuva otettu - http://nvie.com/posts/a-successful-git-branching-model/

Meille Jumperissa, kokeiltuaan muutaman git-työnkulun, olemme päättäneet työskennellä Git-Flown kanssa Vincent Driessenin ehdotuksen mukaisesti (Jos et tunne Git-Flowa, rohkaisen lukemaan siitä).

Lyhyesti sanottuna Git-Flow on suunniteltu pääosin julkaisun ympärille ja kannattaa työn jakamista kahden päähaaran välillä:

Master: Mikä on tällä hetkellä tuotannossa - vakaa haara.
Kehitä: Seuraava joukko ominaisuuksia, joissa työskentelemme - verenvuotohaara.
Git-Flow puhuu myös harvoista tukialueista ja siitä, kuinka kaikki yhdistyy.

Tämä työnkulku on mielestämme erittäin hyödyllinen sulautettuihin ohjelmistoprojekteihin, vaikka se saattaa tuntua hiukan hankalalta. Web- tai mobiilisovelluksissa et ehkä tarvitse yhtä tai useampaa kehitys-, julkaisu- ja päähaaroista. Sulautettuja ohjelmistoja ei kuitenkaan voida käyttää koko ajan, koska fyysiset laitteet eivät ole aina valmiita päivitykseen. Toinen syy on, että ohjelmistopäivitykset on ehkä varmennettava. Mielestämme pää-, julkaisu- ja kehityshaarat ovat välttämättömiä, kun et käytä koko ajan.

Ajattele mitä tapahtuu, kun löydät virheen tuotannossa, mutta aika valmista asennettavasta paketista todelliseen firmware-päivitykseen kentällä on päiviä tai viikkoja. Tänä aikana kehitysryhmäsi työskentelee seuraavan ominaisuusjoukon parissa. Jos yhdistät suoraan masteriksi, mutta et ole vielä valmis vapauttamaan kaikkia ominaisuuksiasi ja tuotannossa on havaittu virhe - joudut juuttumaan palaamaan tuotannossa olevaan tunnisteeseen, haaraamaan sen, testaamaan ja vapauttamaan haara , ja sulautuvat sitten sisään. Kehityshaaraan tämä ei ole ongelma. Uusia ominaisuuksia kehitetään edelleen. Hotfix-korjaukset haarautuvat masteriksi, ja sulautuvat sitten masteriksi ja kehittävät, kun ne on valmis.

Voinko saada samat edut tunnisteilla?

Git-Flow tarjoaa selkeän eron huolenaiheista uusien ominaisuuksien kehittämisessä, jatkuvassa yleisessä kunnossapidossa, jokaisessa julkaisuikkunassa ja hätähuollossa. Mestari on pyhimpänä pyhää, ja hänen on pysyttävä puhtaassa, toimivassa ja vapautettavassa tilassa jatkuvasti. Tosiaan, voisimme teknisesti saavuttaa saman asian merkitsemällä irrotettavat sitoumukset, mutta erilliset haarat antavat selkeän eron, ja se on hyödyllistä sulautettujen ohjelmistojen kehittämisessä.
On myös hyödyllistä nähdä yhdellä silmäyksellä, mitä olet julkaissut, mitä aiot julkaista ja mitkä ominaisuudet ovat vielä sisällytettävissä mihin tahansa julkaisuun.

Sulautettujen ohjelmistojen kehitysrajoitukset

Sulautettujen järjestelmien ohjelmistojen kehittäminen asettaa rajoituksia, jotka vaikuttavat Git- ja ohjelmistokehitysprosessiin. Mielestämme alla olevat kolme ovat yhteisiä useimmille sulautettujen järjestelmien hankkeille:

  1. Laitteistokonfiguraatio - Projektin elinaikana sinun on tuettava erilaisia ​​laitteistokonfiguraatioita, mikä tarkoittaa, että sinun on ylläpidettävä erilaisia ​​ohjelmistoversioita.
  2. Sertifiointiaika - Sertifiointiprosessi, joka on välttämätön lääketieteen, autoteollisuuden, teollisuuden jne. Käyttöön, vie pitkät testisyklit ennen julkaisua, mikä tarkoittaa, että yhdistäminen masteriksi lykätään.
  3. Automatisoitu testaus - Fyysinen laite tekee automatisoidun testausprosessin kytkemisestä Git-työnkulkuun hankalaksi (opi nämä viisi vaihetta siirryttäessä manuaalisesta automaattiseen testaukseen upotettuna).

Kaikki kolme rajoitusta liittyvät valitsemasi Git-työnkulkuun, mutta kolmas vaatii myös testauskehyksen, jonka avulla voit suorittaa sulautettujen ohjelmistotuotteiden automaattisen testauksen (tarkista testiautomaatio Segger-työkaluilla).

Jos haluat helpon tavan automatisoida fyysisen laitteen sulautettujen ohjelmistojen testaus, sinut kutsutaan kokeilemaan Jumperia. Täältä saat lisätietoja oppimisesta automatisoida rakennusprosessi, joka on olennainen osa testausta.

Laitteiston kokoonpano

Sulautetun tuotteen käyttöiän aikana voi olla erilainen laitteistokonfiguraatio, jota käytetään erityyppisille asiakkaille tai jopa samaan asiakkaalle. Tämä tarkoittaa yleensä sitä, että sinulla on oltava eri versiot näistä alatuotteista, kun käytät samaa arkistoa. Voidaan haluta työskennellä useamman kuin yhden mestarin kanssa ja kehittää sivuliikkeitä, mutta emme suosittele sitä. Yritettäessä ylläpitää eri haarahappoja löydät itsesi luomalla ainutlaatuisen rakenteen, erillisen testauksen, kovien ominaisuuksien yhdistämisen jne. Kaikki tämä johtaa tehokkuuden menetykseen.

Tämän tyyppisissä projekteissa päähaaste on yleensä versioiden välisessä vuorovaikutuksessa ja siitä, kuinka jakaa koodi tehokkaasti niiden välillä, ja Git-Flowa ei suunniteltu ratkaisuksi tähän ongelmaan.

Koska Gitillä ei yleensä ole hopeaa, joka käsittelisi tätä Gitillä, esitetään muutamia lähestymistapoja, joista voit valita.

  1. Jaa koodikanta toisiinsa liittymättömiin kirjastoihin / moduuleihin, jotka tukevat erilaisia ​​kokoonpanoja, hallitse niitä erikseen ja tee sitten kokoonpanon hallinta. Huomaa, että sinun on investoitava asianmukaiseen ohjelmistoarkkitehtuuriin ja abstraktiotasoihin.
  2. Hallitse eri kokoonpanoa ominaisuuslipuilla samoilla oksilla.
  3. Luo eristettyjä ja pitkäikäisiä sivukonttoreita jokaiselle version / laitteiston kokoonpanolle.

Pitkällä aikavälillä suosittelemme kahden ensimmäisen lähestymistavan käyttöä yhdessä. Se myös parantaa koodiasi paljon ja säästää aikaa testaamiseen.

Sertifiointiaika

Tuotteiden, joiden on täytettävä sääntelyvaatimukset, sertifiointiaika voi viedä viikkoja ennen julkaisua. Tänä aikana haluat, että ryhmäsi jatkaa yhdistämistä ja työskentelee seuraavien ominaisuuksien parissa, lisäämättä kohinaa varmenteen julkaisuprosessiin. Tätä varten Git-Flow toimii kuin viehätys.

Automaattinen testaus

Hyvä Git-työnkulku kytkemättä siihen automatisoitua testausprosessia on kuin tehdä vain osa työstä (oppia siirtymään manuaalisesta automaattiseen testaukseen). Sinun on määritettävä prosessi, jossa erityyppisiä testejä suoritetaan eri haaroille, jotta sinulla olisi hyvä kattavuus ja tehokkuus ajoajan testaamisessa. Kun ominaisuus on sitoutunut ja yhdistynyt haaraketjuun - paikallisesta ominaisuushaarasta etärepoon, kehittämiseen, vapauttamiseen ja hallitsemiseen, sinun on lisättävä lisää testejä regressioajon suorittamiseksi loppuun.

Koska jokaisella projektilla on ainutlaatuiset testausvaatimukset ja käytettävissä olevat testausresurssit, hahmotellaan testausvirta, joka saattaa tarvita muutamaa mukautusta projektiisi sopimiseksi. Testausvirta perustuu siihen oletukseen, että voit ainakin suorittaa ei-isäntätestauksen, simuloidun isäntätestauksen ja HiL-testauksen [2].

Huomaa, jos haluat asettaa automaatiojärjestelmäsi johtamaan yhtä testiä kahdesti samalla toimeksiannolla.

Haluatko kokeilla Jumperia?

Jos työskentelet sulautettujen järjestelmien kanssa ja haluat olla helppo tapa testata fyysisen laitteen sulautettuja ohjelmistoja, sinut kutsutaan kokeilemaan Jumperia. Jumper antaa sinun simuloida isäntätestausta koko T & K-syklin tehostamiseksi.

Yhteenveto

Oikean Git-työnkulun omaksuminen on jotain, joka sinun on arvioitava huolellisesti. Täällä ei ole yhtä kokoa, joka sopii kaikille, ja se riippuu ainutlaatuisista tuotteesi vaatimuksista. Toivomme, että ehdotetusta työnkulusta on hyötyä tarpeitasi varten. Kerro meille ajatuksesi ja jaa kanssamme Git-työnkulkuasi.

Linkit

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

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