Artikolo Programaro Engineering 7 - Kontinua Integriĝo Agordoj Laboro Teamoj farante pli Organizita
Revua artikolo el Programaro Engineering Eldono 07.
Ĉi
tiu artikolo estas parto de la programaro Inĝenierio revuo speciala
eldono 7. Klaku ĉi tie por legi ĉiujn artikolojn en ĉi tiu temo
Projekto
Kontinua Integriĝo iloj fari la laboron pli organizita teamoj
Sciante Backstage
Pluraj
kialoj difini la ĉeesto de grandaj grupoj de programistoj en la sama
teamo por konstruaĵo sistemoj, kiel grandeco, limdato petita de kliento,
ktp. Tiel, la bezono por programistoj kunlabori en organizita maniero ĉeestas en nia ĉiutaga vivo. Pensante pri tio, kiel projekto povas havi teamon organizis dum la sama fontkodo estas dividita? Estas iloj kiuj helpas en tiu procezo? Se estas, kio estus?
Por
respondi tiuj demandojn, ni povas mencii la koncepton de kontinuaj
integriĝo, ofte uzata de lerta procezoj kiel Extreme Programming. La
ĉefa ideo estas integri la laboro farita de pluraj personoj dum
diversaj epokoj de la tago, kaj realigi provoj por certigi ke la kodo
restas kohera al la fino de ĉiu integriĝo.
La
ideala maniero apliki kontinua integriĝo estas per la uzo de diversaj
iloj kiel versio kontrolo (ekz. CVS, Subversion kaj Klara kazo), muntaĵo sistemoj (ekz. Formiko, NAnt kaj Maven), kaj sciigoj al uzantoj de ekzekutoj (ekz. retpoŝto, SMS kaj MSN). Ekzekutoj, ekzemple, verko projektoj nomas Postenoj en pluraj punktoj en la artikolo.
En Figuro 1 ni ilustri arkitekturon kiu reprezentas la ideon de kontinuaj integriĝo. Notu
ke en ĉi tiu ekzemplo havas teamon de tri programistoj fari ŝanĝojn al
sola dosiero aŭ aro de dosieroj, kiuj konsistigas projekto, dividita de
deponejo lokita en alia maŝino. En la ekzemplo, ni konsideras sin ilo por kontinuaj integriĝo instalita sur alian stacio estas uzita. De tie, ni starigis tempo de la tago por kuri la lasta muntaĵo de la projekto sub disvolviĝo. Ankaŭ,
depende de la ilo uzata, oni povas agordi sciigo retpoŝte devus esti
senditaj al la tuta teamo de disvolviĝo asertante ĉu la ekzekuto estis
sukcesa aŭ malsukcesa.
Figuro 1. Kontinua integriĝo arkitekturo reprezenti.
En ĉi papero ni prezentas komenca resumo de sistemoj build kaj versio kontrolo. Tiam
ni prezentas la ĉefajn trajtojn de tri kontinuaj integriĝo iloj: Cruise
Kontrolo, Kontinuaĵa kaj Hudson, kaj la fino de la artikolo estas
komparo inter ili. De ĉi tiu komparo, vi povas identigi kion liaj ĉefaj avantaĝoj kaj malavantaĝoj.
Sistemoj por Konstruu
Konstruu
sistemoj estas uzataj por agilizar kaj aŭtomatigi ekzekuto de projektoj
por aŭtomatigi taskoj, kiel kodo kompilita sistemo; kompilita kaj
ekzekuto de unueco provoj kaj akcepto; raportado de provo, kovrado
analizo kaj statikaj kodo, kaj ajna alia agadoj necesaj. Ekzemploj de iloj uzataj por konstrui hodiaŭ estas: Formiko, Maven 1, Maven 2, NAnt, inter aliaj.
Versio kontrolo sistemo uzas por stoki kaj subteni versiojn de dosieroj, tiel kiel ĉiuj la fontkodon de sistemo. Aka
dosieraro estas respondeca aŭtomatigi taskoj kiel: identigi loka
ŝanĝojn; vidi de la diferencoj inter la kodo de loka dosiero kaj versio
stokitaj en la deponejo; identigi kiu faris apartan ŝanĝo, korpigante
ŝanĝon en loka dosiero al versio de la sama dosiero stokitaj en la
deponejo, sinkronigi la loka kodo kun unu el la versioj de la sistemo aŭ
dosieron stokitaj en la deponejo. Tre iloj uzataj por disvolvi estas: Subversion, CVS, Klara kazo.
Por sukcesi la senjunta integriĝo, gravas uzi version kontrolo sistemo. Se
ekzistas tia sistemo, ĝi fariĝas malfacila por permesi teamoj kun
multnombraj programistoj kunlabori kaj konigi la fontkodon de la sama
projekto.
Imagu du programistoj ŝanĝi la sama dosiero. Du
grandaj maltrankviloj ĉeestus: la unua estas certigi ke ĉiu programisto
konas, ke la sama dosiero estas ŝanĝita de aliaj, dum la dua estus
kompreni kion ŝanĝoj estis faritaj de ĉiu programisto por enigita versio
povas esti generita . De sistemoj kiuj realigas versio kontrolo, tiaj zorgoj povas pli facile sukcesis.
Nenhum comentário:
Postar um comentário