Som freelancer, - Umbraco konsulent, rådgiver eller hvad det nu ellers er i dette minut, så oplever jeg tit at "overtage" løsninger fra andre bureauer / freelancere, eller udviklere der bare er forsvundet.
Disse løsninger kan være sat op på utroligt mange måder, med dertilhørende super gode eller ualmindeligt elendige deployment metoder (hvis der overhovedet er nogle). - Jeg oplever stadig at overtage løsninger der deployes via FTP (endda ret store løsninger), Jeg bliver lige overrakset hver gang. Men its a tfact.
Mit "opråb" med artiklen er er at man som overtager af disse løsninger gør det en "my" bedre end den forrige. Eller ihvertfald bare sørger for at at have totalt styr på deployment og source control.
Det letter både ens egen hverdag, og når kunden engang skal videre til en anden leverandør, så kan man være stolt af det man videregiver.
Mine typiske scenarier er følgende:
- Kunde ringer med en løsning, de ved ikke hvordan det er sat op, men det skulle være godt nok. (80%)
- Kunde ringer og kender alt til løsningen, - har styr på git repo m.v og har selv kontrol over hosting (0.2%)
- Leverandør ringer og siger kunden vil videre, og de vil overgive løsningen (19.8%)
Min respons er selvfølgelig altid at det vil jeg gerne kigge på, - men uanset hvad udgangspunktet er ovenfor ender det stort set altid med det samme, man får en kodebase (som regel i zip eller et nyt git repo uden history)., måske nogle rdp credentials til en server et eller andet sted, - alternativt nogle FTP oplysninger, - i de bedste tilfælde har den tidligere leverandør sat en azure tennant op til kundes ting, men i guder hvor er det sjældent jeg ser det setup.
Og så til essensen af artiklen.
Jeg har dummet mig mere end mange gange, jeg har taget kunder ind og videreført den process de havde før, fordi det var det de nu engang var trygge ved, eller det var sådan det skulle være eller [indsæt selv forklaring her]. - Der gik en del år før jeg forstod, at kunderne (og jeg beklager hvis der er kunder der læser med), - Ikke ved hvad de har brug for, de foretrækker den tekniske løsning der blev solgt bedst til dem i tindernes morgen af en udvikler der vidste hvad han sagde
Men tiden går, klokken slår, og tiderne ændrer sig meget, så min anbefaling er at man anskuer løsningen, og så finder de rette rammer for den dateret udfra nutiden.
Min process er følgende.
Kildekode:
Det vigtigste ved dette trin er at sørge for ejerskab af kildekoden, sørg for du har den seneste, og den stemmer overens med den kode der er i produktionsmiljøet.
Og så:
- Ligger kildekoden ikke i et git repo, så laver jeg et nyt i min (mit selskabs) konto
- Ligger kildekoden i et repo, men udvikler vil ikke overføre ejerskab til kunden, så laver jeg et nyt repo baseret på det gamle (forudsat der er adgang, ellers går vi til punkt 1)
Et lille tip til når du overtager koden, så skan lige folderen du har fået for store filer, - tit oplever man der ligger zip filer, bak filer, eller MP4 etc. i kodebasen, som ikke burde være der.
I en powershell prompt, så kan du køre
ls *.pdf -Recursive | where-object {$_.length -gt 1048576} | format-table -property Name
Som giver en liste over filer der er større end (fx. 1 mb, jeg sætter den gerne til ca. 5mb).
Deployment:
Hvordan deployes koden i dag, - Hvad har du af muligheder ?.
Min umiddelbare approach er følgende:
- Hvis koden deployes manuelt så skal den process skrotes
- Hvis der er CI/CD sat op, og den giver mening, så behold den, den sparer timer.
