Fejlesztési környezetek
Minden olyan gyártási folyamat, amely magában foglalja a programok fejlesztését, különböző szakaszok vannak. Nagyjából elmondható, hogy a következőképpen lehetnek képviselve:
- Termelés (fejlesztés)
- gyülekezés
- Ellenőrzés és tesztelés
- Szállítási információ
termelés
Az a hely, ahol ez a folyamat fordul elő, fejlesztési környezetnek nevezik, amely rendszerint helyi. Miért van szükségünk egy különleges névre? Ennek megértéséhez figyelembe kell vennünk a helyzetet. Mindig legalább két környezetünk van. Az egyik a fejlesztési környezet (gyakran fejlesztési környezetnek nevezik), a másik a működési környezet (ahogy ritkán mondják, általában a harci környezet, a termelés). És a kódnak a környezettől függően eltérő módon kell viselkednie.
- A fejlesztési környezetben a naplózás szintje szélesebb, azaz minden hibakeresési üzenetet látunk és segítenek nekünk a fejlesztés során. A gyártás során ez a szint le van tiltva, mert a lemezterület nagyon gyorsan repül.
- A fejlesztési környezetben nem tudunk leveleket küldeni valóra. Ha ez megtörténik, akkor a felhasználók nem lesznek boldogok. By the way, ez gyakran előfordul azokban, akik nem konfigurálják a különböző környezeteket.
- A fejlesztői környezetben a gyorsítótár letiltása (a hozzáférés gyorsításának technikája).
- A fejlesztési környezet nem működési kódot tartalmazhat, és nem egyeztethető (nem koordinált) állapotban van. Ez normális, fejlődünk.
Ezenkívül a fejlesztési környezet kódja általában nem a verzióvezérlő rendszer fő ágában íródott, hanem az ág szolgáltatásban. Ez azért fontos, mert nem akadályozza a gyors szerkesztést, ha valami lebomlik a szerveren, és csak egy kis darabot kell megjavítania, és nem hajlandó új fejlesztéseket készíteni.
Sajnos a php környezetben gyakran találkoznak olyan helyzetekkel, amelyekben a fejlesztés közvetlenül egy harci környezetben történik. Ami nagyon szomorú következményekhez vezet.
Miután végrehajtotta a feladatot (szolgáltatás), és megtörtént, a feladatkód beolvad a fő fiókba, és az úgynevezett integráció bekövetkezik. Ez a név annak a ténynek köszönhető, hogy talán ezen tulajdonság mellett egy másik szolgáltatás fejlesztése is párhuzamosan, egy másik fiókban zajlott le, és nem nagy valószínűséggel végezte el a feladatot. És most találkoztak a fő ágazatban, és együtt dolgoznak, vagy sem - ez még mindig látható.
(Ez az elem nagymértékben függ attól, hogy melyik folyamatot választotta az adott csapat).
Ellenőrzés és tesztelés
A tesztelés általában több szakaszból áll. Az első, amelyen konkrétan az Ön sajátos jellemzőjére van szükség, a második pedig, amely ellenőrzi mindazt, ami a következő kiadásba kerül.
Végül is, még ha összegyűjtjük mindent egy ágban (minden funkciót) és ellenőrizzük őket helyi szinten, akkor nem lehet teljesen biztos abban, hogy a csatában, a valódi adatokon minden jól fog működni. Ráadásul valószínűleg van egy menedzser, vagy akár tesztelők, akik szintén szeretnék látni / ellenőrizni, hogy minden rendben van-e. És itt van még egy termelési környezet a jelenetbe, amelyet az integrációs környezetnek (előkészítésnek) neveznek, vagy a színpadon (ahogyan azt mindenki nevezi).
A Staging egy olyan környezet, amelyben egy csekket készítenek a küzdelem előtt. Különlegessége, hogy ez a lehető legközelebb áll a harci környezet körülményeihez, ami lehetővé teszi, hogy jobban teszteljük, mi történik. Általában ez a hely, ahol a menedzserek, tesztelők és az ügyfelek megyek. Gyakran előfordul, hogy az állomás két feladatot végez egyszerre. Mind a fejlesztők sajátosságainak ellenőrzése, mind az alkalmazás végső futtatása a kiadás előtt.
Itt van még egy új szó: "release". A kiadást más módon "felszabadításnak" hívják. Ez egyrészt a rendszer új verziójának a csatába való beindítása. Másrészt ez néha úgynevezett gyülekezés, ami a rendszer új verziója.
Folyamatos integrációs szerver
Egy ilyen rendszer lehetővé teszi, hogy nagyban felgyorsítsa az integrációs folyamatot. A fejlesztők terhelése nagymértékben csökken, és a rendszer automatizált. A fejlesztőnek be kell írnia a kódot, és el kell küldenie az adattárba, és a rendszer elvégzi a szükséges ellenőrzéseket és összeolvad. A folyamatos integráció része az "Extreme Programming (XP)" nevű gyakorlatnak.
Hiányzott egy fontos pont. Hogyan fejeződik be az új kód az előkészítéshez és a gyártási környezethez a fejlesztés befejezése után? És ő teszi ezt a folyamatot, amelyet a köznépen "telepítésnek" neveznek.
Ahogy a gyakorlat azt mutatja, sokan még mindig a kezeknél vannak. Menj a szerverre (és ha sokan vannak?) Klónozzák a kódot, megváltoztatják a kezüket és így tovább.
Végtelenül megbeszélheti, milyen rossz. Attól a ténytől kezdve, hogy valójában nincs megalapozott, megismételhető folyamat, ami azt jelenti, hogy mindig van esély arra, hogy az emberi tényező megtörik és véletlenül valamit elfelejtenek / elvesznek / törlődnek. Miután befejeződik az a tény, hogy a tudást egy fejben tárolják, és a kibocsátás folyamata voodoo eljárássá válik, amelyet csak Vasya tehet, és néha betegedik, megy nyaralni és kilép. Gyakran ilyen társaságokban a kiadás rendkívül fájdalmas eljárás, amely nem egy órát, de talán még néhány napot is igénybe vehet.
Megalapozott eljárással a kiadás tíz percet vesz igénybe, és bármely fejlesztő bármikor (szinte) készíthető. A heklet általában napi 5-10 alkalommal vesz igénybe.
A legfontosabb feladatok, amelyekkel a debot alatt találkozhatunk:
- Vegye le a kód egy új verzióját a tárolóból, és töltse ki a kiszolgáló (k)
- Végezze el az összes szükséges előkészületet: görgesse át a költöztetést, gyűjtsön parancsfájlokat stb.
- Kapcsolja át a projektet új verzióra
- Visszatekintés hibák esetén
Ossza meg a Facebook-on