Versjonskontroll, repositorie osv

[AnaXyd]

Heisann!

 

Har såvidt begynt å titte litt på versjonskontroll, ettersom dette virker som "the way" å jobbe på i fremtiden. Spesielt med tanke på at flere skal jobbe med samme kode osv.

 

Er det noen her inne som har noe erfaring med dette? Gjerne Git?

[BlueEAGLE]

Hadde du et spesielt spørsmål knyttet til dette?

 

En ting du bør være obs på er at veldig mange "etablerte" (les: Microsoftavhengige) bruker TFS og at om .net er en mulig fremtidig platform så er det også et system du bør gjøre deg kjent med. Alt i alt, med mindre du er ansvarlig for et prosjekt så blir det ikke du som velger versjonskontrollsystem, men det er alltid godt å kjenne til alternativ for å kunne gi en informert mening om emnet.

[Valkyrex]

Selv så bruker jeg Github. Det er en fantastisk tjeneste ^^ Git er enkelt og kraftfult. Det jeg føler er bra med Github, er at det er en fin kombinasjon av revisjonskontroll, og det sosiale (man kan "følge" andre brukere, lage sine egne versjoner av andres kode, og det ligger fint tilgjenglig på internett for å dele med venner). =)

 

Edit: https://github.com/Maxtors

Endret 2. juli 2012 av Valkyrex

[AnaXyd]

Takk for svar! Høres bra ut! Sett noen filmer på Youtube osv ang Git, og det ser jo veldig bra ut. Fått grei oversikt over begrepene tror jeg nå. Satte opp en konto hos Bitbucket(da jeg bruker andre tjenester fra Atlassian, som JIRA), og installerte SourceTree på Macen for å ha et GUI på dette. Er ikke så sterk på kommandoer i terminal.

 

Men fant veldig lite om dette her på forumet, så tenkte å høre litt om versjonskontroll her inne.

 

Er mye å sette seg inn i osv, men er det noen smarte måter å teste koden på når man har et repositorie? Min gamle måte å programmere på, er at jeg skriver litt kode, tester i browser for å se.

[Ernie]

En meget smart måte å teste koden på er enhetstesting (en: unit testing). Kort fortalt innebærer dette at man setter opp en rekke «test case» som operer på større eller mindre deler av koden. Dette gjøres typisk ved å sjekke om en gitt funksjon returnerer korrekt/forventet verdi, men er man litt mer avansert kan man også sjekke effekten av koden man har kjørt. F.eks. se om et globalt buffer har økt størrelsen. Er man en avansert bruker av «unit testing» har man også verktøy som sjekker dekningen man har i koden («code coverage») og måler hvor mange funksjoner, linjer og «branch» (steder i koden hvor videre eksekvering kan ta flere veier, typisk if/elseif/else) i koden man faktisk tester. Alt dette gjøres helt automatisert (bortsett fra å lage «test case» såklart), og kan være ekstremt nyttig når man jobber flere i samme prosjekt i og med at man kan ha en server stående og kjøre dette automatisk når noen dytter inn kode. Skulle det dukke opp feil i enhetstestingen kan man effektivt konkretisere det ned til hvilken «commit» som har forårsaket feilen, og ansvarlig person kan enkelt ta tak i det. Oppdager man feil som ikke dekkes av testkoden endrer eller utvider man naturlig nok denne til å inkludere den nye feilen slik at man veit at fremtidig kode fungerer som ønsket.

 

Hvis dette høres interessant ut vil jeg sterkt anbefale å se litt TDD. TDD eller «Test Driven Development» er en utviklingsmetotikk som i sin helhet er bygget rundt det å lage «test case» før man skriver en eneste funksjonell linje med kode. Man skriver altså spesifikasjonen for koden først og skriver så koden for å realisere dette. Dette gjør man typisk i små steg for å hele tiden være i nærheten av å ha kjørbar kode.

 

Bare så det er sagt: Dette er ikke nødvendigvis alltid like enkelt å få til for all kode. GUI er et notorisk problem å teste ordentlig, selv om det er langt fra umulig.

[MrDonutseeker]

Git er som nevnt utrolig kraftig og veldig lett å lære seg. I henhold til testing av kode så anbefaler jeg å se på git sine "hooks". Her kan du legge til bash-script før en commit blir godkjent av git, etter den er blitt godkjent, når den er blitt pushet til origin (server) etc. Dette er fantastisk greit og hjelper til å bake inn kontinuerlig testing av koden din bare du skriver et bra nok bash-script Jeg kjører på større prosjekt enhetstester, PHPCS og JSLint før commiten blir godkjent, for så å bygge prosjektet gjennom Jenkins når det blir pushet til origin.

 

Hvis det er noe mer spesifikt du lurer på er det bare å spørre

[WhiteFire]

Kan anbefale PHPStorm. Har en veldig fin git-integrasjon. Diff-vieweren er genial.

[AnaXyd]

Spennende! Så disse bash scriptene kjører koden inn i f.eks JSLint for å kjøre igjennom der, for å deretter verifisere om det kom noen feil? Antar at disse testene sjekker for f.eks skriveleifer i kode o.l?

 

Har du et eksempel på hvordan et slikt bash-script ser ut?

 

Jenkins har jeg og hørt om. Sett litt mer på den nå, og dette er en som lager builds/artifacts? Det jeg ikke har forstått, er hva man gjør med disse buildene? Er dette på en måte som en "patch" til systemet?

[MrDonutseeker]

Har ikke .sh-scriptet mitt tilgjengelig akkurat nå, men finnes hauger på hauger av eksempel (http://blog.lick-me.org/2011/07/git-pre-commit-hooks/) der ute på det store internettet Hovedpoenget med et pre-commit er at koden som du sender til server ikke er utgangspunktmessig bugget (Jenkins tar seg av dypdykket og ser om det er noe du mangler). Jeg bruker php -l med Zend som standard hovedsaklig da det tvinger meg til å programmere "ren PHP", men du har kanskje andre standarder eller system du vil kjøre for at du føler koden er feilfri nok til en commit.

 

Jeg bruker også GitFlow (http://nvie.com/posts/a-successful-git-branching-model/) når jeg programmerer prosjekt for tiden. Jenkins lager en ny build på develop-branchen hver gang det blir kjørt inn enn commit, og kjører da en haug med tools for å se om koden er up to par. Hvis jenkins er fornøyd, alle endringene gjort og resten er ok, bumper jeg master opp til en ny version tag og merger develop inn i den.

 

For oppsett av Jenkins anbefaler jeg å bare følge oppskriften på http://jenkins-php.org/ , og fjerne eventuelle add-ons du føler blir overkill

[Sono Juventino]

Sett litt mer på den nå, og dette er en som lager builds/artifacts? Det jeg ikke har forstått, er hva man gjør med disse buildene? Er dette på en måte som en "patch" til systemet?

 

PHP tolkes av en parser, i motsetning til språk som Java/C#/etc som må kompileres. En build i Javasammenheng er altså den kjørbare, kompilerte koden. Ta høyde for at dette er lite annet enn en gjetning, men vil tippe han legger til Unit-tester og sånt sett "kan garantere" relativt bugfri kode når denne legges til branchen. (Antagligvis også med versjonsnummer/dato osv) Hva Jenkins i praksis gjør, er jeg ikke kjent med.

 

På denne måten kan man gå tilbake til tidligere versjoner av kjørbare kode om noe plutselig ikke virker som tiltenkt.

 

PHPStorm så forøvrig veldig bra ut. Jeg er aldri helt fornøyd med verken Eclipse eller Netbeans.

[AnaXyd]

Aha, ja selvfølgelig, det tenkte jeg ikke på. Da vil det vel være liten vits med et slikt system når det er PHP det er snakk om?

 

Når jeg tenker meg om, har jeg sett Jenkins før, og det var i sammenheng med Bukkit (server plugin til Minecraft) som er kodet i java. Så til java ser det jo ut til å være den eneste veien å gå iallefall!

[MrDonutseeker]

Ta høyde for at dette er lite annet enn en gjetning, men vil tippe han legger til Unit-tester og sånt sett "kan garantere" relativt bugfri kode når denne legges til branchen. (Antagligvis også med versjonsnummer/dato osv) Hva Jenkins i praksis gjør, er jeg ikke kjent med.

 

På denne måten kan man gå tilbake til tidligere versjoner av kjørbare kode om noe plutselig ikke virker som tiltenkt.

 

Jenkins er en slags totaloversikt sammen med fordypende kvalitetstester som feks CloverPHP og lignende. Hvis noen av disse testene feiler så "brekker builden", selv om muligens programmet fortsatt er fullstendig kjørbart. Dette er bare for å sette en kvalitetsterskel for prosjektet og hjelper veldig hvis det (som det oftest er) flere mennesker inneblandet.

 

PHPStorm så forøvrig veldig bra ut. Jeg er aldri helt fornøyd med verken Eclipse eller Netbeans.

 

PHPStorm er magisk når det kommer til PHP Kraftig og lettvindt IDE. Bruker det sammen med SublimeText2 (som brukes til enklere småprogrammeringer) som også er verdt å snuse på.

[Sono Juventino]

Høres smart ut. Programmerer også endel Java i utdanningsammenheng, så både Unittesting og builds er forsåvidt velkjente begreper. Søkte om en studentlisens på PHPStorm nå. Får se om jeg ikke vurderer å kjøpe en lisens til skolestart om det ikke skulle gå. Takk for forslaget.

 

At det har github-integrasjon er forøvrig også et stort pluss.

[MrDonutseeker]

At det har github-integrasjon er forøvrig også et stort pluss.

 

SublimeText2 har også git-integrasjon (annotate), som kan utvides videre med plugin'en her

https://github.com/kemayo/sublime-text-2-git/wiki

[Sono Juventino]

Studentlisensen for PHPStrorm gjelder visst hele utdanningsintituasjoner, men krever visst bare utfylling fra en ansatt i fakultetet. Vil tro flere av foreleserne mine ville ha fylt ut skjemaet om jeg hadde spurt dem. Tenkte jeg bare skulle nevne det om andre studenter skulle ha lyst til å prøve å søke om en lisens.

 

MrDonutseeker: Takker for tipset. Forsåvidt ikke nok til å få meg til å bytte. GitHub har tross alt er godt GUI-program til OSX som er enkelt i bruk.

[AnaXyd]

Mye bra info her nå!

 

Kan også anbefale Sourcetree som GUI program til Git! Sjekket ut GitHub sitt, bra det og, men syntes kanskje Sourcetree gjør det lille ekstra! (Er forøvrig gratis)

 

Jenkins er noe jeg virkelig skal se på. Om det er slik jeg har forstått, virker det jo veldig kjekt å kjøre koden igjennom denne for å kvalitetssikre så mye man kan. Man har jo Atlassian Bamboo også, men denne er jo ikke gratis. Noen som har erfaringer med Bamboo?

Endret 10. juli 2012 av AnaXyd

[dahuff]

Har brukt Git fra kommandolinjen i ett og ett halvt år nå. Det vil si, git supplementert med gitk, som er ett gui app som gjør at det er lettere å få oversikt over treet og loggen. Det fine med denne ordningen er at versjonskontrollverktøyet fungerer likt uansett plattform og IDE. Jeg behøver ikke å lære meg noe nytt når jeg har taket på det. Kommandoene går veldig kjapt fra terminalen når man har de i fingrene. Ulempen er naturligvis at det er en høyere læreterskel. Jeg tyr fortsatt til Google og dokumentasjonen om jeg skal utføre noe jeg ikke er vant med. Antar Git ser identisk ut i OS X og Linux. På Windows bruker jeg msysgit, men bruker Linux vanligvis.

 

Jeg kjenner mange som fortsatt sverger til Subversion, som jeg også brukte før. Min erfaring er at selv om lærekurven og verktøyene er litt primitive for Git (kan diskuteres), så er man mye bedre beskyttet mot brukerfeil og serverproblemer enn i Subversion.

 

Litt artig at Subversion ikke er nevnt i tråden før nå. Var dette ett år tilbake, ville Subversion vært nevnt tidligere. Det er nok bare ett tidsspørsmål for de som har holdt igjen til nå også vil få øynene opp for fordelene med Git.

[Ernie]

Ja, i mine øyne er man ikke en seriøs utvikler før man innser at SVN ikke nødvendigvis er knallbra. Det eneste som kan være verre er vel CVS og ingen versjonskontrol i det heltatt.

 

Uansett, for de som vil prøve noe alternativt til Git så har man Mercurial. Mye samme greia og er man vant til SVN fra før så er termnologien nesten prikk lik.

[GeirGrusom]

Ja, i mine øyne er man ikke en seriøs utvikler før man innser at SVN ikke nødvendigvis er knallbra. Det eneste som kan være verre er vel CVS og ingen versjonskontrol i det heltatt.

 

Uansett, for de som vil prøve noe alternativt til Git så har man Mercurial. Mye samme greia og er man vant til SVN fra før så er termnologien nesten prikk lik.

Min erfaring er at Mercurial er litt enklere å ha med å gjøre enn Git på små til mellomstore prosjekter. Hvis man bruker GitHub eller lignende har det nok lite å si, men dersom du skal ha lokal hosting så er Mercurial litt enklere å få igang.

[tomsi42]

I bedriften der jeg jobber, så endte vi opp med å bruke Mercurial. En av kriteriene som vi satte opp var krav om en god GUI på Windows, da vi hadde lang erfaring med å bruke Perforce; i tillegg er en del av brukerene ikke utviklere, men testere og dokumentskrivere. I en slik setting fant vi at git ble for komplisert.

 

Subversion er foråvidt OK fortsatt, men er nok bedre egnet for prosjekter der man sittter samlet. Mercurial og git er bedre når utviklerene er spredd over flere lokasjoner.

 

Ja, i mine øyne er man ikke en seriøs utvikler før man innser at SVN ikke nødvendigvis er knallbra. Det eneste som kan være verre er vel CVS og ingen versjonskontrol i det heltatt.

Det finnes mye som er verre - ClearCase og det Microsoft hadde for 10 år siden, f.eks.