.NET Web Service Beste Praksis for flere utviklere

stemmer
1

Vi har et stort ASP.NET prosjekt bestående av flere hundre rapporter. Vi er i ferd med å flytte alle SQL-spørringer (som kjører mot en Oracle Database) i tre webtjenester. Det web-tjenester er kategorisert etter kommando, utvalg og rapportspørringer. Vi må ta i bruk et sub-sett av vårt prosjekt ved hjelp av en SQL * Server backend til flere steder som er koblet fra Internett. Derfor har alle tilkoblinger til databasen og spørringer i webtjenester gjør applikasjonen håndterlig og vi kan trekke sub-sett av rapporter og ikke trenger å endre koden. Prosjektet er under kildekontroll ved hjelp av Serena ChangeMan programvare.

Problemet er at vi har flere programmerere, og de trenger alle å sjekke ut web services filene til å arbeide på sine varer. Vi har nettopp gjennomført forgrening, men det er langsomt blitt et mareritt. Vi har månedlige produksjons leveranser og noen ganger varer som er ment å gå inn i den månedlige build bli holdt fram til neste måned. Sammenslåing har blitt en manuell prosess.

Jeg har gjennomføre søk på internett, og jeg er overrasket over at jeg ikke har vært i stand til å finne noen gode “best practice” webtjenester arkitektur hvite sider. Det er mange store selskaper som må ha møtt disse problemene.

De fleste store utbyggings grupper bruker forgrening? Jeg har lest at Visual Studio Team System Database Edition kan gi standard kode som vil tillate programmet å koble til ulike databaser. Vil innkjøp Team System være den beste metoden? Eller er det noen som vet hvor jeg kan finne dokumentasjon som vil hjelpe oss med å løse disse problemene?

Takk, Lorie

Publisert på 09/12/2008 klokken 18:20
kilden bruker
På andre språk...                            


3 svar

stemmer
2

Dette problemet synes å være helt uavhengig av hensikten med programvaren. Problemet her er at du har et lite, begrenset antall filer som flere utviklere skal jobbe med på en daglig basis. Jeg har ikke erfaring med Serena ChangeMan programvare eller andre enn å spille rundt med den TFS. Jeg har erfaring med et par versjonskontrollsystemer som bruker en sammenslåing / forplikte modell: CVS og Subversion . Disse er begge gode, gratis versjonskontrollsystemer som er mye brukt.

Hvis du er ukjent med flettingen / forplikte modell, ideen her er at ingen enkelt utbygger kan "kassa" og låse en fil for endringer. Alle kan laste ned og gjøre endringer i en hvilken som helst fil. Når det er på tide å begå disse endringene i kildekoden databasen, vil depotet programvare hindre iverksetting hvis andre endringer er gjort i filen av en annen utvikler. Den nye versjonen blir deretter lastet ned, og i de fleste tilfeller endringene blir automatisk slått sammen med endringene. Du re-test, og så begår den versjonen. Denne modellen er svært vellykket og svært skalerbar.

Etter å ha sagt alt dette, selv flettingen / forplikte modellen kan ikke løse sorg over å ha et lite antall filer med en rekke utviklere gjøre endringer til nevnte filer. Jeg vil anbefale dele din funksjonalitet inn flere webtjenester. Kanskje i stedet for tre, monolittisk webtjenester kan du opprette tre grupper av relaterte web-tjenester. Jeg tror dette, kombinert med å bruke et versjonskontrollsystem med flettingen / forplikte vil løse problemene dine.

CVS og Subversion servere kjører på Windows, Mac og Linux. Det finnes en rekke klienter for hver, som er tilgjengelig på en rekke operativsystemer. Disse inkluderer fritt sammen kunder, Visual Studio plugins, og shell plugins. Et annet pluss er at både CVS og Subversion er tilgjengelig fra kommandolinjen som gjør scripting (tror automatisert build) ganske enkelt.

Svarte 09/12/2008 kl. 18:34
kilden bruker

stemmer
1

Hvorfor ikke segmentere logikk i enkelte class filer som kan sjekkes ut av hver utvikler?

Svarte 09/12/2008 kl. 21:05
kilden bruker

stemmer
0

Vi bruker SOA, men vi bruker også SVN som er mer sammenslåing orientert. Kanskje vurdere en annen kilde kontrollsystem?

Svarte 09/12/2008 kl. 18:27
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more