Software Development Practice

Tradičný

Rozvoj/Integrácia/Réžia/Produkcia Praxe pre Vývoj Softvéru

Uverejené December 4, 2006

Tento príspevok bol uverejnený v Raw Technology a pridaný open sourceprogramované Peterom Murray. Bookmark permalink.

Prednedávnom som bol požiadaný, aby som načrtol štrukturovaný proces pre vývoj softvéru, ktorý zvyšuje produktivitu a redukuje výsky porúch, ktoré napádajú užívateľov. Pôvodne išlo o interný OhioLINK dokument, ale opísaný proces je dosť tradičný a ostatní by ho tiež mohli využiť. Ste vítaní ho využiť; prosím, rešpektujte podmienky licencie Creative Commons a vopred ma kontaktujte, ak potrebujete niečo iné.

Description: OTE!  Tento príspevok preložila do srbsko-chorvátskeho jazyka Anja Skrba z Webhostinggeeks.com.

Vyváranie Aplikácii v 4 stupňoch

Najprv začnime s popisom štyroch stupňov vývoja softvéru.

Vývoj

Voliteľný. Toto je pracovné prostredie pre individuálnych vývojárov alebo malé tímy. Pracovaním izolovanie od zvyšku stupňov sa môže vývojár(i) pokúsiť o radikálne zmeny kódu bez nepriazninvého vplyvu na zvyšok vývojarského tímu.

Integrácia

Bežné prostredie, kde všetci vývojari prispievajú k zmenám kódov. Cieľom tohto prostredia je kombinovať a potvrdiť prácu celého projektového tímu, čím môže byť najprv testovaná pred tým, ako ju predstavia Réžijnému Prostrediu. Je možné, aby Vývoj a Integrácia boli jedno oddelenie (ako napríklad, keď vývojar nevyužíva miestne kópie zdrojového kódu).

Réžia

Toto je prostredie je identické produkčnému prostrediu najviac, ako je to možné. Význam Réžijného prostredia je simulovať čo najviac simulovať Produkčné prostredie. Réžijné prostredie sa môže zduplikovať tiež ako Demonstračné/Tréningoví prostredie.

Produkcia

Produkčný stupeň môže zahŕňať buď jeden stroj, alebo veľký zhluk zahŕňajúci veľa strojov.

Tieto stupňe rozprávajú radšej o ,,prostrediach” ako o ,,strojoch” alebo o ,,serveroch”. Určite je možné, aby niekoľkonásobné Vývojové prostredia a Integračné prostredia fyzicky boli na jednom stroji, alebo aby boli na jednom stroji Integračné a Réžijné prostredia. Ak je to možné, potom Produkčné prostredie by malo byť samostatne a nezdieľané so žiadnym dˇalšími prostrediami.

 

Zdroje na Každom Stupni

režia

§  Identická konfigurácia softvéru ako u produkčnom úplná, nezávislá kópia produkčnej databázy, takže ide o skutočnú základňu pre QA tesotvanie. Ak používate Storage Area Network (SAN) alebo Network Attached Storage (NAS), mali by ste byť schopní použiť “snapshot” schopnosti ukladacieho zariadenia na simultáciu kópie produkčnej databázy bez vyžadovania celej zduplikovanej kópie dát (a zodpovedajúceho hardvéru).

§  Konfigurácia hardvéru porovnateľná s produkčným systémom, čiže presná prognóza kapacity podľa testovania výkonu proti nemu, a potom vynásobenie jeho výkonu počtom strojov, ktoré budú nasadené do výroby.

INTEGRácia

§  Limitovaný podsúbor dát, ktorý je užitočný na testovanie ,,hraničných podmienok“ v aplikácii.  subset of data that is useful for testing “boundary conditions” in the application. Mohlo by byť rozumné obnovovať tento podsúbor dát pravidelne, aby sa odstránili artefakty softvérového vývoja a testovania na Integračnom prostredí.

vývoj

§  Ten istý limitovaný podsúbor dát ako pri Integračnom prostredí.

Pohyb Medzi Stupňami

Toto grafické znázornenie zobrazuje charakter práce predvedenej v každom prostredí, zodpovedností hercov v každom prostredí a relatívnu rýchlosť budovania a nasadenia softvéru.

Jednoducho povedané, softvérový vývojár napíše kod v jeho vývojárskom prostredí (1) a skontroluje ho v úložisku pre Podverziu zdroja kodu (2). Ak dˇalší vývojári reportujú chyby, spraví sa viac zmiena (5) a kontrol (6). Zapamätajte si, že Vývojové a Integračné prostredia môže predstavovať to isté jedno prostredie, takže tieto dva rámčeky možu zaniknúť; je dôležité poznamenať, ale, že takýto prípad zmien je stále kontrolovaný v Podverzii.

Ak sú vývojári spokojní so správaním sa Integračného prostredia (6),  hen the developers are happy with the behavior of the Integration environment (6), Master pre Spustenie vytvorí kopiu alebo ,,štítok” kodu v Podverzii a aktualizuje Réžijné prostredie na tento ,,štítok” (7). V tomto momente testovači zabezpečenia kvality (QA) začínajú spätné preskúmanie (8). (QA) testovači môžu byť budˇ interní zamestnanci alebo externí kontrolori; Réžijná oblast takisto duplikuje ako tréningové prostredie, akonáhle je Produksia pripravená. QA reportuje späť vývojárovi (9), ktorý ich opraví (10) a implementuje zmeny to Podverzie (11). Po tom, ako sú všetky poruchy napravené, manažér vydania predstaví réžií novú verziu (12).

Tento process sa opakuje, až kých QA tím zdeklaruje, že réžijná verzia je ,,okay pre zverejnenie” (13). Manažér vydania vybalí verziu vydania z Podverzie (14) a nasadí ju na produkčné servery (15). Časom sú vytvorené reporty pre poruchy a budúce požiadavky (16), pre ktoré vývojár napíše kod a (17) zaregistruje zmeny do úložiska zdroju kodov (18)(17) a (18) sa funkčne rovnajú ”(1)” a ”(2)” uvedené vyššie. Opakujte, až kým je konečný používateľ úplne spokojný.

dôležité poznámky

Vývojári robia zmeny len vo Vývojovom a Integračnom prostredí. Ak je potrebné napraviť poruchu, vývojár tak urobí v Podverzii v Integračnej fáze. V záujme zachovania integrity úložiska zdrojového kodu, vývojár neurobí zmeny v žiadnom bote procesu priamo v Réžijnom alebo Produkčnom prostredí.

Pre každé nasadenie do Produkcie existuje niekoľko verzií v Réžii and re každé nasadenie do Réžie je niekoľko verzií vo Vývoji/Integrácii. Počas dizajnu sú koneční užívatelia uchránení od rýchleho a príležitostného procesu nápravy porúch pri vývoji softvéru. Predpokladá sa, že najviac porúch bude zachytených vpredstihu a opakované verzie v počiatočných fázach nájdu poruchy rýchlejšie.  

Iba ,,manažér vydania” môže nasadiť verziu do ďalšej fázy. Prítomní môžu byť viacerí manažéri vydania pre nasadzovanie z Integrácie-do-Réžie a Réžie-do-Produkcie; manažér vydania môže dokonca meniť verzie. Samozrejme, pri niektorých projektoch vývojár, manažér vydania a QA testovací pracovník môžu byť tá istá osoba. Dôležité, ale, je, že len jedna osoba je zodpovedná za nasadenie novej verzie.  

Hoci zvislé rámčeky v grafike znázorňujú, že Integračné prostredie je vypnuté v kroku ”(7)”, v realite verzia sofvtéru Integračného prostredia nikdy nezaniká. Neamiesto toho verzia softvéru, ktorá je povýšená fo Réžijného prostredia, je “oštítkovaná” ako vyhodený z “kufra” v úložisku zdrojového kódu a ide o oštítkovanú verziu, ktorá je skopírovaný do Réžie. Vývojári dˇalej pracujú na ,,kufri”. To isté platí pre povýšenie Réžijnej verzie do produkcie.

 

Kodovacie Štandardizácie

Pre uľahčenie prestupu aplikácií z vývojárského serveru cez réžijný a do produkcie kod by mal byť zbavený akýchkoľvek premien závislých na serveri.

§  Ak je to nevyhnutné, hostname uričte radše programovo ako by ste ho špecifikovali výslovne v kóde alebo v konfigurcii. Môžete použiť buď javax.servlet.ServletRequest.getServerName alebojavax.servlet.ServletRequest.getLocalName pre toto určenie v servlete.

§  Pre ujistenie ja, že kód je prenosný cez súborové systémy, použite relatívne názvové cesty v kóde a ak je nevyhnutné, nastavte základný slovník v konfigurácii aplikácie. Toto umožní aplikáciám a prepisom pohyb z jedného slovníka vo vývojárskom zariadení do iného slovníka (pravdepodobne s rozdielnou cestou) produkčného stroja.