Projekti kaitsepiirded: keskkondade loomine
See lühikeste artiklite seeria koosneb mõnest asjast, mida olen õppinud viimastel aastatel meie piirkonnas põhinevate projektide läbiviimisel (eeldusel, et loete seda samast valdkonna osast, mida mina teen 🙂) tööd.
Kui te lihtsalt komistate selle otsa, hõlmab seeria mõningaid projekti jaoks olulisi tegureid :
- Ei tohiks olla " komisjoni kavandamist”. “
- Mitte keegi teine, kelle arendustegevuse põhimeeskond peaks suutma arendust, lavastust ja tootmist pakkuda.
- Tootmisse ei tohiks kirjutada keegi peale arendusmeeskonna (ja isegi siis peaks olema juurutamisprotsess).
Mulle ei meeldi selliste karmide ja kiirete reeglite kehtestamine nimelt seetõttu, et asjad muutuvad ajas kas vajaduse või suurema kogemuse tõttu. See on põhjus, miks mulle meeldivad "juhised".
Kuid selle kirjutamise ajal on need asjad, mida ma näen mängimas.
Keskkondade pakkumine
Viimase paari aasta jooksul oleme teinud palju edusamme selles osas, kui kiiresti suudame oma süsteeme luua nii, et need kõik peegeldaksid üksteist (või üldiselt). See hõlmab meie arenduskaste, seda, kuidas meie kohalikud masinad peegeldavad lavastust ja kuidas lavastus peegeldab tootmist.
Enam-vähem uue keskkonna loomine. Rullige sellega.
See tähendab, et see "töötab minu masinas" peaks tegelikult tõsi olema. Ei ole vabandus, miks ei saa viga paljundada.
Ja kui see on tõsi, on see tõenäoliselt tõsi ka teiste masinate, lavastuse ja tootmise puhul. Ja see on tore, eks? See tähendab, et me keerutame oma kaste, juurutame oma skripte või teeme seda, mida teeme, ja siis on meil vajalik seadistus.
Mida siis tähendab keskkondade varustamine? See sõltub sellest, millisele keskkonnale viitate.
Kuidas see tegelikult välja näeb?
Kui töötate WordPressis, mida ma eeldan, et seda loete, eeldab see, et kasutate vähemalt veebiserverit, andmebaasi ja PHP-d.
Arenduskeskkond võib välja näha järgmine:
- Nginxi apache, _
- MySQL, mis on kõige levinum,
- Vähemalt PHP 5.2.4 (soovitatav PHP 7.1),
- Või midagi võrreldavat.
Võite kasutada ka midagi nagu Laravel Valet või midagi nagu VVV. Kõik sõltub teie töö iseloomust.
Lisaks võib teie ettevõtte olemusest olenevalt teatud reeglite jõustamiseks olla teile määratud IDE koos erinevate konfiguratsioonifailidega .
Ja ülejäänud keskkonnad?
Nagu tavaliselt:
- arendus viitab seadistusele teie kohalikus masinas,
- lavastus viitab valdkonnale, kus teie ja sidusrühmad saate testida,
- ja tootmine on koht, kus rakendus asub.
Kuid see näeb välja ka erinev olenevalt sellest, kus te töötate, kuidas teie töö on korraldatud ja nii edasi. Asi pole niivõrd selles, kuidas seda kasutatakse, vaid selles, et seda kasutatakse.
Lavastus
See on tavaliselt ette nähtud serveris (või serverite rühmas, olenevalt projekti suurusest), kuhu saate testimiseks juurutada oma uusima koodi. See võib hõlmata osalist funktsionaalsust, testandmeid ja ainult tootmisest pärineva teabe alamhulka (kui otsustate selle teabe, nimelt andmebaasi tootmiskeskkonnast tõmmata).
See annab teile ja teistele sidusrühmadele võimaluse vaadata, mis toimub ja kuidas see tootmises toimib, ilma et peaksite kartma millegi tundliku hävitamise pärast.
Kood juurutatakse tavaliselt teie Giti hoidlast (kui te seda kasutate) harust, tavaliselt põhivarast. Ja selliseid tööriistu nagu DeployBot, CircleCI, Travis CI, GrumPHP, Behat jne kasutatakse ka nii koodi kvaliteedi hindamiseks, automaattestide käivitamiseks kui ka lõpuks koodi juurutamiseks.
Lõpuks luuakse iga keskkond nii, et neid saab kiiresti peegeldada kohalikes masinates, lavastusserverites ja tootmisserverites. Lisaks peaks olema lihtne andmeid nende vahel lükata ja tõmmata, et andmetega töötamine oleks lihtne.
Tootmine
Lõpuks seisneb tootmine tegelikult toimivas projektis; See tähendab, et selle server, rakendus ja andmebaas töötavad koos ja kasutajad kasutavad seda.
See tähendab ka seda, et kood on stabiilses kohas. Tõenäoliselt on olemas logimismehhanismid, mis teavitavad arendusmeeskonda kõigist probleemidest. Selles keskkonnas ei tohiks koodi muuta ilma, et see oleks eelnevalt läbinud kvaliteedikontrolli või lavastuse.
Ja protsessid paigas?
Olgu, oletame, et töötate parema termini puudumisel traditsioonilise seadistusega, kus kõik teie juurutused tehakse S/FTP kaudu tootmiskeskkonda (või isegi lavastuskeskkonda). Nii saavad kasutajad faile alla tõmmata, muudatusi teha ja üles tõsta.
See pole hea.
See tähendab, et igaüks, kellel on mandaadid, saab sisse logida, muudatusi teha ja allika juhtimisest, pidevast integreerimisest, kvaliteedi tagamise tööriistadest jne mööda minna ning teha mis tahes muudatusi.
See õõnestab kõiki käivitatud protsesse. See mitte ainult ei lähe mööda standardprotseduurist (mis on loomulikult paigas), vaid lõhub arendaja või arendajate meeskonna masinates oleva koodi peamiselt seetõttu, et tootmises olev ei ole enam sünkroonis koodi hoidla.
Lisaks võib seda koodi levitada filiaalide vahel, mis on veel ühendamata või kasutusele võtmata. See jätab meile mitmesuguseid olukordi, kus arendajad ja kliendid on rikkunud osa ehitusprotsessist ja seega kogu projektist.
Kui on aeg tootmist kontrollida, on see arenduse ja lavastusega sünkroonist väljas ning keegi ei tea, miks. Kui tuleb kasutuselevõtu aeg, kirjutatakse muudatused üle ja vastutavad isikud on kaotanud selle, mida nad arvasid nägevat.
Mida peab meeskond tegema?
Ma ei tea, kas sellele on üks õige vastus, aga mida kauem ma selles valdkonnas töötan, seda enam usun, et kliendile lahenduse loomise eest vastutav ettevõte – või ettevõtted – peaksid omama protsessi lõppu kontrolli all. lõpetama.
- Disainerid vastutavad oma valdkondade haldamise eest kontseptsioonide loomisel, pilkudel, demomallide loomisel ja tagasiside küsimisel,
- Projektijuhid vastutavad osakondadega suhtlemise eest,
- Arendajad vastutavad lahenduse juurutamise ja disainerite töö sidumise eest funktsionaalse taustaga,
- Klient vastutab muudatuste ülevaatamise, tagasiside andmise ja muu ülesande täitmiseks vajaliku teabe edastamise eest.
See tähendab, et kui rääkida domeeni seadistamisest, hostimisest, keskkondadest, versioonikontrollist, ehitusprotsessist ja pidevast integreerimisest ning kõigest muust, mida olen mainimata jätnud, siis see jääb otseselt arendusmeeskonna kanda.
Püsige kaevikutes, püsige sihtmärgil (kuid olge tähelepanelik ümbritsevate suhtes).
Lihtsamalt öeldes ei ole need kliendi kohustused ega peaks olema. Vastutuspiirid tuleks seada, neid säilitada ja austada kõigis meeskondades – mitte ainult arendajate ja klientide või klientide ja disainerite või disainerite ja arendajate ja nii edasi.
Mis järgmiseks?
Järgmises postituses räägin vastutusest, mis on arendajatel (ja teistel sidusrühmadel) koodi keskkondade hooldamisel.
See tähendab, kes peaks mille eest vastutama ja kellel on juurdepääs milliste andmete lugemiseks ja kirjutamiseks ning kuidas see võib lõppkokkuvõttes projekti tulemust mõjutada.