Odabir vlastitog puta uz GitLab
Podijelite na društvenim mrežama
Odabir vlastitog puta uz GitLab
Val Naipaul
23. siječnja 2024.
10 min čitanja
Val Naipaul
23. siječnja 2024.
10 min čitanja
Prijelaz na odjeljak
Prijelaz na odjeljak
Uobičajeni pristupi
Prijedlog pristupa
Zašto se odlučiti za Auto DevOps?
Ako radite na strani platforme i/ili DevOpsa i nađete se u situaciji da trebate napraviti migraciju ili implementirati GitLab (SaaS ili samostalno upravljanje), vjerojatno ćete shvatiti da GitLab ima mnoštvo opcija.
To je uistinu sveobuhvatna platforma koja je svojim temeljnim VCS-om, CI/CD kanalima, upravljanjem paketima, analizom sastava softvera, mogućnostima planiranja i brojnim drugim sadržajima u mogućnosti zadovoljiti sve vaše potrebe.
No, je li za uspjeh potrebno implementirati baš sve njezine značajke? Pogotovo ako GitLab Runners implementiran na cloudu utječe na financije.
U ovom blogu predstavljamo prijedlog pristupa planiranju migracije ili implementacije GitLaba koji dionicima brže donosi vrijednost, a timovima pomaže da se uključe u GitLab pod vlastitim uvjetima, bez potrebe da uvijek rade punom parom.
Uobičajeni pristupi
Prije nego što prijeđemo na naš prijedlog pristupa migraciji ili implementaciji GitLaba, sagledajmo neke uobičajene pristupe od kojih bi možda neki mogli biti prikladniji za vašu situaciju.
Veliki prasak (migracija)
Pristup velikog praska uključuje iteracije analize, konfiguracije, ETL-a i validacije, uz mogućnost upotrebe reprezentativnog izvornog sadržaja u početku te napredak do punog izvornog sadržaja, što kulminira konačnom migracijom u „velikom prasku”.
Glavna je prednost jasna točka prijelaza za sve uključene, no vrijednost se odgađa sve do te točke prijelaza. Ponavljajući karakter ovog pristupa također može dovesti do strukturne neučinkovitosti, u obliku troškova povezanih s iteracijama migracije.
Migracija u fazama
U pristupu podijeljenom na faze izvorni se sadržaj dijeli i migrira u koracima. To se i dalje može učiniti na iterativan način, kao i kod pristupa velikog praska, ali uz lakše upravljanje iteracijama.
U faznom pristupu mogućnosti ciljnog okruženja aktiviraju se u fazama, pri čemu se svaka faza nadovezuje na prethodnu.
Primjenom svakoga od ovih pristupa vrijednost se ostvaruje prije nego kod metode velikog praska, no i izvorne i ciljne platforme aktivne su dulje vrijeme, od prvog koraka ili faze do posljednje, što može predstavljati opterećenje i biti zbunjujuće.
Inženjering platforme sa samostalnom administracijom (migracija/implementacija)
Uz pristup inženjeringa platforme sa samostalnom administracijom tim stručnjaka postavlja temelje (konfiguraciju, automatizaciju, zaštitu) kako bi omogućio razvojnim timovima da iskoriste GitLab, bilo da to uključuje migraciju sadržaja, uvođenje u posao ili pokretanje novih projekata pomoću dopuštenih i odobrenih predložaka.
Iako ovaj pristup može funkcionirati bez okvira za standardizirano iskustvo razvojnih inženjera, odnosno interne platforme za razvojne inženjere (IDP), oslanjajući se na zajedničko znanje i disciplinu tima, najbolji rezultate ostvaruju se upravo s takvim okvirom. Mogućnosti IDP-a uključuju Backstage, Compass, Venue.sh i sami GitLab.
Prijedlog pristupa
Pristup migraciji ili implementaciji GitLaba s testiranjem u ranijim fazama razvoja softvera (eng. shift-left) s naglaskom na vrijednostima
Pristup koji predlažemo daje prioritet isporuci vrijednosti dionicima, a istovremeno ubrzava implementaciju kako bi se osigurala kvalitetna interakcija između korisnika i GitLaba.
Na primjer, ako vaši timovi žele koristiti GitLab Review Apps za suradnju (a možda i da bi se smanjili troškovi infrastrukture), možda je dobro razmotriti integracije vanjskih repozitorija kao prijelazno rješenje prema Review Apps prije potpune migracije Git repozitorija ili čak prije početka migracije!
Iako ubrzavanje implementacije može imati smisla u nekim aspektima, u drugima može biti korisnije usporiti proces, primjerice pri automatskom preslikavanju problema iz postojećeg alata za planiranje u GitLab Team Planning. Time se razvojnim inženjerima omogućava da sami odaberu tempo prebacivanja, uz minimalna ometanja.
Osim toga, iako se obično ne upotrebljava u kontekstu implementacije/migracije platforme, „shift-left” način razmišljanja doista je u središtu ovog pristupa. Time se mogu uzeti u obzir i različiti dionici i ono što ih zabrinjava (npr. troškovi, iskustvo razvojnih inženjera), uz uobičajene probleme koji dolaze s implementacijom/migracijom platforme.
Opća načela
Ovim pristupom najprije je potrebno utvrditi vlastite kriterije za uspjeh s GitLabom, nakon čega se određuju njihovi prioriteti kroz tri atributa:
- važnost/hitnost ili „veličina”
- trošak implementacije
- Angažman korisnika (potreban ljudski kapital, stručnost i predanost)
Daljnjom migracijom ili implementacijom u skladu s utvrđenim prioritetima brže se isporučuje vrijednost dionicima te istovremeno potiče angažman timova u GitLabu.
Utvrdite vlastite kriterije za uspjeh.
Po kojim će se kriterijima mjeriti uspjeh (od strane svih dionika, ne samo od vašeg tima)? Navedite najmanje dva i ne više od pet kriterija.
Vaši kriteriji, poput dobro poznatih DORA metrika, mogu biti povezani s DevOpsom. Ne zaboravite da se radi o vašem okruženju: brine li vas najviše sigurnost i usklađenost? Koliko je važna preciznost i transparentnost u testiranju?
Odredite prioritete kod kriterija za uspjeh i uskladite ih sa značajkama GitLaba
Za svaki kriterij uspješnosti:
- Dodijelite broj koji predstavlja relativnu veličinu, pri čemu je 1 najmanja (važniji/hitniji kriteriji imaju viši prioritet). Ostavite praznine između kriterija kako bi se bolje prikazale relativne vrijednosti, npr. 1, 2, 3, 5, 10.
- Dodijelite broj koji predstavlja relativni trošak implementacije (uključujući alate i procese) za prelazak iz trenutnog u ciljno stanje (s obzirom na kriterij), pri čemu je 1 najviši trošak (kriteriji s nižim troškovima implementacije imaju viši prioritet). Pri određivanju cilja razmišljajte kratkoročno i srednjoročno, no pritom zadržite i razinu ambicioznosti, kako bi ostvarenje tog cilja predstavljalo određeno postignuće.
- Dodijelite broj koji predstavlja relativni angažman korisnika, pri čemu je 1 najmanja vrijednost (kriteriji s najvišim angažmanom zaslužuju viši prioritet). Zapitajte se posjedujete li ljudski kapital, stručnost i predanost potrebnu za uspjeh.
- Sada rangirajte kriterij u odnosu na druge prema njegovoj veličini, troškovima i angažmanu korisnika, tako da viši prioriteti imaju viši broj.
- Utvrdite relevantne značajke GitLaba koje bi vam mogle pomoći (ili otežati) i objasnite na koji način. Na početku je potrebno biti uključiv, a zatim skratiti popis ako je potrebno, po mogućnosti kroz savjetovanje s dionicima.
Kopirano!
Na primjer:
Kriteriji uspješnosti – suradnja
- Veličina – 5
- Trošak – 4
- Angažman – 4
- Vrijednost – 80
Relevantne značajke GitLaba
- InnerSourcing uz minimalnu grupnu hijerarhiju
- Osjetljivi sadržaj premjestite iz repozitorija i aktivirajte Razotkrivanje informacija kao podršku za InnerSourcing (kao i za poboljšanje sigurnosti)
- Tehnike sastavljanja kanala, kao što su ponovna uporaba kanala putem predložaka, CI/CD komponente i CI/CD kataloga
Kriteriji uspješnosti – operativni troškovi
- Veličina – 1
- Trošak – 3
- Angažman – 3
- Vrijednost – 9
Relevantne značajke GitLaba
- Review Apps za kratkotrajna testna okruženja
Kriteriji uspješnosti – operativni troškovi
- Veličina – 3
- Trošak – 1
- Angažman – 1
- Vrijednost – 3
Relevantne značajke GitLaba
Zašto se odlučiti za Auto DevOps?
Ali zašto ne izabrati Auto DevOps? Zar se taj alat ne prilagođava različitim modelima grananja, razvojnim metodologijama i povijesti, odnosno neujednačenom sadržaju? Zar ne bismo mogli preskočiti određivanje prioriteta i sve isporučiti istodobno uz pomoć alata Auto DevOps (ako ostavimo po strani operativne troškove za cloud)?
Ni u kojem slučaju; Auto DevOps (koji je zapravo samo skup odabranih zadataka vezanih uz kanale) dobar je kao model i kao početna točka za DevSecOps, pogodan za prilagodbe te vam može dati ideju za upotrebu vlastitih CI/CD komponenti i CI/CD kataloga, no to nije pravi model nečega, već samo model koji možete iskoristiti za nešto.
Završna misao
Nadamo se da će vam ovaj blog pomoći u pripremi za migraciju ili implementaciju GitLaba, bilo kao SaaS ili za samostalno upravljanje, te pružiti širi pogled na planiranje uspješnog ishoda u vlastitom okruženju.
Uz naš predloženi pristup – određivanje prioriteta kriterija za uspjeh u skladu s njihovom veličinom, troškom implementacije i angažmanom korisnika – GitLab će prije donijeti vrijednost vašim dionicima. Vaši će korisnici uživati u značajnoj interakciji s GitLabom jer će vidjeti da se njihovi problemi rješavaju pri implementaciji.
Kao što smo već spomenuli u uvodu, GitLab ima mnoštvo opcija. Za najbolje rezultate s našim predloženim pristupom migraciji ili implementaciji GitLaba, istražite sve značajke koje on nudi (pritom obratite pozornost na primjenjivi plan pretplate, Premium ili Ultimate). Na taj ćete način vidjeti koje značajke najbolje odgovaraju vašim kriterijima uspješnosti.
Ako želite znati više, obratite nam se!
Napisao/la
Val Naipaul
Glavni savjetnik za DevOps
Val primjenjuje DevOps način razmišljanja na stvarne probleme, razvijajući naše DevOps prakse i razmjenjujući ideje i iskustva s klijentima i partnerima. Val voli poticati inovacije na temelju različitih priča i perspektiva.
DevOps
GitLab