Traditsiooniline arendus/integreerimine/tehnosiirde/tootmise tava tarkvara arendamiseks

Original: https://dltj.org/article/software-development-practice/

Peter MurrayPeter Murray
Raamatukogu tehnoloog, avatud lähtekoodiga advokaat, püüeldes globaalselt mõtlema, tegutsedes kohapeal

 

Mulle paluti hiljuti visandada tarkvaraarenduse struktureeritud protsessi kava, mis maksimeerib tootlikkust ja vähendab kasutajale jõudmist tekitavaid vigu. See oli algselt sisemine OhioLINK-i dokument, kuid kirjeldatud protsess on üsna traditsiooniline ja teised võivad seda kasutada. Olete teretulnud seda kasutama; austage Loominguline Commonsi litsentsitingimusi ja võtke minuga ühendust, kui vajate midagi muud.

Loomine Neli Tasemed

Alustame kõigepealt kirjeldus neljast tasandist tarkvara arengut.

Areng
Valikuline. See on töökeskkonna üksikute arendajate või väikestes rühmades. Töö isolatsioonis ülejäänud astmed, arendaja (d) saab proovida radikaalseid muudatusi kood kahjustamata ülejäänud arendusmeeskond.
Integratsioon
Ühine keskkond, kus kõik arendajad toime koodi muudatusi. Eesmärk on see keskkond on ühendada ja kinnitada töö kogu projekti meeskond nii, et see saab testida enne reklaamitakse Proovikeskkond. On võimalik, et arengu ja integratsiooni olema sama keskkonda (nagu juhul, kui arendaja ei kasuta kohaliku koopia lähtekoodi).
Lavastus
Lavastuses astme on keskkond, mis on identne tootmiseks kui võimalik. Eesmärk proovikeskkonnast on simuleerida nii palju tootmiseks kui võimalik. Proovikeskkond ka topelt nagu demonstreerimine/koolitus keskkond.
Tootmine
Tootmise astme võib hõlmata ühe masina või suur klastri sisaldab palju masinaid.

Need tasemed räägivad pigem “keskkondadest” kui “masinad” või “serverid”. Kindlasti on võimalik, et mitmed arenduskeskkonnad ja integratsioonikeskkond asuvad ühes ja samas füüsilises masinas või integreerimise ja seiskamise keskkonnas ühes masinas. Kui see on üldse võimalik, peaks tootmiskeskkond olema üksi ja mitte üheski teises keskkonnas.

Ressursid igal tasandil

Lavastus

  • Identsed tarkvara konfiguratsiooni tootmise masin ja täielik, sõltumatu koopia tootmise andmebaasi nii, et see on tõsi aluseks QA katsetamine. Kui te kasutate Storage Area Network (SAN) või Network Attached Storage (NAS), võib teil olla võimalik kasutada “Pilt” võimeid mäluseade simuleerida koopia tootmise andmebaas nõudmata kogu eksemplaris koopia andmete (ja vastav riistvara).
  • Võrreldav riistvara konfiguratsiooni tootmise süsteem  nii täpset prognoosi võimsust jõudluskontrolli vastu ja seejärel korrutatakse selle tulemuste mitmeid masinaid, mis võetakse kasutusele tootmiseks.

Integratsioon

  • Piiratud hulgal andmeid, mis on kasulik testimiseks “piiri tingimused” taotluses. See võib olla mõistlik värskendage seda alagrupis andmed sageli eemaldada esemeid tarkvara arendamise ja testimise Integratsiooni keskkond.

Areng

  • Sama piiratud hulga andmete integreerimise keskkonda.

Liikumine kihtide vahel

See graafiline näitab, milline on töö igas keskkonnas, vastutust osalejaid igasse keskkonda ja suhteline tarkvara ehitab ja kasutuselevõttu.

Process for Moving Through Development/Integration/Staging/Production Stages

Jutustavas vormis kirjutab tarkvaraarendaja oma arenduskeskkonnas (1) koodi ja kontrollib seda Subversioni lähtekoodi hoidlas (2). Kuna teised arendajad teatavad veadest (3), on tehtud rohkem muudatusi (5) ja need on märgitud (6). Pidage meeles, et arendus-ja integratsioonikeskkonnad võivad olla samad tegelikud keskkonnad, nii et need kaks kasti võib kokku murda; on siiski oluline märkida, et sellisel juhul muudetakse muudatusi Subversioonis endiselt.

Kui arendajad on integreerimiskeskkonna (6) käitumisega rahul, loob vabastamismeister koodi koopia või märgendi Subversioonis ja värskendab sellele märgendile (7) matkimine-keskkonda. Sellel hetkel alustavad kvaliteedi tagamise (QA) testijad oma kontrolli (8). QA testijad võivad olla nii sisemised töötajad kui ka väliseksperdid; Kui tootmisväljaanne on valmis, siis ka matkimine area kahekordistub koolituskeskkonnana. QA aruanded lähevad tagasi arendajale (9), kes neid parandab (10) ja kontrollib muudatusi Subversionis (11). Kui kõik vead on fikseeritud, reklaamijuht reklaamib lehelt uue versiooni (12).

See protsess jätkub seni, kuni QA meeskond deklareerib, et lavastusviis on “õige vabastamiseks” (13). Väljalaskehaldur pakendab Subversioni versiooni (14) versiooni ja levitab selle tootmisserveritesse (15). Kui aeg läheb edasi, tehakse vigade aruanded ja funktsiooninõuded (16), mille puhul arendaja kirjutab koodi (17) ja kontrollib lähtekoodi hoidla muudatusi (18). (17) ja (18) on funktsionaalselt samaväärsed ülaltoodud punktidega ”(1)” ja ”(2)”. Korda, kuni lõppkasutaja on täiesti rahul.

Olulised märkused

Arendajad muuta ainult arengut ja integratsiooni keskkondades. Kui vigu parandada tehakse, arendaja teeb seda Subversionist Integratsiooni etapis. Selleks, et säilitada terviklikkust lähtekoodi hoidla  kordagi ei arendaja muudatusi teha otse Lavastus või tootmine keskkondades.

Iga lähetuse tootmine on mitu versiooni lavastada ja iga kasutuselevõtu arvesse Hoiu on mitu versiooni Areng/Integratsiooni. Autor disain, lõppkasutajate eraldatakse kiire ja mõnikord lollakas väljatöötamisel tarkvara. Eeldatakse, et enamik vigu on püütud varem ja korduva versioonid algstaadiumis täita leida vead kiiremini.

Ainult “release manager” saab versioone järgmisele etapile installida. Integreerumisest-asetundlikkusesse ja tootmisesse jõudmiseni jõudmiseks võib kasutada mitmesuguseid väljaandmisjuhiseid; vabastamise haldur võib isegi muuta versiooni versioonist. Loomulikult võib mõnes projektis olla arendaja, pressiteadete juhataja ja kvaliteedikontrolli tester tegelikult üks ja sama isik. Siiski on oluline, et uue versiooni kasutuselevõtmise eest vastutab alati ainult üks isik.

Kuigi vertikaalne kastid graafiline tähenda Integratsiooni keskkond on välja lülitatud etapis “(7)”, tegelikult versiooni tarkvara integratsiooni keskkonna kunagi kaob. Selle asemel  versiooni tarkvara, mis on edutatud vaheetappide keskkondi “tagged” off “pagasiruumi” lähtekoodi hoidla  ja see on märgistatud versioon, mis on kopeeritud Hoiu. Töö arendajad siis jätkub “pagasiruumi”. Sama kehtib edendamiseks peatuspaigas versiooni tootmiseks.

Kodeerimise standardid

Rakenduste edastamise hõlbustamiseks arendusserverilt tootmis-ja esitusviisi kaudu peaks kood olema serverist sõltuvate muutujateta.

  • Vajadusel määrata hostname programatically määramise asemel seda selgesõnaliselt kood või konfiguratsiooni. Võib kasutada kas javax.servlet.ServletRequest.getServerName või javax.servlet.ServletRequest.getLocalName teha kindlaks seda Servlet.
  • Et tagada kood on kaasaskantav kogu failisüsteemi kasutada suhtelise teede nimede kood ja vajadusel kogumi baaskataloogi taotluses konfiguratsiooni. See võimaldab rakenduste ja skriptide liigutada ühest kataloogist arengu masin teise kataloogi (võimalik teist teed) tootmise masin.