- 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: 953
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: 953
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, 8 måneder siden af kazcon.
Cancerman
- E-peen: 3,775
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: 953
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: 953
#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,775
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,775
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: 953
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: 953
#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: 953
#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, 8 måneder siden af Festival_H.
- Dette svar blev ændret 2 år, 8 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, 8 måneder siden af hausner.
- E-peen: 3,775
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: 603
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: 953
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,775
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: 953
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...