De broncode voor de T-HL ASP.NET websites bevat een aantal Visual Studio projecten die allemaal apart onder git DVCS zitten. De blog post schetst de structuur van deze code en geeft aan hoe er van branch kan veranderd worden, hoe branches worden gemerged en hoe commits gebeuren. Om deze post te ondersteunen zijn een aantal scripts aangemaakt die de acties automatisch uitvoeren.

Structuur van de code

De broncode voor de T-HL ASP.NET websites zit verdeeld over de volgende 5 projecten:

• thl_asp_websites: De website-specifieke code voor Transeurope, Holidayline en GoChic

• Objectclasses: Bevat de code van JRS

• Pageclasses2009: Bevat pagina elementen zoals Repeaters, Literals, ...

• Library: Een bibliotheek met definitie van constanten, paths, etc.

• SEO: Een module voor URL rewriting

Deze projecten zitten apart in git en moeten op elkaar afgestemd blijven door middel van de correct referenties.

Version control met git

Basisbegrippen

git laat toe om met meerdere developers op éénzelfde codebase te werken. Bovendien wordt er naast een lokale versie van de broncode (local) ook een overeenkomstige versie bijgehouden in de cloud op Bitbucket.

De operatie die je verandering opneemt in source code control heet COMMIT.

De operatie die veranderingen in een lokale branch naar zijn tegenganger in de cloud brengt heet PUSH.

De operatie die veranderingen in de cloud in de lokale branch zet heet PULL.

Je kunt ook code van twee branches samenvoegen, dit heet MERGE en gebeurt steeds lokaal. Eventueel kan na een merge operatie ook nog de lokale branch gesynchroniseerd worden met de cloud door een push.

Werken met branches

De version control op de broncode van de websites werkt volgens het principe van master/DEV/developer branches. Dit wil zeggen dat er een master branch is die steeds de code van de huidige productiewebsite bevat, een DEV branch die de code voor de test websites bevat en developer branches die individuele aanpassingen bevatten.

Verder zijn er op elk project branch permissions gedefinieerd. Dit houdt in dat niemand rechtstreeks code kan pushen naar de master of de DEV branch. Aanpassingen gebeuren steeds via "Pull request". Bovendien kan elke developer exclusief op zijn eigen branch werken en indien gewenst "feature branches" aanmaken om bepaalde functionaliteit te isoleren.

Vermijden van conflicten via .gitignore

Samenwerken op een code base vraagt dat developers op regelmatige basis de code van hun collega's en de code op master of DEV 'mergen' met hun eigen code. Om hierbij geen conflicten te hebben passen we een aantal zaken toe:

• .csproj en .sln files die machine-specifieke paths bevatten worden via .gitignore uit source control gehouden. Elke developer zet de verwijzingen juist op zijn/haar lokale machine en beïnvloedt hierbij niemand anders;

• /bin en /obj folders die lokaal worden gebuild worden via .gitignore eveneens buiten source control gehouden

Basis-operaties met git

Operaties

Om met git te kunnen werken op de vijf verschillende projecten zijn drie batch files gemaakt die operaties uitvoeren op alle projecten:

• commit_all.sh: Commit de veranderingen in alle projecten. Optioneel kunnen deze ook gepusht worden;

• switch_branch.sh: Verandert van branch in alle projecten. Optioneel kan de laatste versie van de doelbranch ook opgehaald worden van de remote;

• merge_branch.sh: Synchroniseert de code op de huidige branch met de code op een andere branch. Optioneel kan de code op de branch die wordt gemerged eerste nog worden opgehaald van de remote. Bij deze operatie kunnen er mogelijk conflicten zijn die moeten opgelost worden. Hier wordt dieper op ingegaan verder in de blogpost.

De shell scripts kunnen hieronder worden gedownload, je kunt ze ook vinden op de dataserver (S:\IT\varia\git).

Uitvoeren van shell scripts

De scripts worden uitgevoerd met de git command line die kan gedownload worden vanaf de git scm website.

De scripts moeten geplaatst worden in de top level directory waaronder de THL ASP.NET websites projecten vallen. Let ook op de mappenstructuur waarbij de projecten Library, ObjectClasses, PageClasses2009 en SEO niet in de folder thl_asp_websites zitten.

Je kunt naar deze directory navigeren en vervolgens het commando uitvoeren met het volgende statement (vb voor commit_all.sh):

$ bash commit_all.sh

Het script zal verder input vragen en steeds aangeven wat er moet ingevuld worden.

Indien er problemen zijn tijdens de uitvoering zal er ook output worden gegeven naar de gebruiker.

Oplossen van merge conflicten

Indien er bij de uitvoering van het script merge_branch.sh een conflict is (code aangepast in beide branches), zul je moeten beslissen welke code te weerhouden. git plaatst je branch in een intermediare staat (MERGING) en wacht tot de gebruiker de conflicten oplost. De git shell toont in welke files de conflicten zitten. In de broncode-bestanden staan de conflicten staan duidelijke aangegeven (zie onder voor voorbeeld). Onder de <<<<<< staat de code zoals die in de huidige branch staat, onder de ======= de code van de branch die gemerged wordt. De gebruiker verwijdert de code die niet meer nodig is.

<<<<<<<
Changes made on the branch that is being merged into. In most cases,
this is the branch that I have currently checked out (i.e. HEAD).
|||||||
The common ancestor version.
=======
Changes made on the branch that is being merged in. This is often a 
feature/topic branch.
>>>>>>>

Nadien met een commit worden uitgevoerd. Dit kan door het script commit_all.sh uit te voeren.

Af en toe zal git ook vragen om een merge-boodschap op te geven.

Hiervoor wordt een vi editor geopend in de git shell. Typ i om je merge boodschap toe te voegen. Als je klaar bent, druk op Esc en vervolgens op :wq om de boodschap op te slaan.

Conventies voor werken met git

We gebruiken de volgende conventies binnen T-HL:

• Werk steeds op je developer branch. Gebruik switch_branch.sh om naar je eigen branch te switchen alvorens code te editeren.

• Merge enkel naar je eigen developer branch. Zorg bij de uitvoering van het merge_branch.sh script dat je eigen branch eerst geselecteerd is. 

• Merge geregeld de branches van mede-developers en de DEV of master branch.

• Hoe het broncodebeheer clean, plaats geen code backups of tijdelijke bestanden in de mappen die onder broncodebeheer staan.

Troubleshooting

De meeste problemen zullen voorkomen wanneer de projecten voor het eerst moeten gebuild worden. Hierbij moet je vaak referenties naar de andere projecten en dlls terug juist zetten.

Locatie van .sln en .csproj files

Bij een eerste installatie moet je de .sln en de .csproj files manueel inplakken in de mappen met je projecten. Je kunt deze files terugvinden op de dataserver:

S:\IT\varia\git\sln and csproj files

De structuur is als volgt:

• map thl_asp_websites:

• • map Transeurope2010

  • • Transeurope2010.sln

    • map Transeurope2010

    • • Transeurope2010.csproj

  • map Holidayline2009

  • • Holidayline2009.sln

    • map Holidayline2009

    • • Holidayline2009.csproj

  • map GoChic

  • • GoChic.sln

    • map GoChic

    • • GoChic.csproj

• map Library

• • Library.csproj

• map ObjectClasses

• • ObjectClasses.csproj

• map PageClasses2009

• • PageClasses2009.csproj

• map SE0

• • SEO.csproj

Projectreferenties

Bij het inladen van de projecten (Library, ObjectClasses, PageClasses2009 en SEO) moet de referentie naar de map met deze projecten juist zijn. Soms zul je onderstaande boodschap zien.

Om een referentie te vernieuwen, kun je in de Properties de folder aanpassen. Indien dit niet lukt kun je project-referenties verwijderen (Rechtsklik + Remove) en vervolgens weer toevoegen met FILE > Add > Existing Project ... en dan de .csproj file van het desbetreffende project selecteren.

DLL referenties

Bij het inladen van DLLs kan er ook soms iets fout lopen. In de map S:\IT\varia\git\sln and csproj files zit ook een map "Shared DLLs". Deze wordt buiten sourcecode control gehouden en kun je dus manueel inplakken in de map thl_asp_websites.

Als je bij het builden fouten krijgt in Flight of ObjectClasses.dll, kijk dan zeker eens de referenties na:

Als een referentie niet meer juist is komt er links een oranje symbooltje naast. Dan moet je de referentie verwijderen (rechtsklik + Remove) en nadien opnieuw toevoegen door rechts te klikken op References > Add reference en dan ofwel een project referentie aan te vinken (zie onder voor voorbeeld) of via Browse op zoek te gaan naar een DLL in de map SharedDlls.

Probeer bij buildproblemen zeker om de referenties naar Projects te vernieuwen. Dit kan de meeste problemen oplossen.

2023 opstelling voor Visual Studio Community 2022
Op de e-schijf plaats je de folder 2022projects
hierin worden de verschillende projecten geladen vanuit git
de referenties van de projecten verwijzen naar de folder packages

in de projecten vind je .ignore file welke bestanden en folders er niet moeten gesynced worden

 Indien er in de bitbucket folders zijn opgeladen die eigenlijk niet moeten en niet moeten gesynced worden omdat dit per user anders is of folder te groot wordt (bv .sln / bin / obj / images /...)
Ook al staat er in de .ignore file dat er bepaalde folders of files moeten genegeerd worden, indien ze reeds in bitbucket zitten dan zullen ze toch gecontroleerd worden bij commit of pull en push, je dient ze dus online in bitbucket te verwijderen

dan ga je naar git-bash
ga naar de correcte locatie
en doe commando : git rm -r --cached file of folder
daarna : git add .
daarna : git commit -m "boodschap bv update sync"

Voorbeeld:

e:\2022projects\objectclassescms2022 (heeft een bin folder die niet online hoeft)

git rm -r --cached ./bin
git add .
git commit -m "remove bin folder from bitbucket"

zorg wel dat uw ignore file correct is ingevuld want anders voeg je de bin en obj foldrs terug toe via de git add . !!!!