- Dette emne har 19 svar og 7 stemmer, og blev senest opdateret for 2 Är, 5 mÄneder siden af Festival_H.
-
Emne
-
Festival_H
- E-peen: 945
SÄ tager jeg den fÞrste. Det er godt nok ikke spil udvikling, men jeg tÊnker at vi ogsÄ har en par almindelige udviklere pÄ sitet ogsÄ, der kunne have et input til denne case.
Sagen er den at jeg snart skal vÊre med til at starte en nyt firma op og i den forbindelse skal vi ogsÄ have startet en ny rundt bitness kode med til vores nye produkter. Det betyder at vi starter 100% blankt.
Jeg sidder i dag i et stort helvede af en code base situation. Jeg er glad for GIT og source control sÄ alle mine projekter ligger pÄ GitHub og jeg publicer alle mine projekter og committer alle mine Êndringer til GitHub. Mine kollegaer elsker at pille direkte i source koden og gemme direkte i LIVE code for at kunne prÞve Êndringen med det samme uden build, publish og ingen commits. Det er primÊrt forskellige web services vi udvikler. Ikke nok med det, men alle services ligger i forskellige afskygninger pÄ forskellige FTP servers som ingen rigtig har et overblik over. NÄr en service gÄr ned eller skal have implementeret en ny feature, sÄ skal vi fÞrst finde en klient som kalder ind til den pÄgÊldende service for at finde den sti servicen ligger pÄ og sÄ kan vi rode den frem pÄ en FTP server og fÄ adgang til koden.
Jeg blir lead developer pÄ det nyopstartende hold og har i tankerne at krÊve at vi kÞrer GitHub first. ALT skal ligge pÄ GitHubben og det er Git der er Master. Hvis der er en udvikler der fumler direkte i live kode, sÄ er det hans skyld hvis hans rettelser blir over skrevet af en publish fra Git. Det er synd fornuft efter min mening. Det problematiske kommer i den nÊste del.
Vi har i dag smÄ bider af kode i stort set alle projekter der pÄ den ene eller anden anden mÄde fx hÄndtere namespace i xml eller arbejder med mediatypes som PlainTest eller Json. Som det er i dag har alle projekter sin egen udgave af dette kode. Ingen code sharing med andre ord. Det vil jeg gerne indfÞre. Jo mere code sharing jo bedre. Jerg vil ogsÄ gerne forsÞge at gÞre det nemt for kommende nye udvikler medarbejdere at finde ting. I stedet for at skulle browse rundt pÄ forskellige FTP servers, sÄ er min ide at lave en CompanyName solution der sÄ skal indeholde alle vores projekter. PÄ den mÄde blir det nemt at introducere kommende medarbejdere i Žhele kode basen og det blir nemt for alle projekter at fÄ adgang til dele kode. Det kunne ogsÄ sagtens vÊre stÞrre helper classes nu hvor alle projekter vil blive slÄet sammen i en solution.
Jeg tÊnker at skulle kategorisere projekterne i projekt foldere i solutionen, men ellers have alt i den samme solution. Fordi der oftest er tale om webservices, sÄ vil alle projekterne have deres publishing profile der fortÊller prÊcis hvor projektet skal deployes nÄr der skal publiceres. En ny udvikler skal derfor bare have adgang til FTP host serveren og sÄ vil de kunne publisher nye udgivelser af vores projekter rimeligt hurtigt uden at vide hvor projekter ligger. Det er allerede indstillet pÄ forhÄnd.
Mine anker er dog hvordan GitHub vil tage imod sÄdan en monolith af en solution! I starten vil der ikke vÊre sÄ mange, men det vil vÊre min plan at alt nyt skal oprettes heri.
Og nÄr der kommer mange projekter i, hvordan vil Visual Studio sÄ begynde at opfÞre sig!!Der er sgu mange ting der kan gÄ galt her. MÄske jeg bare skal prÞve og viser det sig at vÊre noget lort, sÄ mÄ jeg splitte det op. SÄ blir en solution folder til sin egen solution. Og skal den bruge noget delt kode sÄ skal projektet addes til den solution og sÄ mÄ den referere dertil.
-
Svar
-
Festival_H
- E-peen: 945
Hmm jeg lÊser mig til at det kan vÊre usmart at have mange projekter i een solution. Jeg tror jeg mÄ lÞse det med GitHub i stedet. Have en eller anden CompanyName.Core med alt det delte kode og sÄ projekterne selv per solution.
Tror det er sÄdan det mÄ ske..
kazcon
- E-peen: 16
Jeg ser ikke et eneste spÞrgsmÄl. Er det her en blogpost, eller debatindlÊg?
VS kan sagtens hÄndtere mange projekter i én solution. Det kan gÞre build (og evt. NuGet styring) markant nemmere, end hvis det er spredt over flere solutions som alligevel er afhÊngige af hinanden.
Hvis projekterne er totalt uafhÊngige, sÄ kan det give mening at give dem hver deres solution.- Dette svar blev Êndret 2 Är, 7 mÄneder siden af kazcon.
Cancerman
- E-peen: 3,721
Medmindre du elsker GitHub, sÄ overvej Azure DevOps.
Det gÞr ingen forskel pÄ din store solution, men jeg foretrÊkker i hvert fald frem for GitHub.
Hvis projekterne er afhÊngige af hinanden, sÄ giver det mening og have dem i samme solution. Ellers kan du fint dele dem op.
Nogle af core tingene kan du evt lave som Nuget pakker.
Festival_H
- E-peen: 945
Debat indlÊg. Interwebs siger sÄ fÄ projekter som muligt. I princippet vil de fleste projekter have brug for reference til det library med det kode som er delt, men ellers vil de vÊre uafhÊngige af de andre projekter. I hvert fald for webservice API projekter. Det er muligt at der kan komme andre typer projekter til over tid, men det vil primÊrt vÊre webservice APIs.
Jeg er nok ude i at jeg mÄ prÞve at se hvad der virker. Jeg er ret tosset med at have alt i én solution i forhold til det jeg oplever i dag mÄ jeg sige, men det kan mÄske give performance problemer hen af vejen.
Festival_H
- E-peen: 945
#3 Ka godt vĂŠre jeg bare burde have skrevet Git i stedet for GitHub. For vi bruger i dag faktisk DevOps som Git host. Jeg ved bare lige nu ikke hvor meget funding der vil blive sat af til online miljĂžer rundt omkring.
Det er alt sammen meget nyt og alle aftaler eller kontrakter er slet ikke pĂ„ plads endnu. Jeg er bare ved at afsĂžge de udfordringer jeg oplever i min hverdag pĂ„ forhĂ„nd og sĂžger argumenter for at tage den ene eller den anden beslutning nĂ„r vi engang gĂ„r i gang đ
- E-peen: 3,721
Det kommer ogsÄ utroligt meget an pÄ arkitekturen og hvilke afhÊngigheder der er mellem de services.
Skal hele lortet deployes pÄ en gang, eller er det autonome services der ikke nÞdvendigvis skal deployes samtidig?
dinirex
- E-peen: 55
Eftersom du nĂŠvner Visual Studio laver jeg antagelsen at du arbejder med C#?
Jeg ville holde separate projekter for sig, men lave delt kode som nuget pakker pÄ en nuget server feks Azure devops.Var kun pÄ github i deres unge dage, men om det er github, bitbucket eller azure devops, sÄ antager jeg, at du kan benytte dig af branching strategies. SÄ ingen ikke kan pushe direkte til master branchen, men at alt gÄr igennem pull requests. Samt at alle features bliver lavet pÄ feature branches.
Hvis i bruger devops kan i samme alt logik et sted, og lave jeres deploys her ogsĂ„. SĂ„ folk ikke nĂždvendigvis har adgang direkte til serverne / ftp’er, og det gĂžr det nemt at identificere hvem der har deployet ĂŠndringer, samt at nye blot skal trykke pĂ„ en knap, og ikke kende diverse logins til ftp’er.
- E-peen: 3,721
Generelt vil det nok vĂŠre en god ide at lĂŠse lidt om DevOps disciplinen – det er en videnskab i sig selv. đ
Festival_H
- E-peen: 945
Det er generelt ikke vildt store projekter vi laver. Og som sagt har de ikke vilde referencer rundt omkring. Det er bare de der standard .Net libraries til ASP.Net projekter og sÄ mÄske vores Core/Shared projekt med alle Helper classes og sÄ mÄske en eller 2 Nuget packages hvis det er lidt specielle services.
Grunden til at kÞre GIT er mest for at fÄ historik pÄ commits. Og at kunne branche ud fra master hvis vi skal lave en stÞrre Êndring. Som udgangspunkt kommer udvikling og minor vedligehold til at foregÄ pÄ master/main. Vi kommer ikke til at lave auto publish. Det blir den enkelte udvikler der publisher Êndringer i de services han er Êndret i lokalt fra nÄr han mener koden er klar til test/release.
Det er netop igennem publishing profiles i de enkelte projekter at vi vil sÞrge for at ingen skal huske pÄ hvor de forskellige projekter skal publiceres hen. Man skal dog have rettighed til at uploade til den FTP servicen er hosted pÄ dog. Det er noget management som vores system admin mand kommer til at stÄ for.
Vi mÄ bare prÞve os frem og fÄ rettet de ting som ikke lever op til forventningerne.
Festival_H
- E-peen: 945
#6 Autonome for det meste. Vi kommer kun til at deploye de services der er Êndret i. Med mindre vi har lavet om pÄ et API signatur. SÄ skal vi selvfÞlgelig opdater clienter pÄ det api.
Festival_H
- E-peen: 945
#7 Det lyder smart og sÄ sikre man ogsÄ at udviklerne fÄr committet sine Êndringer. Det vil jeg lige fÄ kigget pÄ. Med deploy fra lokal kode, kan man jo komme i en situation at en udvikler glemmer at committe og pushe sine Êndringer til remote og sÄ er Source Control jo ligegyldigt.
- Dette svar blev Êndret 2 Är, 7 mÄneder siden af Festival_H.
- Dette svar blev Êndret 2 Är, 7 mÄneder siden af Festival_H.
hausner
- E-peen: 888
#7
Med flere mennesker og flere projekter involveret skal processen vÊre skarpt styret. Alt det der med at Êndre direkte pÄ serveren, via FTP-sites, deploye lokal kode til ovenliggende miljÞer osv. bÞr afvikles.
Der skal vÊre branching-strategier pÄ plads, Pull Request skal godkendes fÞr de kan merges ind i kildekoden og gated CI/CD pipelines bÞr sÊttes op, og der skal vÊre styr pÄ miljÞerne (dev, test, pre, prod). SÄ der er styr pÄ processen og den er dokumenteret i en form for Developers Guide.
Det kan tage lang tid at fÄ det hele pÄ plads men i vil takke jer selv for at have gjort det. nÄr det fÞrst er pÄ plads kommer i til at spare sÄ meget tid pÄ udviklingen og fejl i deployment. Og i kan klare det hele i Azure DevOps.- Dette svar blev Êndret 2 Är, 7 mÄneder siden af hausner.
- E-peen: 3,721
Jeg er 100% enig med #12
Jo fĂžr i fĂ„r det sat i system jo bedre – og det er nemmest at gĂžre fra start.Jeg tror i vil sĂŠtte pris pĂ„, at deployment er sat i system og ikke det vilde vesten đ
Bams
- E-peen: 358
Et supplement omkring struktur.
Det er helt fint med en solution til alle dine projekter, men da jeg var VS-dreng, sÄ kunne der godt vÊre en performanceudfordring med VS, hvis det blev alt for stort, sÄ det ville jeg vÊre opmÊrksom pÄ.
Jeg kan godt lide dit forslag om solution name = CompanyName. Det er sq da business first đ TĂŠnk i den sammenhĂŠng hvad du er lead for, og hvad formĂ„l og ansvar er med jeres team. Vi har allesammen lidt storhedsvanvid, nĂ„r vi starter sĂ„ noget her:)
SmallCompany.[Projects].[Files]
Hvis du har brug for mere granulering kan du altid bruge navngivning.
+MidSizeCompany.Customers.[Projects].[Files] Her zommer du lidt ind i din solution – stadig med business first.Og sĂ„ er der Projekter, men det kan vĂŠre jeg allerede vrĂžvler, sĂ„ min holdning hertil mĂ„ komme pĂ„ forespĂžrgsel đ
Til sidst vil jeg nĂŠvne, at det kan vĂŠre en rigtig god idĂ© at bruge 30min i excel pĂ„ at opstille en matrix, der mapper en forretnings-/organisationsstruktur til VS til DevOps / GitHub. Det gĂžr det meget nemmere, nĂ„r man er igang đ
Fisker
- E-peen: 568
OgsÄ enig i #12 der er virkelig, isÊr nÄr det gÊlder web projekter, mange gange hvor deployment ender med at vÊre at kopiere filer via Explorer.
FÄ lavet en klokkeklar deployment strategi, sÞrg for at have versionering synlig i produktet sÄ i kan spore frem til hvilken kode er gÊldende.
Kig eventuelt pÄ containere som en af jeres strategier.
Og gĂžr det nu fra starten af, lav nogle simple hello world projekter til at teste af med evt.
Som ogsÄ nÊvnt hvis projekterne har en reel sammenhÊng, sÄ giver det god mening det er i samme solution, man kan muligvis gÞre brug af git submodules til at have adskilte repositories, hvilket kunne give god mening hvis man fx har et projekt som del af solution der laver en installer.
UndgÄ firmaer og brands i koden i ender blot med at ligne amatÞrer nÄr det sÄ bliver besluttet i skal rebrande eller lignende. PÄ samme vis kan man lige sÄ godt antage at det sker, sÄ jeg vil anbefale at man tÊnker pÄ at gÞre det nemt at skifte tekst og logoer ud.
- E-peen: 888
Festival_H
- E-peen: 945
Status update.
Vi har nu vÊret igang i en mÄneds tid, med alt mulig udvilking og prototyping pÄ et udvalg af produkter til at fÄ startet op pÄ noget.
Vi er kommet frem til at benytte Repos pÄ DevOps. Der er lavet et Core projekt der blir pakket og publiseret til en nuget feed. De services der skal bruge helpers fra Core projekter henter fra en privat nuget/artifact feed som builder og publiser automatisk nÄr der committes til den og der er angivet nyt versionsnummer. Jeg har ikke lige luret hvordan man laver AutoIncrement med YML pÄ Pipelines endnu, men det kan vÊre jeg finder ud af det engang.
Vi laver en slags micro services med sÄ lidt funktionalitet i hver service som mulig. Om det er en god ide mÄ tiden vise. Det er ret nemt at oprette en nyt API Service Host pÄ Azure. Alle services/funktioner til et bestemt produkt kommer i den samme solution, men de ender med at have deres egen csproj og bliver deployet til deres egen api site.
Vi er ved at afprÞve flexibiliteten af Azure hosting. Det er pÄ sigt meningen at et balancing system skal kunne tage disse artifact builds og automatisk bygge nye sites som vores produkter sÄ dynamisk kan blive tildelt hvis behovet opstÄr.
What a crazy world we live in!
Azure er godt nok en gigantisk platform!
- Dette svar blev Êndret 2 Är, 5 mÄneder siden af Festival_H.
- E-peen: 3,721
Jeg har ikke lige luret hvordan man laver AutoIncrement med YML pÄ Pipelines endnu, men det kan vÊre jeg finder ud af det engang.
GitVersion đ
Azure er godt nok en gigantisk platform!
Yep. Jeg kan huske da det startede, der var der ikke meget men pludselig sĂ„ gik det godt nok stĂŠrkt. đ
Det lyder som en rigtig fin lĂžsning i er kommet frem til.
Festival_H
- E-peen: 945
GitVersion… Det skal jeg da lige have give et kig đ
Cancerman
hausner
Fisker- Du skal vĂŠre logget ind som bruger for at kunne svare...