Projektin suojakaiteet: Ympäristöjen tarjoaminen

Tämä lyhyiden artikkelien sarja koostuu muutamista asioista, jotka olen oppinut muutaman viime vuoden aikana ajaessani projekteja alueella, jolla me (olettaen, että luet tätä samalta alalta kuin minä 🙂) työ.

Jos olet vain törmännyt tähän, sarja kattaa joitain projektin kannalta tärkeitä tekijöitä :

1. Ei pitäisi olla " komitean suunnittelemaa”. "
2. Kukaan muu, jonka ydinkehitystiimin pitäisi pystyä tarjoamaan kehitystä, lavastusta ja tuotantoa.
3. Kukaan muu kuin kehitystiimi ei saisi kirjoittaa tuotantoon (ja silloinkin pitäisi olla käyttöönottoprosessi).

En todellakaan pidä tällaisista tiukoista ja nopeista säännöistä, nimittäin koska asiat muuttuvat ajan myötä joko tarpeen tai kokemuksen myötä. Tästä syystä pidän "ohjeista".

Mutta tätä kirjoittaessani nämä ovat asioita, joita näen toimivan.

Ympäristöjen tarjoaminen

Muutaman viime vuoden aikana olemme edistyneet paljon siinä, kuinka nopeasti voimme varustaa järjestelmämme niin, että ne kaikki heijastavat toisiaan (tai yleensä niin). Tämä sisältää kehityslaatikomme, kuinka paikalliset koneemme peilaavat lavastusta ja miten lavastus peilaa tuotantoa.

Uuden ympäristön tarjoaminen, enemmän tai vähemmän. Anna mennä.

Eli jos sen "toimii koneellani" pitäisi todella olla totta. Ei tekosyy sille, ettet pysty toistamaan bugia.

Ja kun se on totta, se on todennäköisesti totta muiden koneissa, näyttämöissä ja tuotannossa. Ja tämä on mukavaa, eikö? Tarkoitan, me pyöritämme laatikoita, otamme käyttöön skriptejä tai teemme mitä teemme, ja sitten meillä on tarvitsemamme asetukset.

Mitä ympäristöjen valmistelussa sitten on? Se riippuu siitä, mihin ympäristöön viittaat.

Miltä tämä todella näyttää?

Jos työskentelet WordPressissä, mitä oletan, jos luet tätä, se olettaa, että käytät vähintään verkkopalvelinta, tietokantaa ja PHP:tä.

Kehitysympäristö voi näyttää tältä:

• Nginxin apache, _
• MySQL, joka on yleisin,
• vähintään PHP 5.2.4 (suositus PHP 7.1),
• Tai jotain vastaavaa.

Saatat myös käyttää jotain, kuten Laravel Valet tai jotain, kuten VVV. Kaikki riippuu työsi luonteesta.

Lisäksi yrityksesi luonteesta riippuen sinulla voi olla IDE, joka on määritetty sinulle yhdessä erilaisten määritystiedostojen kanssa tiettyjen sääntöjen noudattamiseksi.

Ja muut ympäristöt?

Kuten tavallista:

• kehitys tarkoittaa paikallisen koneen asennusta,
• lavastus viittaa alueeseen, jolla sinä ja sidosryhmät voit testata,
• ja tuotanto on siellä, missä sovellus sijaitsee.

Mutta tämä näyttää myös erilaiselta riippuen siitä, missä työskentelet, miten työsi on järjestetty ja niin edelleen. Kyse ei ole niinkään siitä, miten sitä käytetään, vaan siitä, että sitä käytetään.

Lavastus

Tämä on yleensä varattu palvelimelle (tai palvelinryhmälle projektin koosta riippuen), johon voit asentaa uusimman koodisi testausta varten. Se voi sisältää osittaisia ​​toimintoja, testitietoja ja vain osan tuotannosta peräisin olevia tietoja (jos päätät noutaa kyseiset tiedot, nimittäin tietokannan, tuotantoympäristöstä).

Tämä antaa sinulle ja muille sidosryhmille mahdollisuuden tarkastella, mitä tapahtuu ja miten se toimii tuotannossa ilman, että sinun tarvitsee huolehtia arkaluontoisten asioiden tuhoamisesta.

Koodi otetaan yleensä käyttöön haarasta, yleensä pääversiosta, Git-arkistostasi (jos käytät sitä). Ja työkaluja, kuten DeployBot, CircleCI, Travis CI, GrumPHP, Behat jne., käytetään myös koodin laadun arvioimiseen, automaattisen testauksen suorittamiseen ja lopulta koodin käyttöönottoon.

Lopulta jokainen ympäristö varustetaan siten, että ne voidaan nopeasti peilata paikallisten koneiden, välityspalvelimien ja tuotantopalvelimien välillä. Lisäksi datan työntäminen ja vetäminen niiden välillä pitäisi olla helppoa, jotta tietojen kanssa työskentely olisi helppoa.

Tuotanto

Lopuksi tuotannossa on kyse varsinaisesta toimivasta projektista; Tämä tarkoittaa, että palvelin, sovellus ja tietokanta toimivat yhdessä ja käyttäjät käyttävät sitä.

Tämä tarkoittaa myös sitä, että koodi on vakaalla paikalla. Käytössä on todennäköisesti kirjausmekanismeja, jotka ilmoittavat kehitystiimille kaikista ongelmista. Koodia ei saa muuttaa tässä ympäristössä ilman, että se on läpäissyt laadunvarmistuksen tai vaiheistuksen ensin.

Ja prosessit paikallaan?

Okei, oletetaan, että työskentelet paremman termin puutteessa perinteisellä asennuksella, jossa kaikki käyttöönottosi tehdään S/FTP:n kautta tuotantoympäristöön (tai jopa lavastusympäristöön). Tällä tavalla käyttäjät voivat vetää tiedostoja alas, tehdä muutoksia ja nostaa ne takaisin ylös.

Tuo ei ole hyvä.

Tämä tarkoittaa, että kuka tahansa, jolla on valtuustiedot, voi kirjautua sisään, tehdä muutoksia ja ohittaa lähteen hallinnan, jatkuvan integroinnin, laadunvarmistustyökalut ja niin edelleen, tehdä mitä tahansa muutoksia.

Se heikentää kaikkia käyttöönotettuja prosesseja. Tämä ei vain ohita vakiomenettelyä (joka on tietysti syystä), vaan se päätyy rikkomaan koodin, joka kehittäjällä tai kehittäjäryhmällä on koneissaan ensisijaisesti siksi, että tuotannossa oleva sisältö ei ole enää synkronoitu koodin arkisto.

Lisäksi tämä koodi voidaan levittää haarakonttoreille, joita ei vielä yhdistetä tai otetaan käyttöön. Tämä jättää meille erilaisia ​​tilanteita, joissa kehittäjät ja asiakkaat ovat rikkoneet jonkin osan rakennusprosessista ja siten koko projektista.

Kun on aika tarkistaa tuotantoa, se ei ole synkronoitu kehityksen ja lavastuksen kanssa, eikä kukaan tiedä miksi. Kun on aika ottaa käyttöön, muutokset kirjoitetaan päälle, ja vastuulliset ovat menettäneet sen, mitä he luulivat näkevänsä.

Mitä tiimillä on tehtävä?

En tiedä onko tähän olemassa yhtä oikeaa vastausta, mutta mitä pidempään työskentelen tällä alalla, sitä enemmän uskon, että ratkaisun rakentamisesta asiakkaalle vastaavalla yrityksellä – tai yrityksillä – pitäisi hallita prosessia alusta alkaen. Loppuun.

• Suunnittelijat ovat vastuussa omien osa-alueidensa hallinnasta, luovat konsepteja, pilkkaa, luovat esittelymalleja ja pyytävät palautetta,
• Projektipäälliköt vastaavat yhteydenpidosta osastojen kanssa,
• Kehittäjät vastaavat ratkaisun toteuttamisesta ja suunnittelijoiden työn yhdistämisestä toimivaan taustaan,
• Asiakas on vastuussa muutosten tarkistamisesta, palautteen antamisesta ja muiden tehtävän suorittamiseen tarvittavien tietojen toimittamisesta.

Tämä tarkoittaa, että verkkotunnuksen, isännöinnin, ympäristöjen, versionhallinnan, rakennusprosessin ja jatkuvan integroinnin sekä kaiken muun, mitä olen unohtanut mainita, määrittäminen kuuluu suoraan kehitystiimille.

Pysy juoksuhaudoissa, pysy tavoitteessa (mutta muista ympärilläsi olevat).

Yksinkertaisesti sanottuna nämä eivät ole asiakkaan velvollisuuksia, eikä niiden pitäisi olla. Vastuurajat tulee asettaa, ylläpitää ja kunnioittaa kaikissa tiimeissä – ei vain kehittäjien ja asiakkaiden tai asiakkaiden ja suunnittelijoiden tai suunnittelijoiden ja kehittäjien ja niin edelleen.

Mitä seuraavaksi?

Seuraavassa viestissä puhun vastuista, jotka kehittäjillä (ja muilla sidosryhmillä) on koodin ympäristöjen ylläpidossa.

Eli kenen pitäisi olla vastuussa mistäkin ja kenellä on oikeus lukea ja kirjoittaa mitä tietoja ja miten se voi lopulta vaikuttaa projektin tulokseen.