Füstvizsgálat a napi termék összeszereléséhez

Az egyik jelentős kockázatokkal szembesül a fejlesztő csapat, hogy a fejlesztők dolgoznak a kódot külön egymástól függetlenül, ami egy komplex program nem a várt módon működik az összeállítás a felhalmozott kódot. Attól függően, hogy amikor kiderült, összeférhetetlensége a program- hibakeresés tovább tarthat, mint a korábbi integrációhoz, különösen abban az esetben, változások a felületen vagy végrehajtása után a súlyos változathoz fő részei a programnak.

Ha egyszerű számítógépes programot szeretne létrehozni, amely egy fájlt tartalmaz, csak összegyűjteni és linkelni kell az összes fájlt, amelyet ezzel a fájllal írtak. A leggyakoribb projekt, amely a fejlesztők csoportja, több száz, akár több ezer fájlt is tartalmaz. Ez "hozzájárul" ahhoz a tényhez, hogy a végrehajtható program létrehozásának folyamata bonyolultabbá és időigényesebbé válik: össze kell állítania a programot különböző összetevőkből.

A Microsoftban és más szoftverfejlesztésben részt vevő vállalatoknál alkalmazott gyakorlat a program napi összeszerelése (összeállítása), amelyet kiegészít a füstvizsgálat is. Minden nap, amikor minden akta (sbildovan épült), csatlakozik (kapcsolódik), és integrálni kell a végrehajtható program, a program maga ki van téve egy viszonylag egyszerű vizsgálatsorozat, amelynek célja az, hogy ha a program során „dohányzik” munkát. Ezeket a teszteket füstnek hívják (az angol füsttől füsttől). Leggyakrabban ez a folyamat elég jól automatizált (vagy kell).

Előnyeit. Ez az egyszerű folyamat számos jelentős előnnyel jár.

Az integráció veszélyének minimalizálása

A fejlesztõi csapat egyik legjelentõsebb kockázata, hogy a fejlesztõk maguk is együtt dolgoznak a kóddal egymástól függetlenül, aminek következtében az összetett program nem mûködik, ahogyan azt a kód összeszerelésében várták. Attól függően, hogy mikor észlelt egy inkompatibilitást a projektben, a program hibakeresése hosszabb időt vehet igénybe, mint a korábbi integrációnál, különösen akkor, ha a program interfész megváltozik, vagy a program főbb részein végrehajtott jelentős módosítások végrehajtása után kerül sor.

Szélsőséges esetekben az integrációs hibák a projekt törléséhez vezethetnek.

A füstvizsgálatok napi összeszerelése és működtetése lehetővé teszi az integrációs hibák kockázatának csökkentését, időben történő reagálását és megakadályozza azok felhalmozódását.

A rossz minőségű szoftver termékek kockázatának csökkentése

A termék alacsony minősége közvetlenül a hibák és az integrációs problémák függvénye. A füstpróbák minimális készletének napi működése nem ad hibáikat és problémákat, hogy elsőbbséget élvezhessenek a projektnél. Ha egyszer a projektet egy stabil állapotba hozta, akkor mindenkor stabil marad. Ezzel soha nem engedheti meg, hogy a minőség csökkenjen a hibák szintjéig.

Segítség a hibák diagnosztizálásában

Ha egy napon a termék nem felel meg (hibával összegyűjtött), akkor a napi összeszerelés és a füstpróbák futtatása sokkal könnyebb megtalálni a probléma okait. A mûködõ termék tegnap, és nem mûködik ma tiszta utalás arra, hogy valami rosszul ment végbe a két szerelvény között.

A morál javítása

Ha a termék működik, és minden nap egyre több és több szerez új tulajdonságokat és funkciókat, a morál a fejlesztők, elméletileg kell nőni, és nem számít, hogy mit is kellene csinálni ezt a terméket. A fejlesztő mindig örömmel figyeli munkás "agyszüleményét", még akkor is, ha a termék téglalapot jelenít meg a képernyőn :)

Napi építések és füstvizsgálatok segítségével

Ennek a folyamatnak az alapelve az egyszerű ötlet a DAILY füstvizsgálatok építéséről és működtetéséről.

Íme néhány részlet ennek az elvnek.

Az alkalmazás napi felépítése

Egyes vállalatoknál a projektet általában nem naponta, hanem hetente egyszer gyűjtik össze. Ez a rendszer téves, mert a projektben "törés" esetén a héten a következő sikeres összeszereléshez néhány hétbe telhet. Ebben az esetben a vállalat elveszíti a napi projektszerelési rendszer minden előnyét.

Sikertelen összeszerelési teszt

A napi projektgyártás esetében azt sugallják, hogy a projektnek működnie kell. Ha azonban a projekt nem működik, akkor a javítás az elsőbbségi feladat.

Minden egyes projektnek megvan a saját szabványa, és annak a jele, amit "összeszerelés közben" lebontottak. Ennek a szabványnak meg kell határoznia a minőségi szintet, amely elegendő a kisebb hibák megfigyeléséhez, és nem hagyja figyelmen kívül azokat a hibákat, amelyek "blokkolják" a projektet.

Egy jó összejövetel az, amelyben legalább:

• az összes fájl, könyvtár és más összetevő sikeresen összeállítva;
• az összes fájlra, könyvtárra és egyéb összetevőkre mutató hivatkozások érvényesek;
• nem tartalmaznak semmilyen stabil rendszert, kizárva az alkalmazás megfelelő működését, hibák blokkolását;
• minden füstvizsgálat elhalad.

Napi füstvizsgálatok

Füstvizsgálatokat kell végezni az egész projekten az elejétől a végéig. Nem feltétlenül teljes körűnek és átfogónak kell lennie, hanem tartalmaznia kell az összes alapvető funkció ellenőrzését. A füstvizsgálatnak elég mélynek kell lennie ahhoz, hogy sikeres áthaladás esetén a projekt stabil legyen és hívható legyen, hogy mélyebb vizsgálatokat hajtson végre.

A napi összeszerelés értelme elveszett füstvizsgálat nélkül. Ez a folyamat védi a termék minőségét, és nem tesz lehetővé integrációs problémákat. Ennek hiányában a napi felépítés időpocsékolás, amelynek célja az összeállítás ellenőrzése.

A füstvizsgálatnak a projekt szintjén kell fejlődnie. Kezdetben a füstvizsgálatok valami egyszerűen ellenőrizni fogják például a projekt "Hello, World!" Üzenetet. A rendszer fejlesztésével a füstpróbák mélyebbé válnak. Az első füstpróbákra fordított idő néhány másodpercen belül kiszámításra kerül, ugyanakkor a rendszer növekedése mellett a füstvizsgálathoz szükséges idő is megnő. A projekt végén a füstvizsgálat órákig tarthat.

Egy szerelőcsoport meghatározása

Adja hozzá a revíziót a szerelvényhez csak akkor, ha értelme van

Általában a fejlesztők egyenként elég lassan írják a kódot, így napi rendszerességgel is érdemes változtatni a rendszeren. A legtöbb kódon dolgozni kell, és néhány naponta integrálni kell a rendszerbe.

Adjon meg egy szisztematikus rendszert, amely megakadályozza a következő szerelvény felszabadulását (a felszabadítás nem működik).

A legtöbb projekt esetében van egy büntetési rendszer, amely megakadályozza egy másik egység felszabadítását. A projekt kezdetén világossá kell tenni, hogy a munkaterv megőrzése a legfontosabb feladat. Egy másik egység kiadásának megzavarása kivétel lehet, de nem szabályként. Ragaszkodjon hozzá, hogy a fejlesztők hagyják el az összes esetet, amíg a rendszer újra nem működik. A szerelés gyakori meghibásodása esetén (a nem működő szerelvény felszabadítása) nehezen tudja visszaállítani a projektet.

A kisebb pénzbírságok hangsúlyozzák a rendszer építési minőségének magas fokú figyelését. Egyes projektek esetében a fejlesztők, akiknek a hibája miatt az összeállítás "esik", adják ki a cukorkát egy nem működő egység felszabadításáért. Az ilyen fejlesztő szekrényének ajtaján egy megfelelő jelet lóg ki, amíg meg nem javítja a szerelvényt (feltéve, hogy a fejlesztők külön irodákkal rendelkeznek :)). Bűnös más projektek fejlesztők viselni mesterséges kecske szarva, vagy hogy egy bizonyos mennyiségű „morál alap” (példák venni a történetek valós cégek).

De egyes projekteknél súlyosabb büntetéseket szabnak ki. Például a Microsoft kiemelkedő fontosságú projektekből álló fejlesztők (Windows NT, Windows 95, Excel) viseltek pagereket, és felismerés esetén munkába kellett mennünk. Még akkor is, ha megbetegedést vagy hibát észleltek 3 órakor.

Gyűjtse össze a rendszert és nyomást gyakoroljon rá

Amikor a projekt kibocsátásának ütemezése növekszik, a rendszer összeszerelése napi ellenőrzésének munkája értelmetlen időpocsékolásnak tűnik. Ez azonban nem így van. A stresszes helyzetekben a fejlesztők gyakran hibákat követnek el. Úgy érzik, hogy a szükségszerűségre nehezedő kihagyni az implementációkat, amelyek a szokásos körülmények között egyszerűen nincsenek jelen. Kipróbálják a kódegység-tesztjeiket sokkal kevésbé gondosan, mint általában. Ilyen helyzetekben a kód az entrópia állapotához sokkal gyorsabb, mint a kevésbé stresszes helyzetekben.

Bármi is legyen, a napi összefogás megerõsíti a fegyelmet, és megtartja az irányítás tendenciáját az entrópia állam irányítása alatt.

Ki profitálhat ebből a folyamatból? Néhány fejlesztő tiltakozik a napi gyülekezetekkel szemben, ezzel indokolja tiltakozásait a szakma gyakorlása és a nagy időbeli költségek miatt. De a legutóbbi időben minden kifinomult rendszert napi összeállításoknak és füstvizsgálatoknak vetettek alá. A kiadás idején a Microsoft Windows NT 3.0 5,6 millió sorot tartalmaz 40 000 fájlban. A teljes összeszerelés 19 órát vett igénybe, és több számítógépen készült el. Ennek ellenére a fejlesztők rendszeresen gyűjtötték a rendszert. Mivel egy profi csapat, az NT fejlesztőcsapata, annak sikere nagyrészt a napi összejövetelnek köszönhető. Azok a fejlesztők, akik kevésbé összetett projekteken dolgoznak, és ezért nem használják ki a napi felépítési folyamatot, gondoljanak arra, hogy felmerülnek bizonyos ésszerű magyarázatok.