Archief - development workflow met Git

't Is eens iets anders, maar ik heb het gevoel dat ik het hier wel kan vragen:

We zijn op't werk met een 4tal developers (hopelijk binnenkort met 5) en het wordt dringend tijd dat we overschakelen op een versiecontrole systeem.

Git lijkt me de way to go als ik even vergelijk met de concurrentie en hier heb ik de laatste dagen dan ook al wat mee gespeeld. Nu, wat me nog altijd wat onduidelijk is, is de workflow binnen een team. Zijn er hier mensen die hier ervaring mee hebben?

Gelijk ik het zie, hanteren we best volgende aanpak:
- De bare repository centraal.
- Elke dev heeft z'n eigen clone waar aan gewerkt wordt.
- 's ochtends pull je de origin zodat je eigen repo up to date is.
- Je werkt aan je eigen repo, met je eigen commits
- 's Avonds doet elk zijn push naar de bare repo. Meestal werken we toch aan afzonderlijke bestanden, conflicten zouden nauwelijks mogen optreden.

Klopt deze aanpak zowat? Of werk je toch beter met meerdere mensen aan dezelfde repo? Belangrijk blijft natuurlijk dat in de bare repo duidelijk blijft wie wat gedaan heeft en we eenvoudig terug kunnen bij fouten (dit is me nog niet helemaal duidelijk of dit vlot werkt met Git).

Het hangt een beetje af van waar je aan werkt uiteraard, gaan er verschillende versies van de software bestaan die verder onderhouden moeten worden of niet? Want de workflow bepaal je in principe zelf.

Een eenvoudige workflow is dat je een master branch hebt die overeenkomt met de productieversie. Daarnaast werk je elk aan bepaalde features in afzonderlijke feature branches (feature/xxxx, feature/yyyy). Eens je die wil mergen met de master branch doe je eerst nog eens een merge met de laatste versie van de master branch (pull op master, merge met master op je feature branch) die je test (automated of niet) en daarna doe je (als je GitHub/Bitbucket gebruikt) een pull request en kan 1 van je peers (een andere developer dus) die code eens checken en dan mergen (of vragen om ze aan te passen uiteraard ). Die werkwijze hanteren wij nu op 't werk (ongeveer toch, Jenkins doet ook nog wat automated checks).

Tevoren werkten we met gitflow, maar aangezien we niet echt een product ontwikkelen was dat niet zo handig als werken met pull requests. Lees zeker ook 't volgende eens : Scott Chacon on the Interwebs.

Wat Djeez zegt is volledig juist en die twee workflows ben ik paar weken terug ook tegengekomen.

Djeez is idd spot on, volgens mij de beste methode! Het voordeel van de feature branches en pull requests is dat je goede kwaliteitscontrole kan uitvoeren en als je bv Github gebruikt kan je lijnen code highlighten voor verbetering wat enorm handig is.

Wij gebruiken hier ook Git in samenwerking met Gitflow. Voor elk project hebben we 2 branches, namelijk development en master. Master is altijd stabiel en kan elk moment in productie worden geplaatst.

Daarnaast wanneer we een nieuwe module ontwikkelen maken we een feature aan die zich basseert op development. Eens die klaar is sluiten we deze feature en gaat deze code in development gezet worden. Als alles uitvoerig door de klant is getest maken we hiervan een release en plaatsen we alles in master.

Indien er een bug is in productie maken we een hotfix die zich basseert op master, als je de hotfix beïndigd zal deze in development en master worden geplaatst.

Hier heb je een mooi voorbeeldje : https://github.com/eadz/Git-Flow-Example

En als je iets verder wil gaan dan simpelweg versioneren, maar deftig de volledige cyclus van je projecten wil beheren dan kies je beter ook meteen voor ALM (Application Lifecycle Management) software.

Deze software gaat de verschillende fases van de volledige levenscyclus van je project beheren, zijnde:

- Requirements
- Issue/Defects Tracking
- Developement
- Versioning
- Build
- Test & Quality Assurance
- Deploy

Een voorbeeld van zulks beheerpakket is IKAN ALM. Het grote voordeel hiervan is dat het pluggable is m.a.w. je kan je bestaande ontwikkelomgeving (b.v. IDE's zoals Eclipse,...) en versionering tool (b.v. Subversion,...) hieraan koppelen.

Er bestaan nog paketten, maar IKAN ALM is wel op-en-top Belgisch.

Meer info: ALM through evolution - IKAN ALM

Ik had het product misschien beter moeten verduidelijken inderdaad: we werken aan 1 product het hele jaar door, 't is dus niet dat we om de zoveel tijd een ander product moeten afleveren of met verschillende versies zitten die onderhouden moeten worden.

De workflow die Pro Git ook uitlegt (http://progit.org/book/ch5-2.html#private_small_team) zal, denk ik, het best voor ons passen.

Met toestanden als ALM gaan we voorlopig zeker niet beginnen. We hebben ons eigen issue/defects tracking systeem, ons eigen versioning methode...

TheCrow7 zei:

En als je iets verder wil gaan dan simpelweg versioneren, maar deftig de volledige cyclus van je projecten wil beheren dan kies je beter ook meteen voor ALM (Application Lifecycle Management) software.

Deze software gaat de verschillende fases van de volledige levenscyclus van je project beheren, zijnde:

- Requirements
- Issue/Defects Tracking
- Developement
- Versioning
- Build
- Test & Quality Assurance
- Deploy

Een voorbeeld van zulks beheerpakket is IKAN ALM. Het grote voordeel hiervan is dat het pluggable is m.a.w. je kan je bestaande ontwikkelomgeving (b.v. IDE's zoals Eclipse,...) en versionering tool (b.v. Subversion,...) hieraan koppelen.

Er bestaan nog paketten, maar IKAN ALM is wel op-en-top Belgisch.

Meer info: ALM through evolution - IKAN ALM

Klik om te vergroten...

Dat lijkt mij echt zoiets enterpriseachtig dat een manager voor zijn dev team koopt omdat hij development wil verbeteren.

Drone zei:

Dat lijkt mij echt zoiets enterpriseachtig dat een manager voor zijn dev team koopt omdat hij development wil verbeteren.

Klik om te vergroten...

Niet echt, zelfs in kleine teams (b.v. 5 personen) gaat dit al voor een enorme tijdsbesparing zorgen. Een developer gaat zich volledig kunnen toeleggen op dat wat hij het liefst en best doet, namelijk ontwikkelen. Van de rest hoeft hij zich niets aan te trekken.

Trouwens gaat de integratie met andere mensen, die weinig met de eigenlijke software ontwikkeling te maken hebben, ook optimaal verlopen.

Een CEO gaat bijvoorbeeld via een eenvoudige klik een overzicht krijgen waneer welke versie van een project succesvol gecompileerd is, en wie bijvoorbeeld zijn toestemming heeft gegeven om te builden.

Een ontwikkelaar kan bijvoorbeeld door enkel zijn broncode in te checken ervoor zorgen dat er een kant-en-klare versie bij een tester op de computer komt te staan. De ALM software gaat in dit geval zien dat er nieuwe code beschikbaar is, automatisch deze code op een machine compileren en vervolgens transporteren naar de juiste persoon, in dit geval dus de tester.

Bekijk het als een moederbord. Elke component doet zijn ding (waar hij specifiek voor gemaakt is) en het moederbord zorgt voor de communicatie en dataoverdracht tussen elke component volgens de juiste workflow.

Merci voor het voor te stellen en het uit te leggen, maar geen een van de dingen die je opsomt zijn van toepassing op ons bedrijf Mij overtuig je dus alvast niet