Vra

Of om eintlik 'n bouproses te vestig wanneer daar nie veel van een in plek is om mee te begin nie.

Tans is dit min of meer die situasie wat my groep in die gesig staar.Ons doen hoofsaaklik webtoepassingsontwikkeling (maar geen rekenaarontwikkeling op die oomblik nie).Sagteware-ontplooiings is lelik en onhandelbaar, selfs met ons beskeie toepassings, en ons het te veel probleme gehad in die twee jaar wat ek deel van hierdie span (en maatskappy) was.Dit is verby tyd om iets daaromtrent te doen, en die gevolg is dat ons twee Joel-toetsvoëls met een klap sal kan doodslaan (daaglikse bouwerk en eenstapbouwerk, wat geeneen in enige vorm hoegenaamd bestaan ​​nie).

Wat ek hier soek, is 'n paar algemene insig oor die soort dinge waaraan ek moet doen of dink, van mense wat al langer as ek in sagteware-ontwikkeling is en ook groter breine het.Ek is vol vertroue dat dit die meeste van die mense sal wees wat tans in die beta plaas.

Relevante gereedskap:Visual Build Source Safe 6.0 (ek weet, maar ek kan niks doen aan die vraag of ons op die oomblik Bron Safe gebruik nie.Dit is dalk die volgende stryd wat ek veg.)

Tentatief het ek 'n Visual Build-projek wat dit doen:

  1. Kry bron en plek in die plaaslike gids, insluitend die nodige DLL's wat nodig is vir die projek.
  2. Kry konfigurasielêers en hernoem soos nodig (ons stoor dit in 'n spesiale subgids wat nie deel van die werklike toepassing is nie, en hulle word volgens gebruik benoem).
  3. Bou met Visual Studio
  4. Stel vooraf saam met die opdragreël en kopieer na wat 'n "bou"-gids sal wees
  5. Kopieer na bestemming.
  6. Kry enige nodige bykomende hulpbronne - meestal dinge soos dokumente, beelde en verslae wat met die projek geassosieer word (en vanaf stap 5 in die gids geplaas word).Daar is baie van hierdie goed, en ek wou dit nie voorheen insluit nie.Ek gaan egter net veranderde items kopieer, so miskien is dit irrelevant.Ek was nie seker of ek regtig hierdie goed by vroeëre stappe wou insluit nie.

Ek moet nog steeds 'n bietjie uitteken by Visual Build vir al hierdie dinge, maar ek is nog nie op 'n punt waar ek dit moet doen nie.

Het iemand enige raad of voorstelle om te maak?Ons gebruik nie tans 'n ontplooiingsprojek nie, ek sal daarop let.Dit sal sommige van die stappe wat nodig is in hierdie bou, vermoed ek, verwyder (soos web.config omruiling).

Was dit nuttig?

Oplossing

As u 'n projek aanpak wat nog nooit 'n outomatiese bouproses gehad het nie, is dit makliker om dit in stappe te neem.Moenie probeer om te veel op een slag te sluk nie, anders kan dit oorweldigend voel.

  1. Kry eers jou kode saamstel met een stap met behulp van 'n outomatiese bouprogram (d.w.s.nant/msbuild).Ek gaan nie debatteer oor watter een beter is nie.Soek een wat vir jou gemaklik voel en gebruik dit.Laat die bouskripte saam met die projek in bronbeheer leef.
  2. Vind uit hoe jy wil hê jou outomatiese bou moet geaktiveer word.Of dit nou is om dit aan CruiseControl te koppel of om 'n nagtelike boutaak uit te voer deur gebruik te maak van geskeduleerde take.CruiseControl of TeamCity is waarskynlik die beste keuse hiervoor, want hulle bevat baie gereedskap wat jy kan gebruik om hierdie stap makliker te maak.CruiseControl is gratis en TeamCity is gratis tot op 'n punt waar jy dalk daarvoor moet betaal, afhangende van hoe groot die projek is.
  3. Ok, teen hierdie punt sal jy redelik gemaklik wees met die gereedskap.Nou is jy gereed om meer take by te voeg gebaseer op wat jy wil doen vir toetsing, ontplooiing, ens.

Hoop dit help.

Ander wenke

Ek het 'n stel Powershell-skrifte wat dit alles vir my doen.

Skripsie 1:Bou - hierdie een is eenvoudig, dit word meestal hanteer deur 'n oproep na msbuild, en dit skep ook my databasis skrifte.

Skripsie 2:Pakket - Hierdie een neem verskeie argumente om 'n vrystelling vir verskeie omgewings te verpak, soos toets, en subsets van die produksie-omgewing, wat uit baie masjiene bestaan.

Skripsie 3:Ontplooi - Dit word op elke individuele masjien uitgevoer vanuit die vouer wat deur die Pakket-skrip geskep is (die Ontplooi-skrip word as deel van die verpakking gekopieer)

Vanuit die ontplooiingskrip doen ek gesonde verstandkontroles op dinge soos die masjiennaam sodat dinge nie per ongeluk op die verkeerde plek ontplooi word nie.

Vir web.config-lêers gebruik ek die 

<appSettings file="Local.config">

funksie om oorskrywings te hê wat reeds op die produksiemasjiene is, en hulle is leesalleen sodat hulle nie per ongeluk oorgeskryf word nie.Die Local.config-lêers is nie ingeboek nie, en ek hoef nie enige lêerwisseling te doen tydens boutyd nie.

[Wysig] Die ekwivalent van appSettings-lêer= vir 'n config-afdeling is configSource="Local.config"

Ons het twee jaar gelede van die gebruik van 'n perl-skrif na MSBuild oorgeskakel en het nie teruggekyk nie.Die bou van visuele ateljee-oplossings kan gedoen word deur dit net in die hoof xml-lêer te spesifiseer.

Vir enigiets meer ingewikkeld (om jou bronkode te kry, eenheidstoetse uit te voer, installeringspakkette te bou, webwerwe te ontplooi) kan jy net 'n nuwe klas in .net skep wat afkomstig is van Taak wat die Uitvoer-funksie ignoreer, en verwys dan daarna vanaf jou build xml-lêer.

Daar is 'n baie goeie inleiding hier:inleiding

Ek het nog net aan 'n paar .Net-projekte gewerk (ek het meestal Java gedoen), maar een ding wat ek sal aanbeveel is om 'n instrument soos Nant.Ek het 'n werklike probleem met die koppeling van my gebou aan die IDE, dit maak dit uiteindelik 'n baie pyn om boubedieners op die pad op te stel, aangesien jy 'n volledige VS-installasie moet gaan doen op enige boks waarvan jy wil bou in die toekoms.

Dit gesê, enige outomatiese bou is beter as geen outomatiese bou nie.

Ons bouproses is 'n klomp tuisgemaakte Perl-skrifte wat oor 'n dekade of so ontwikkel het, niks fancy nie, maar dit kry die werk gedoen.Een skrif kry die nuutste bronkode, 'n ander bou dit, 'n derde faseer dit na 'n netwerkligging.Ons doen rekenaartoepassingsontwikkeling, so ons verhoogproses bou ook installeringspakkette vir toetsing en uiteindelik gestuur na kliënte.

Ek stel voor dat jy dit in individuele stappe afbreek, want daar sal tye wees wanneer jy wil herbou, maar nie die nuutste kry nie, of dalk net weer moet begin.Ons skrifte kan ook bou van verskillende takke hanteer, so oorweeg dit ook met watter oplossing jy ook al ontwikkel.

Ten slotte het ons 'n toegewyde boumasjien wat elke aand die stam- en instandhoudingstakke herbou en 'n e-pos uitstuur met enige probleme of as dit suksesvol afgehandel is.

Een ding wat ek sou voorstel, maak seker dat u bouskrip (en installeerderprojek, indien relevant in u geval) in bronbeheer is.Ek is geneig om 'n baie eenvoudige skrif te hê wat net uitcheck \ kry die nuutste die "hoof" bou script dan begin dit.

Ek sê dit b/c Ek sien spanne wat net die nuutste weergawe van die bou-skrip op die bediener gebruik, maar óf plaas dit nooit in bronbeheer nie óf wanneer hulle dit doen, gaan hulle dit net op 'n ewekansige basis in.As jy die bouproses maak om van bronbeheer af te "kom", sal dit jou dwing om die nuutste en beste bouskrif daar te hou.

Ons boustelsel is 'n makefile (of twee).Dit was nogal lekker om dit te laat werk, aangesien dit op beide vensters moet loop (as 'n boutaak onder VS) en onder Linux (as 'n normale "maak bla"-taak).Die baie lekker ding is dat die bou die werklike lêerlys van 'n .csproj-lêer kry, ('n ander) make-lêer daaruit bou en dit laat loop.In die prosesse noem die maak-lêer dit eintlik self.

As daardie gedagte die leser nie bang maak nie, dan (óf hulle is mal óf) kan hulle waarskynlik maak + "jou gunsteling string mangler" kry om vir hulle te werk.

Ons gebruik UppercuT.UppercuT gebruik NAnt om te bou en dit is uiters maklik om te gebruik.

http://code.google.com/p/uppercut/

'n Paar goeie verduidelikings hier: UppercuT

Gelisensieer onder: CC-BY-SA met toeskrywing
Nie verbonde aan StackOverflow
scroll top